One of my favourite benchmarks is the calculation of the solar eclipse.

solar_eclipse.zip

The data I use to test with is:
12,1,2000
39,40,36
-104,57,12
1644
30


Running on a HDMI build at 378 MHz this takes 13.23 seconds

Converting this to Micropython 1:1

solar_eclipse_py.zip

This runs in 8.77 seconds at 378MHz!

but Micropython has a trick up its sleeve using the ulab library

solar_eclipse_ulab.zip

And now it runs in 7.44 seconds

For reference if I run the Basic code on a 480MHz STM32H743 which has H/W double precision floating point it takes 7 seconds

---

Damn snakes, spoiling it for everyone, can't help but think that happened somewhere else .

Tom

  matherp said  

One of my favourite benchmarks is the calculation of the solar eclipse.

solar_eclipse.zip

The data I use to test with is:
12,1,2000
39,40,36
-104,57,12
1644
30


Running on a HDMI build at 378 MHz this takes 13.23 seconds

Converting this to Micropython 1:1

solar_eclipse_py.zip

This runs in 8.77 seconds at 378MHz!

but Micropython has a trick up its sleeve using the ulab library

solar_eclipse_ulab.zip

And now it runs in 7.44 seconds

For reference if I run the Basic code on a 480MHz STM32H743 which has H/W double precision floating point it takes 7 seconds

I notice the BASIC version has a BASIC subroutine for matrix transpose. MMBasic has one built in. Would using the MATH subroutine be faster than the one written in BASIC?

BASIC code is the prettiest though  

MicroPython has a perfectly good math.atan2(), which will be faster than a hand-rolled equivalent.

MicroPython's complete lack of a useful sgn() function, however, is a pain.

I wonder how much faster it would be compiled with single-precision floating point. That's the norm for MicroPython

It would be a lot faster, but, for example, that solar eclipse program simply fails. Any complex math needs double precision

There are many industrial users of MicroPython who are just fine with single precision. If you want to do fancy stuff, use a desktop. Let the code run at its proper speed.

Lots of industrial stuff can be done without floating point (*), but it may be easier with it!

(*) been there...

John

  Quote  

There are many industrial users of MicroPython who are just fine with single precision. If you want to do fancy stuff, use a desktop. Let the code run at its proper speed.

There is very little speed penalty using double precision because all interpreters spend more time interpreting than calculating. Single precision isn't adequate for many many tasks - errors build up too quickly. Even BBCBasic as implemented on a 6502 used 40-bit floating point rather than 32.
Feel free though to build a version with single precision - the source is all on github. I bet you will see very little increase in speed for normal usage

  Quote  

If you can't solve the problem with integers, you don't understand the problem ~ unknown

I have always been an integer guy but now I'm liking our double precision.  

Speed is not everything. The language is what you need for a job, what you are comfortable with, that runs on the required platform.

These speed adventures have been going on for decades. When all the computers were really, painfully, slow the language speeds really mattered a lot. Outside of modern video games, the speeds today are not as significant. Everything runs fast, so much faster than it did years ago. How much better is Hangman, or Pacman or a home alarm display panel if it runs at 1Ghz, using assembly rather than 50Mhz, using BASIC?

If you want speed, use assembler or maybe C. Or stick with a slower language on a faster processor.

To me, Python is just structured BASIC with a beard. Usually a bit faster but both can get the job done, so why get so worried about one or the other? Plenty elsewhere to get stressed about.

For machine control, the PicoMite with BASIC is extremely capable.

I was troubleshooting the highly regarded Heidenhain TNC151 (CNC) on a Bridgeport Interact-4. I have all the documentation and Gemini provided further details.
Long-story-short, I came to realize that a single PicoMite RP2350 can easily outperform this entire controller, including HMI, without breaking a sweat.  

I then researched a Trumpf laser (BIG) that features the Siemens 840D (very popular).
Same thing  

Both CNCs run their PID loops at 4ms (250Hz). We can achieve 1ms (1KHz) on the PicoMite. I am not too comfortable with the CPU load when running more than four axes (4 PIDs) but at 2ms (500Hz) we have lots of spare power.

The trajectory planners run much slower which is nothing for the PicoMite.

Aaaannnnnd....We have an onboard code editor  

Mind blowing  

