ydna_sresal
Posts: 5
Joined: Thu Apr 09, 2015 7:36 pm

Raspberry Native C and Speed Tests

Tue Apr 21, 2015 10:24 am

I've been looking at this http://codeandlife.com/2012/07/03/bench ... pio-speed/

speed test to try and understand why some applications run like rockets and others are very very slow.

The fastest turns out to be done with Native C which has a link to some test code.

”C Native library 2015-02-15 using latest RaspPi wiki code 22 MHz on the pi & 44 MHz on the pi2”

could anyone clarify to me what means to use "native C", does it means to write code directly into example a text editor on the raspberry, name the file test.c and then compile it with GCC like this "gcc -o test test.c"

ghans
Posts: 7883
Joined: Mon Dec 12, 2011 8:30 pm
Location: Germany

Re: Raspberry Native C and Speed Tests

Tue Apr 21, 2015 1:19 pm

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.

ghans
• Don't like the board ? Missing features ? Change to the prosilver theme ! You can find it in your settings.
• Don't like to search the forum BEFORE posting 'cos it's useless ? Try googling : yoursearchtermshere site:raspberrypi.org

User avatar
joan
Posts: 15124
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Raspberry Native C and Speed Tests

Tue Apr 21, 2015 2:25 pm

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).

ydna_sresal
Posts: 5
Joined: Thu Apr 09, 2015 7:36 pm

Re: Raspberry Native C and Speed Tests

Tue Apr 21, 2015 5:37 pm

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.

ghans
Thank you ghans for the clarification.

ydna_sresal
Posts: 5
Joined: Thu Apr 09, 2015 7:36 pm

Re: Raspberry Native C and Speed Tests

Tue Apr 21, 2015 5:40 pm

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).
Hi Joan,

Thank you for answering, actually I was not writing it correctly, I was meaning libraries as apposed to native C, not applications.

My request was more to clarify the "Native C" point as it was not clear to me what meant native C.

Fatih GUMUS
Posts: 1
Joined: Mon Jul 13, 2015 1:47 pm
Location: Istanbul / Turkey

Re: Raspberry Native C and Speed Tests

Mon Jul 13, 2015 2:02 pm

so why do we have to other libraries?
because the code seems simpler than the others

by the way to use it
which library should I install
which library should I include to program
or only defining the pins is enough like Arduino.

User avatar
allfox
Posts: 452
Joined: Sat Jun 22, 2013 1:36 pm
Location: Guang Dong, China

Re: Raspberry Native C and Speed Tests

Mon Jul 13, 2015 4:01 pm

In real application, even with C, you can't drive GPIO that fast.

And I remember that there is a book, named Learning perl with a camal on its front page, told me that using a Stradivarius violin to pound nails should not be considered a sound construction technique.

I think it's a good idea to use C to pound nails, and use script language to produce music. (libs in C, but programs in script)

W. H. Heydt
Posts: 13644
Joined: Fri Mar 09, 2012 7:36 pm
Location: Vallejo, CA (US)

Re: Raspberry Native C and Speed Tests

Tue Jul 14, 2015 5:21 am

Probably the way to get the absolutely highest speed would to write the routine in the ARM assembly language. Note that this is not likely to wind up as a useful program (for the reasons already given), plus--barring a program that is trivially simple--whether your code runs faster than C will depend on how good a programmer you are as it is possible to write bad assembly code just as much as any other language.

User avatar
experix
Posts: 204
Joined: Mon Nov 10, 2014 7:39 pm
Location: Coquille OR
Contact: Website

Re: Raspberry Native C and Speed Tests

Tue Jul 14, 2015 2:07 pm

What are people saying when they attach 'native' to 'C'? Are they doing this to clarify that they are not talking about 'non-native' C?

mikerr
Posts: 2826
Joined: Thu Jan 12, 2012 12:46 pm
Location: UK
Contact: Website

Re: Raspberry Native C and Speed Tests

Tue Jul 14, 2015 2:19 pm

Native C is without any specific PI libraries ( bcm2835 ,WiringPi etc)

Note the page linked to has changed, full example code is now at

http://elinux.org/RPi_GPIO_Code_Samples#C
Android app - Raspi Card Imager - download and image SD cards - No PC required !

