Thank you ghans for the clarification.ghans wrote:Yes, that is exactly what is meant with "native C".
Takeit as a fact of life that C is simply much faster in this
scenario than any scripting language.
Hi Joan,joan wrote:You are wasting your time looking at silly benchmarks like that.
It tells you nothing about the performance of the same application written in C or another language (unless your application's sole job is to toggle gpios).
Wow! First time to know this. Thanks!mikerr wrote:Native C is without any specific PI libraries ( bcm2835 ,WiringPi etc)
Only the hardware(Electronics) student will understand how important speed and resource use.C language used less memory compared to other languages and it is very fast compared to other languages.
Well, and students of actual software engineering who want performance out of their code.rckanta wrote: ↑Tue Feb 18, 2020 2:12 pmOnly the hardware(Electronics) student will understand how important speed and resource use.C language used less memory compared to other languages and it is very fast compared to other languages.
Python is a useless language for interfacing hardware. It is very slow and used lot of resources.
That doesn't make Python useless. It all depends on what one is interfacing to and what speed one needs.
Since this thread has been resurrected, it is worth noting the official code samples for toggling GPIO are athippy wrote: ↑Tue Feb 18, 2020 3:57 pmThat doesn't make Python useless. It all depends on what one is interfacing to and what speed one needs.
Many Pi users will be interfacing to buttons, LED's, relays and the like where speed of execution is largely irrelevant with ease of programming being far more important.
Did you forget about Julia?Heater wrote: ↑Tue Feb 18, 2020 4:36 pmI'm warming to the idea of Python being acceptable when 99% of the work in ones program is done in some library in C/C++ or whatever.
That can include interfacing to devices through libraries in C/C++ or through kernel drivers.
Use of Python in machine leaning is great example. Most of the work there is done in C libraries or in CUDA on a GPU.
In such cases Python can be quite fast enough for many things, including "real-time" applications like robotics.
I believe that's because it's the hardware equivalent of 'just how fast does it really go?' ... "and with the software layer on top?". I cannot think of any micro or SoC where the fastest and actually achievable toggling rates haven't been discussed.
That was always the argument as to why apps in VB6 et al were never really as slow as it might appear they would be. Many interpreters only add a couple of instructions of overhead to the calls to the libraries which actually do the something. It's why emulating X86 apps on Windows 10 ARM isn't always as atrocious as some say they will be.
It seems it does and appears well supported on a Pi -
I think it is important that someone has measured and then reported the GPIO switching rates as careful work such as that can save time for many people.
It depends on exactly what one means by that.