I have been waiting for this type of comparison. Thanx Kevin! I have done initial selections between C and Python several times. My main arguments have been: Files, sound or strings -> Python. Complex logic, multiple interfaces -> C. Hardware testing -> Python. The application is to be maintained by a person with limited programming skills -> Python. For the Python implementations I still need to choose between CircuitPython and MicroPython.
MicroPython and C is not an either-or choice! Many of the MicroPython modules are implemented in C (the rest are in plain Python) - and one can install third party C modules as well. There are two flavors - external C modules, which have to be included at build time of the MicroPython firmware - and native modules, which can be installed at runtime, by adding a .mpy file to the filesystem. By combining C modules with Python, we can get the best of both worlds - the convenience and rapid iteration of Python, and the fast execution and low memory usage of C. For example, I have written an ML/DSP library for MicroPython using native modules, called emlearn-micropython.
The C++ statement float result = (1234.56 * 7890.12) / 345.67; is not a good benchmark: the right hand side being constant, it is evaluated at compile-time. You end up with just an assignment of a constant to be done at run time. Wait, no, not event that! As the variable `result` is not used anywhere in the sketch, it gets optimized-out by the compiler. So the whole “calculation” benchmark gets optimized into this: while (millis() < endTime) { calculations++; } I don't know whether the Python interpreter can do this kind of optimizations, but the C++ compiler can absolutely not miss them.
Thank you for sharing this knowledge. I am currently trying to learn viper and asm_thumb but there is little to no documentation to support this important part of MicroPython. Therefore, please make a series similar to how Life with David did for PIO. Also, I noticed at 44:20 of your video that MicroPython performed 65536 calculations per second. This number, 65536 is the same as 0xFFFF. When I see an exact number like 65536, this makes me suspicious there is an anomaly with the test that needs further investigation to understand if there is something that is artificially biasing the results.
Which programming language did you use for your smackdown scores ? After comparing File systems the score was 7/5 then one comparison later after Development Workflow the score was 7/8 Something fishy is going on here
The comparisons made were completely objective, but the points awarded for each part were completely subjective. So Python wins because... personal preferences / priorities.
24:33 You don't need to click the Verify button, unless you don't intend to upload it afterwards. Just click the Upload button. It then does the same thing, but without compiling it twice. I agree it compiles when there's no need to though, e.g. after failing to upload because of forgetting to set the port correctly. There's no Stop button either. Despite what I've read, the only reliable way to stop it compiling, when I know I've made a mistake, is to exit the IDE, which doesn't help much because it takes a while to start up again.
Due to micropython being slower, would micropython on a 600mhz teensy be fast enough to use for a speeduino, I think it would need to fire the spark exactly every 2.3 milli seconds for each cylinder alternatively?
BASIC is easier still, so why aren't we using that? Python is a fussy language with quite a bit of extra typing involved, like having to use math.sin() instead of just sin(). The indentation errors are a pain to track down, for a beginner. Personally, I find it easier to write in C or C++ than Python and it's not entirely because I know them better. Immediate execution is about the only bonus, but BASIC does that too.
This is the first I've heard that there's an official Arduino IDE for MicroPython. Does it do CircuitPython too? Is there a legitimate reason for CircuitPython to exist, or should Adafruit have just contributed board support packages for MicroPython instead?
I've used C++/Arduino a lot, but have very little experience of using Python. So there's MicroPython, CircuitPython (just for Adafruit?) and I now know there's at least 4 IDE's - Arduino Lab, OpenMV, Thonny and Mu. What I'd really like to see is some comparison of all those options to get a better idea what to use.
The ESP32 port of MicroPython runs on top of esp-idf and FreeRTOS. I think the Zephyr port also runs on top of Zephyr RTOS. So yes, it is possible for them to at least co-exist.
There was no need to use the Verify button before Upload, though it's true that the Upload shouldn't have to do the compilation again if Verify has been used. It's always been like that and they're clearly never going to fix it. It's more irritating to me if I've forgotten to set the port correctly, or the device needs to be unplugged and plugged back in again to get it recognised after the previous upload. It can be done with Cmake instead, apparently, which would cope with that better and not compile it again when nothing has changed... I keep meaning to look into that.
Great comparison - this deserves a lot of views!
Thank you!
I have been waiting for this type of comparison. Thanx Kevin! I have done initial selections between C and Python several times. My main arguments have been: Files, sound or strings -> Python. Complex logic, multiple interfaces -> C. Hardware testing -> Python. The application is to be maintained by a person with limited programming skills -> Python. For the Python implementations I still need to choose between CircuitPython and MicroPython.
MicroPython and C is not an either-or choice! Many of the MicroPython modules are implemented in C (the rest are in plain Python) - and one can install third party C modules as well. There are two flavors - external C modules, which have to be included at build time of the MicroPython firmware - and native modules, which can be installed at runtime, by adding a .mpy file to the filesystem. By combining C modules with Python, we can get the best of both worlds - the convenience and rapid iteration of Python, and the fast execution and low memory usage of C.
For example, I have written an ML/DSP library for MicroPython using native modules, called emlearn-micropython.
The C++ statement
float result = (1234.56 * 7890.12) / 345.67;
is not a good benchmark: the right hand side being constant, it is evaluated at compile-time. You end up with just an assignment of a constant to be done at run time.
Wait, no, not event that! As the variable `result` is not used anywhere in the sketch, it gets optimized-out by the compiler. So the whole “calculation” benchmark gets optimized into this:
while (millis() < endTime) {
calculations++;
}
I don't know whether the Python interpreter can do this kind of optimizations, but the C++ compiler can absolutely not miss them.
Thank you for sharing this knowledge. I am currently trying to learn viper and asm_thumb but there is little to no documentation to support this important part of MicroPython. Therefore, please make a series similar to how Life with David did for PIO.
Also, I noticed at 44:20 of your video that MicroPython performed 65536 calculations per second. This number, 65536 is the same as 0xFFFF. When I see an exact number like 65536, this makes me suspicious there is an anomaly with the test that needs further investigation to understand if there is something that is artificially biasing the results.
Yes, there is some Viper and Thumb documentation, but the documentation leaves much to be desired.
Which programming language did you use for your smackdown scores ?
After comparing File systems the score was 7/5 then one comparison later after Development Workflow the score was 7/8
Something fishy is going on here
The comparisons made were completely objective, but the points awarded for each part were completely subjective. So Python wins because... personal preferences / priorities.
24:33 You don't need to click the Verify button, unless you don't intend to upload it afterwards. Just click the Upload button. It then does the same thing, but without compiling it twice.
I agree it compiles when there's no need to though, e.g. after failing to upload because of forgetting to set the port correctly. There's no Stop button either. Despite what I've read, the only reliable way to stop it compiling, when I know I've made a mistake, is to exit the IDE, which doesn't help much because it takes a while to start up again.
pico is my favorite microcontroller (running MicroPython)
Due to micropython being slower, would micropython on a 600mhz teensy be fast enough to use for a speeduino, I think it would need to fire the spark exactly every 2.3 milli seconds for each cylinder alternatively?
TLDR: micropython is easier than C++, especially for noobs. C/C++ a lot faster and more powerful.
BASIC is easier still, so why aren't we using that? Python is a fussy language with quite a bit of extra typing involved, like having to use math.sin() instead of just sin(). The indentation errors are a pain to track down, for a beginner. Personally, I find it easier to write in C or C++ than Python and it's not entirely because I know them better. Immediate execution is about the only bonus, but BASIC does that too.
This is the first I've heard that there's an official Arduino IDE for MicroPython. Does it do CircuitPython too? Is there a legitimate reason for CircuitPython to exist, or should Adafruit have just contributed board support packages for MicroPython instead?
I've used C++/Arduino a lot, but have very little experience of using Python. So there's MicroPython, CircuitPython (just for Adafruit?) and I now know there's at least 4 IDE's - Arduino Lab, OpenMV, Thonny and Mu. What I'd really like to see is some comparison of all those options to get a better idea what to use.
Can we work with an RTOS using microPython?
The ESP32 port of MicroPython runs on top of esp-idf and FreeRTOS. I think the Zephyr port also runs on top of Zephyr RTOS. So yes, it is possible for them to at least co-exist.
👍👍👍
25:00
There was no need to use the Verify button before Upload, though it's true that the Upload shouldn't have to do the compilation again if Verify has been used. It's always been like that and they're clearly never going to fix it. It's more irritating to me if I've forgotten to set the port correctly, or the device needs to be unplugged and plugged back in again to get it recognised after the previous upload. It can be done with Cmake instead, apparently, which would cope with that better and not compile it again when nothing has changed... I keep meaning to look into that.