User avatar
allfox
Posts: 452
Joined: Sat Jun 22, 2013 1:36 pm
Location: Guang Dong, China

Re: Raspberry Native C and Speed Tests

Tue Jul 14, 2015 2:47 pm

mikerr wrote:Native C is without any specific PI libraries ( bcm2835 ,WiringPi etc)
Wow! First time to know this. Thanks!

I was thinking of cygwin and mingw32 for non-Native and Native. So I was wrong, they both are non-Native.

rckanta
Posts: 58
Joined: Tue Feb 18, 2020 2:00 pm

Re: Raspberry Native C and Speed Tests

Tue Feb 18, 2020 2:12 pm

joan wrote:
Tue Apr 21, 2015 2:25 pm
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).
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.

Python is a useless language for interfacing hardware. It is very slow and used lot of resources.

Heater
Posts: 16874
Joined: Tue Jul 17, 2012 3:02 pm

Re: Raspberry Native C and Speed Tests

Tue Feb 18, 2020 2:37 pm

rckanta wrote:
Tue Feb 18, 2020 2:12 pm
joan wrote:
Tue Apr 21, 2015 2:25 pm
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).
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.

Python is a useless language for interfacing hardware. It is very slow and used lot of resources.
Well, and students of actual software engineering who want performance out of their code.
Memory in C++ is a leaky abstraction .

hippy
Posts: 8598
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Raspberry Native C and Speed Tests

Tue Feb 18, 2020 3:57 pm

rckanta wrote:
Tue Feb 18, 2020 2:12 pm
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.

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.

ejolson
Posts: 6045
Joined: Tue Mar 18, 2014 11:47 am

Re: Raspberry Native C and Speed Tests

Tue Feb 18, 2020 4:24 pm

hippy wrote:
Tue Feb 18, 2020 3:57 pm
rckanta wrote:
Tue Feb 18, 2020 2:12 pm
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.

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.
Since this thread has been resurrected, it is worth noting the official code samples for toggling GPIO are at

https://elinux.org/RPi_GPIO_Code_Samples

I found the link in the original post to be interesting. The follow-up discussion focusing on how fast one really needs to toggle a GPIO line without reference to any specific application also makes for an interesting study in social behaviour.

Heater
Posts: 16874
Joined: Tue Jul 17, 2012 3:02 pm

Re: Raspberry Native C and Speed Tests

Tue Feb 18, 2020 4:36 pm

I'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.
Memory in C++ is a leaky abstraction .

ejolson
Posts: 6045
Joined: Tue Mar 18, 2014 11:47 am

Re: Raspberry Native C and Speed Tests

Tue Feb 18, 2020 4:46 pm

Heater wrote:
Tue Feb 18, 2020 4:36 pm
I'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.
Did you forget about Julia?

https://julialang.org/

I wonder if it has a GPIO library.

Heater
Posts: 16874
Joined: Tue Jul 17, 2012 3:02 pm

Re: Raspberry Native C and Speed Tests

Tue Feb 18, 2020 7:22 pm

ejolson wrote:
Tue Feb 18, 2020 4:46 pm
Did you forget about Julia?
Oh shoot, yet another language. Did I forget? I don't know. Did a Julia solution show up in our coding challenges this last year or so?
Memory in C++ is a leaky abstraction .

hippy
Posts: 8598
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Raspberry Native C and Speed Tests

Tue Feb 18, 2020 8:06 pm

ejolson wrote:
Tue Feb 18, 2020 4:24 pm
I found the link in the original post to be interesting. The follow-up discussion focusing on how fast one really needs to toggle a GPIO line without reference to any specific application also makes for an interesting study in social behaviour.
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.

It's a baseline I use in my own toy languages which interact with GPIO.

It's not really any more abstract or inapplicable than typical software benchmarks like recursive Fibonacci benchmarks, is just something consistent to compare each against.
Heater wrote:
Tue Feb 18, 2020 4:36 pm
I'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 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.

But, even where most of the work is being done in Python, it can still be plenty quick enough. Refreshing a 480x320 LCD with pure bit-banged SPI through RPi.GPIO ( not using any SPI hardware, only set pin high and low ) only takes a couple of seconds, works out at around a couple of microseconds per byte transfer rate.

