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
Code: Select all
FOR i=1 to 1000000
NEXT i
END
Code: Select all
i=1000000
END
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.Digitaldreams wrote: ↑Sat Mar 03, 2018 9:25 amOn the topic of Arm assembler is there a good well finished one (IDE) for the PI that has good help files and tutorials etc
No it is not, at least not for any practical program of any size.
You've hit the nail on the head there.
Well NOW you've really done it. That's another one where you'll get very conflicting answers.Digitaldreams wrote: ↑Sat Mar 03, 2018 9:25 amis there a good well finished one (IDE) for the PI that has good help files and tutorials etc ?
I like that!ShiftPlusOne wrote: ↑Sat Mar 03, 2018 11:43 amMy approach:
https://sanctum.geek.nz/arabesque/series/unix-as-ide/
Thats the best advice.ShiftPlusOne wrote: ↑Sat Mar 03, 2018 11:43 amIn 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.
Try it for yourself, very educational.Digitaldreams wrote: ↑Fri Mar 02, 2018 7:06 pmAnyone tried a simple loop in all the current pi programming languages to see which is the fastest on a Pi Zero ?
That was true, and I often used to do just that - decades ago.danjperron wrote: ↑Sat Mar 03, 2018 12:17 pmDon'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.
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 .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.
This is not the sort of thing you worry about when using a high level language and a modern compiler.danjperron wrote: ↑Sat Mar 03, 2018 1:28 pmIn 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)])
Sorry, that doesn't make any sense at all.It can't be translated into C.
This is true! I can't use that code if I change something .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?
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.
Thats a well composed summary, thank you.ejolson wrote: ↑Sun Mar 04, 2018 4:15 pmThe 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.
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.
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.