Fastest programming language on pi zero ?

[Digitaldreams]

Anyone tried a simple loop in all the current pi programming languages to see which is the fastest on a Pi Zero ?

Thanks in advance

[PhatFil]

what do you think the results would indicate? have you a project in mind that requires minimal latency?

[ShiftPlusOne]

Such a test wouldn't tell you anything useful at all. But the answer is asm.

[scruss]

Depends on the compiler, too. Some optimizing compilers see something like this:

Code: Select all

FOR i=1 to 1000000
NEXT i
END

and notice there's nothing going on in the loop, and produce code that's effectively:

Code: Select all

i=1000000
END

This is the fastest code of all, because it does nothing.

The fastest programming language is the one that gets you to the result you wanted in a way you understand in the least total time. For some people, that might be ARM assembly language. For others, it might be Scratch or Blocks.

[gkaiseril]

Most computer benchmark programs use a mix of operations to develop a more meaningful picture of how fast a computer language will process. A lot will depend upon the operations you are trying to run. In general assembler is considered the fastest running but it may require more coding to create and if large enough will be harder to modify. Also the introduction of a new processor may offer new opportunities for optimization but again this may require more coding and added debugging. After assembler would come a higher level compiled language like C which can provide easier to code and read source programs and produce code that may be optimized. The least efficient would be interpreted languages since the source code would need to be syntax checked, converted into some usable coding line by line before stating to run the program or it might even require each line to be fully processed each time the line of code is called for processing.

[Digitaldreams]

I was hoping for a chart of sorts comparing whats out there for a PI. Yes Arm assembler is bound to be the fastest. I was wondering what the difference was between the different versions of python, scratch etc.

On the topic of Arm assembler is there a good well finished one (IDE) for the PI that has good help files and tutorials etc ?

Regards

[ghans]

I would guess C would be the fastest ? I don't think there is any useful "IDE" for Raspbian Assembly programmers out there. But C should be supported via Geany, Code::Blocks or even Eclipse CDT.

ghans

[jahboater]

On the topic of Arm assembler is there a good well finished one (IDE) for the PI that has good help files and tutorials etc

I don't think so. Raspbian includes the standard gnu assembler called "as" which is truly excellent - but of course has no specific IDE of its own.
A useful tip for debugging and general interest, is to run you program in the debugger (gdb) and type "layout reg" (or just "la r"). This splits the screen into three windows - one showing all the registers with the those changed by the last instruction highlighted, one showing the code, and one for your commands. Step though with "si" (or "ni").

[jahboater]

Yes Arm assembler is bound to be the fastest.

No it is not, at least not for any practical program of any size.

Use C. And get the latest version of the compiler (gcc 7.3 at the time of writing) it will produce faster code than the default compiler version. C++ is a close second.

There is very good reason why most of the system (e.g. the OS kernel and the majority of the commands you use day to day) are written in C. Furthermore, other languages or libraries you might try are commonly written in C underneath.

A highly competent assembler programmer, with a great deal of effort, for that one single processor, might just match the C compiler for a small program (a few lines). Any real program of any size and the compiler will always win. There are various reasons for this.
And then later you decide to use a different Pi, perhaps even in 64-bit mode - the assembler programmer is lost, yet the compiler rebuilds the program, optimized for the new machine, in seconds.

The assembler programmer has various constraints that the compiler simply does not have.
One obvious example: readability and maintainability of the code. Assembler is hard to write and manage. The program must be well structured, and typically split into small manageable chunks that a human can understand (functions) even if they are only called once. The compiler has no such limits, the first thing it does is merge all those functions used once and many others into a single very large function after which large scale global optimization can be applied. Not possible for the human.

The compiler doesn't get tired, it can apply the same level of optimization throughout a million lines of code that a good assembler programmer (might) achieve over 10 lines of code.