hippy
Posts: 8598
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Raspberry Native C and Speed Tests

Tue Feb 18, 2020 8:37 pm

ejolson wrote:
Tue Feb 18, 2020 4:46 pm
Did you forget about Julia? ... https://julialang.org/ ... I wonder if it has a GPIO library.
It seems it does and appears well supported on a Pi -

https://www.raspberrypi.org/blog/julia- ... pberry-pi/

Haven't tried GPIO but it looks to be impressively fast on the Recursive Fibo() benchmark. Rankings updated -

viewtopic.php?t=256391#p1577475

ejolson
Posts: 6045
Joined: Tue Mar 18, 2014 11:47 am

Re: Raspberry Native C and Speed Tests

Tue Feb 18, 2020 8:42 pm

hippy wrote:
Tue Feb 18, 2020 8:06 pm
I cannot think of any micro or SoC where the fastest and actually achievable toggling rates haven't been discussed.
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.

Without such information it is difficult to know whether the Pi can be used for certain applications and what languages are suitable in each case. It would be nice to further indicate the stability of the maximum toggle rates. For example, whether they can be maintained or are periodically interrupted by various system tasks like writing to the SD card.

rckanta
Posts: 58
Joined: Tue Feb 18, 2020 2:00 pm

Re: Raspberry Native C and Speed Tests

Mon Mar 16, 2020 6:07 am

C language is very fast compared to other language and it uses very little system resources compared to others.
And pythons an interpreted language because of this it makes slower.

The big advantage of pythons is very easy while C is much more complex.

Compare to python, C pro use less than 1% of the memory.


C language is almost fast as assembly language.

For PI
C = 125 MHz
Python = 70Khz

Hence C best for use in professionals.

How I choose the programming language :

1.Fastest
2. Use little system resource
Last edited by rckanta on Mon Mar 16, 2020 6:19 am, edited 1 time in total.

rckanta
Posts: 58
Joined: Tue Feb 18, 2020 2:00 pm

Re: Raspberry Native C and Speed Tests

Mon Mar 16, 2020 6:12 am

interfacing relay, led, speed control, etc these are very low frequency.

Python can not interface to the high-frequency hardware.

Heater
Posts: 16874
Joined: Tue Jul 17, 2012 3:02 pm

Re: Raspberry Native C and Speed Tests

Mon Mar 16, 2020 6:47 am

Some time ago I managed to goggle a GPIO pin at 50MHz on a Pi 3. The tricky part is being able to do that continuously without all the stutters
and stalls that the Linux kernel can introduce when it reschedules things. I managed to get it running pretty solidly with only a 5us stall every few milliseconds. Have since learned a way to deal with that. Not tried it yet. My experiment was described here: viewtopic.php?t=200793

Of course that result is pretty meaningless and useless on it's own. But the techniques used did help someone get their timing critical job done in that thread above.

I have yet to see how well the Pi 4 does with that setup.
Memory in C++ is a leaky abstraction .

hippy
Posts: 8598
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Raspberry Native C and Speed Tests

Mon Mar 16, 2020 2:35 pm

rckanta wrote:
Mon Mar 16, 2020 6:12 am
Python can not interface to the high-frequency hardware.
It depends on exactly what one means by that.

Python cannot interface to any hardware directly so a Python programmer will call libraries which can be written in C which will be just as fast when executing as C itself is.

Any slowness of Python is in calling the libraries and interpreting the Python bytecode once that library has returned. If most of the time it stays within the C library it can handle things just as fast as C itself can. If it does a lot of calling, returning and executing Python it will be slower.

A Python program could build up a bitmap for a GPIO connected LCD and than blat that out. If it does that by bit-banging each GPIO signal change in Python then it will be slow, though surprisingly quick for the amount of bit-banging it's doing. If it bit-bangs bytes via a Python SPI library it will be faster, if it passes the entire bitmap to a C library that can blat it out as quickly as any C program could.

It's a bit like 3B+ wired ethernet; capable of 1GBe but not sustained, only in bursts.

So it's not that it can't interface to high-frequency devices; it depends on what that high-frequency hardware demands.

Return to “General discussion”