Q: discuss why MMBASIC is as good as any modern language
From Perplexity:
MMBasic deserves more respect than it usually gets. Skeptical coders often dismiss it as “just BASIC,” as though age and simplicity were defects rather than design choices. But in practice, MMBasic is a sharp, efficient tool for a very real class of problems: embedded control, instrumentation, rapid prototyping, and single-purpose systems where getting useful work done matters more than stacking abstractions. It is not trying to replace every modern language; it is trying to make small hardware feel immediate and programmable, and it succeeds remarkably well. MMBasic is described as a full-featured BASIC interpreter focused on ease of use and rapid development, with support for dynamic memory, strings, floating point, structured statements, and custom extensions.

The first thing a skeptical coder should notice is that MMBasic removes friction. Modern programming stacks often begin with package managers, build systems, dependencies, scaffolding, and layers of framework before a single sensor is read or a pin is toggled. MMBasic instead lets you get straight to the job. That simplicity is not just convenient; on microcontrollers, it is often the difference between finishing a prototype in an afternoon and spending a week wrestling infrastructure. When the environment is small, the language should be small too.

Second, MMBasic is not “minimal” in the insulting sense. It is compact, but it is also practical. It includes useful built-ins for hardware interaction and even graphics, and it supports a range of structured features that make real programs maintainable. That matters because the strongest criticism of old BASIC dialects was usually that they encouraged messy sprawl; MMBasic is a modern response to that problem. It preserves the accessibility of BASIC while adding enough structure to support serious work.

A skeptic may argue that modern languages offer better ecosystems, and that is fair. But ecosystem size is not the same as engineering quality. A tool is good when it fits the constraints of the task. In embedded work, the constraints are often memory, simplicity, deterministic behavior, and direct hardware access. MMBasic shines precisely because it respects those constraints. It lets a small controller behave like a programmable instrument rather than a puzzle box.

There is also a deeper reason to value MMBasic: it lowers the barrier between thought and execution. In many languages, the programmer spends a lot of cognitive energy on ceremony and syntax before the actual idea appears. MMBasic shortens that path. For engineers, hobbyists, and educators, that is powerful. It encourages experimentation, and experimentation is how hardware projects get refined into something robust. The best language is often the one that lets you ask the machine a question and get an answer quickly.

Of course, MMBasic is not the right answer for everything. If you are building a massive server, a concurrent distributed system, or a library-heavy application, a modern language may be the better choice. But that does not diminish MMBasic. It simply means MMBasic is specialized, and specialization is a strength. In the same way that a torque wrench is not inferior to a Swiss Army knife because it does one job well, MMBasic is not inferior to a fashionable general-purpose language because it excels in its domain.

So the defense of MMBasic is not nostalgia. It is engineering. It is a language that values clarity, immediacy, and practical control over ceremony. It is easy to underestimate because it is approachable, but that approachability is exactly what makes it effective. A skeptical coder may not fall in love with MMBasic at first sight, but once they need to bring hardware to life quickly and reliably, they may discover that it is not merely adequate. It is excellent.
Edited 2026-07-30 06:08 by barewires

Great write-up  

Not sure about:

  Quote  

a concurrent distributed system

I use a full-duplex, multidrop RS485. Data is already present on each node.
Address &HFF is "broadcast" and so execution is as concurrent as however long (few µS?) it takes MMBasic to grab from the RX buffer on each node.

Very few people seem to latch on to the fact that BASIC was designed from day one to be as easy to understand as possible. That was the fundamental reason for it being created in the first place - as a tool to teach the concepts of programming. It's moved on a lot since, but a lot of that still remains. It makes the programs easier to document and maintain than some other languages.

"Micropython is faster than MMBasic"

but not when MMbasic is compiled.

Interim results for the MMbasic compiler under Fuzix on the Pico Computer 3,  i.e compiled on the rp350b itself


Edited 2026-08-01 04:37 by matherp

Some of those are over 20x faster. How does your Solar Eclipse calculation fair? assuming the compiler is complete enough to compile it....
just found it on Github, 3.5 seconds so about 4x faster than uncompiled MMBasic. Excellent. :-)
Edited 2026-08-01 05:52 by Bleep

  matherp said  

but not when MMbasic is compiled.

You can't just drop that comment in here without explanation  

I am intrigued!

  PeteCotton said  

  matherp said  

but not when MMbasic is compiled.

You can't just drop that comment in here without explanation  

I am intrigued!

Fuzix currently working on an MMBasic compiler

~~~~ Reality checks ~~~~

  Quote  

From Perplexity:

Perplexity is an AI bot, it seems to be regurgitating the marketing hype that
made me avoid MMBasic in the first place !!

  Quote  

but not when MMbasic is compiled.

Is there a Python compiler ? Using that would be a fairer comparison.