The teams of people that write compilers like GCC know the hardware very well. Here is an example, instruction scheduling. Most assembler programmers would think that "movt" is dependent on the previous "movw" and separate them. But some recent ARM processors fuse these two together into a single operation in which case separating them would be a disaster. Some ARM processors are out-of-order anyway (not Pi's). Keeping track of all that stuff is very hard indeed for the assembler programmer, yet it is natural and easy for the compiler.

More and more compilers are understanding what the programmer really wants to achieve in the end. Highly expressive languages like C++ help, but even in C, compilers do surprising things and recognize common idioms. I saw for example, a C compiler take a function to count the set bits in a word using Denis Ritchie's algorithm and reduce it to a single instruction!

Forget any interpreted language, they have to translate the program on-the-fly and no real (global) optimization is possible.

Assembler is great fun, educational, and I love using it.
But for speed nowadays it is always C.

[DougieLawson]

Forget any interpreted language, they have to translate the program on-the-fly and no real (global) optimization is possible.

Assembler is great fun, educational, and I love using it.
But for speed nowadays it is always C.

You've hit the nail on the head there.

I write IBM mainframe assembler (and HLASM is a wonderful tool) but it's a long slow process to get anything useful running. IBM write their operating system and database/transaction managers in Programming Language Extended (PLX) which has all the benefits you've documented, plus supports in-line assembler for special cases. It generates assembler which is then assembled to machine code with HLASM. The assembler it creates looks nothing like the stuff I write.

On my Raspberries if I need something faster than an interpreted language I'll always use plain old C.

[jahboater]

I used to work with IBM's VM/SP and CMS which was written in assembler.
I have to say it was the best quality, best written, and most maintainable assembler code I have even seen.

C has in-line assembler too which is occasionally useful. Inline asm in GCC is hard to learn, but takes part fully in the optimization process which is unusual. It can do clever things like exporting the condition codes for direct use in the surrounding C.

[ShiftPlusOne]

You'll also find people who say C is for dinosaurs. You'll see people talking about how Java's garbage collection makes it the only language worth using in 'real' applications. You'll see people saying that compilers are awful and hand-crafted assembly is the way to go and others saying compilers produce much better assembly than anything you can write by hand. Asking this sort of question will get you every single answer possible, if you ask enough people.

is there a good well finished one (IDE) for the PI that has good help files and tutorials etc ?

Well NOW you've really done it. That's another one where you'll get very conflicting answers.

My approach:
https://sanctum.geek.nz/arabesque/series/unix-as-ide/

In the end, it all depends on what your application requires, what you're comfortable with and whether you have the time and desire to learn. Try everything and see where you land.

[jahboater]

My approach:
https://sanctum.geek.nz/arabesque/series/unix-as-ide/

I like that!
UNIX and I suppose Linux were always described as a "software factory".

In the end, it all depends on what your application requires, what you're comfortable with and whether you have the time and desire to learn. Try everything and see where you land.

Thats the best advice.

Anyone tried a simple loop in all the current pi programming languages to see which is the fastest on a Pi Zero ?

Try it for yourself, very educational.
But not a "simple loop" - few programs consist of just a small loop - and you will get distorted results.
A byte code interpreter will do a reasonable job here as the translation is only done once, a C compiler will simply remove everything, assembler will execute it exactly as given.

[danjperron]

All depends !

A well design assembly code will be faster than C. Don't forget C will compile and create an assembly version using optimisation but a skill programmer could even optimize the assembly again to speed up process.

But in reality you could do code and make it way faster when you know all the in and out. Code could be faster using DMA or use the GPU, split the code in threads to spread it into differents cores. Between C and assembly it is how you code your application the most important!

[jahboater]

Don't forget C will compile and create an assembly version using optimisation but a skill programmer could even optimize the assembly again to speed up process.

That was true, and I often used to do just that - decades ago.
But have you tried doing that with a recent version of GCC (7.3 is the latest version)?
I'll be surprised if you can find even a single instruction out of place (and if you can, please report it as a bug).
More likely if you did find something odd, say an unnecessary register move, its because you have not fully understood the code and the compiler is actually using it a long way away (it does global and inter procedural optimization).

This website is very interesting - the Godbolt Compiler Explorer. You can give it bits of code and it will present the emitted assembler - for various compilers/versions and target hardware:
https://godbolt.org/

GCC 7+ emits the original source intermingled with the assembler, so its reasonably easy to see whats going on.

[danjperron]

danjperron wrote: ↑
Sat Mar 03, 2018 7:17 am
Don't forget C will compile and create an assembly version using optimisation but a skill programmer could even optimize the assembly again to speed up process.
That was true, and I often used to do just that - decades ago.

I don't know about arm but I do have some trick on my hand when I use x86 compilation. In C it is hard to use the x86 indirect address with offset in C .

ex: #define ADDVALUE(V) __asm(mov ax, word ptr[ esi + (V)])

I found that if I had to calculate suround filter on a 2D image this instruction is 10 times faster in assembly. It can't be translated into C.

[jahboater]

In C it is hard to use the x86 indirect address with offset in C .

ex: #define ADDVALUE(V) __asm(mov ax, word ptr[ esi + (V)])

This is not the sort of thing you worry about when using a high level language and a modern compiler.
Compilers nowadays do a far better job indexing arrays than you can imagine.

It can't be translated into C.

Sorry, that doesn't make any sense at all.
What do you think the compiler does with "short n = array[V]" ?

Please stop thinking about ancient 16-bit compilers from 20+ years ago.
Look at what GCC does now.

[jamesh]

I would say the only time you MIGHT need assembler on the PI is if you want to use the NEON instructions set. Although compilers can use it, and turning it on will benefit, they are not quite so good at parallelising code (although getting better all the time, its quite possible the 7.x series of gcc is much beter) as humans. And by humans, I mean the very specialised humans who can actually write good NEON code.

And there are not many of them about.

[Heater]

Assuming one can hand craft some assembler to outperform a C/C++ compiler for some CPU sometimes. On average the assembler programmer loses badly. His code may not run as well on new versions of the architecture he has targeted, it won't run at all on other machines. How bad is that?

A while ago I wrote some number crunching code in C that was a bit slower than my assembler equivalent on the same machine. But, using OpenMP I could get my algorithm (the same source code) spread over 2, 3, 4 or more cores with useful boosts in performance. No way would I want to be writing such adaptably parallel code in assembler!

Bottom line is that it's silly to use assembler except in some specific cases.

As for Python and other interpreted languages. Tests I have done show Python to be 10 times slower than Javascript under node.js. And Javascript can be as fast as compiled C code with optimizations turned off. Which is pretty amazing.

The other bottom line of all this is that benchmarks don't tell the whole story. They quite likely don't represent what you want to do in your application. If performance (as in speed) for your application is important the best thing to do is try it and measure it.

Certainly measuring what is going on is the first thing to do. If your program is causing cache misses all the time it will be running very slowly. Rewriting that algorithm in assembler will not help you!

[danjperron]

Assuming one can hand craft some assembler to outperform a C/C++ compiler for some CPU sometimes. On average the assembler programmer loses badly. His code may not run as well on new versions of the architecture he has targeted, it won't run at all on other machines. How bad is that?

This is true! I can't use that code if I change something .


In reality I must agree that C is way far easier to build code and good ones But sometimes you need to break the rules and figure out a way to optimize the code because the current version is not fast enough and is time to increase speed.

But the fastest code is normally the code that you find the best way to optimize.

ex: when I was a teen I figure out how to create a tic tac toe games using a simple index pointer. So the code was simple but the optimizing took
me more time than the coding. Figure out only 3 positions center, left top and middle top, All the other are a simple rotation of the tic tac toe, etc..

So in my point the view the fastest code is the one you try to decipher the most to get the best approach!

[ejolson]

I would say the only time you MIGHT need assembler on the PI is if you want to use the NEON instructions set.

The C programming language was designed so the built-in data types reflected those available in the hardware. That was in the 70s and the hardware was a PDP-11. Now that short vectors such as NEON and other SIMD are widely available, C no longer maps onto the hardware but leaves out significant features. It also lacks SMP control structures, however, that has been mostly overcome by the OpenMP and MIT Cilk/Tapir parallel programming extensions.

Although NEON, SSE, AVX, AltiVec and similar have been added, these intrinsics do not extend the C programming language in an architecture-independent way. On the other hand, automatic vectorization of portable code that was written using only the data types available in the 70s is limited. Compilers are good at creating low level-code from high-level constructs but significantly less able to abstract low-level constructs into high-level code. To write efficient portable code for modern processors a new programming language is needed that maps onto modern hardware in a C-like way by including built-in operations on vector data types. As far as I know, no such language exists.

[jahboater]

I would say the only time you MIGHT need assembler on the PI is if you want to use the NEON instructions set.

The C programming language was designed so the built-in data types reflected those available in the hardware. That was in the 70s and the hardware was a PDP-11. Now that short vectors such as NEON and other SIMD are widely available, C no longer maps onto the hardware but leaves out significant features. It also lacks SMP control structures, however, that has been mostly overcome by the OpenMP and MIT Cilk/Tapir parallel programming extensions.

Although NEON, SSE, AVX, AltiVec and similar have been added, these intrinsics do not extend the C programming language in an architecture-independent way. On the other hand, automatic vectorization of portable code that was written using only the data types available in the 70s is limited. Compilers are good at creating low level-code from high-level constructs but significantly less able to abstract low-level constructs into high-level code. To write efficient portable code for modern processors a new programming language is needed that maps onto modern hardware in a C-like way by including built-in operations on vector data types. As far as I know, no such language exists.

Thats a well composed summary, thank you.

I see in the forthcoming GCC 8

Code: Select all

The Cilk+ extensions to the C and C++ languages were removed from GCC.
The MPX extensions to the C and C++ languages have been deprecated and will be removed in a future release. 

Not sure why.

[Heater]

Cilk+ is going away because Intel does not want to support it anymore. They suggest using standardized alternatives such as OpenMP
https://software.intel.com/en-us/forums ... pic/745556

That only talks about it being dropped from the Intel compiler. I can find no mention of that re: GCC by googling. Do you have a link to such a statement?

[jahboater]

Early days yet:

https://gcc.gnu.org/gcc-8/changes.html

[ejolson]

Cilk+ is going away because Intel does not want to support it anymore. They suggest using standardized alternatives such as OpenMP

In my opinion Cilk is an example of a disruptive innovation that makes parallel processing so easy that it becomes the standard way of programming. In terms of Christensen's theory, Intel as well as the gcc project may be too large, concerned with bigger things and consequently unable to invest in something small that will change the world. At the same time, researchers at MIT have continued innovating and there is now a Cilk version of Clang that includes a parallel processing aware version of LLVM called Tapir. As Tapirs are large animals known for biting people's arms off as well as not running on the Pi's ARM processors, the bad-naming tradition started with the term Cilk seems to continue.

It is possible that the dynamic parallelism currently developed as Cilk/Tapir will be assimilated into OpenMP. Unfortunately, OpenMP consists of hundreds of complier directives given by pragmas that make it much more complicated to use and syntactically uglier than the three keywords introduced by Cilk. Currently the gcc implementation of OpenMP supports dynamic parallelism with about 80% of the efficiency in my tests as the gcc implementation of Cilk. My understanding is that Tapir is ahead of both.

I'm hoping Cilk will survive. Given the Meltdown and Spectre, maybe Intel will not and their x86 processors soon be displaced by Shénwēi-manufactured versions of the DEC alpha CPU--or maybe the Pi Zero, to get back on topic.