Arm Assembly Or High Level.. How Much Of A Performace Difference?


letsridebmx104

Still Fresh
Joined
Sep 18, 2007
Messages
78
I want to start programing for my gp2x and I was wondering by how much is ARM assembly faster/ more efficient then a high level language?

Goals

- touch screen Drsnes ;)
 
Depends on exactly what your writing and how you write it. Easy to read assembler can be much worse than compiled code (Compiler can juggle registers and ensure the output value of one register isn't used in the next instruction for example to help the pipeline).

The advice given is therefore to write in a high level language such as C, profile your application, and then analyse the slow parts and see if you can spot a way of optimising the code (either in the same high level language, or in a lower level).
 
Squidge said:
Depends on exactly what your writing and how you write it. Easy to read assembler can be much worse than compiled code (Compiler can juggle registers and ensure the output value of one register isn't used in the next instruction for example to help the pipeline).

The advice given is therefore to write in a high level language such as C, profile your application, and then analyse the slow parts and see if you can spot a way of optimising the code (either in the same high level language, or in a lower level).
Ok so if I use C++ where can I get a complier to compile .gpe?
 
Last edited by a moderator:
'.gpe's are normally just elf binaries. Pretty much any arm-linux toolchain can make them.
 
To give you an example of how much faster ASM is than C:

http://wiki.gp2x.org/wiki/Fast_32-bit_to_1...ramebuffer_blit

Not much, sometimes ;) And that is with a lot less overhead than the SDL generic blit. A_SN's version that didn't unroll the loop and did not use LDM/STM, and also, like mine, didn't have a lot of SDL's overhead that allows blits of all dimensions and bpp's, still was .020ms slower than straight SDL!!

However, Robin Watts's libTremolo ASM OGG decoder is claimed to have a 10-15% speed increase over libTremor (written in C). I haven't verified this but he's an ARM ASM guru so I don't doubt it.
 
Squidge said:
The advice given is therefore to write in a high level language such as C, profile your application, and then analyse the slow parts and see if you can spot a way of optimising the code (either in the same high level language, or in a lower level).
What he said.
 
Last edited by a moderator:
I think it's quite pointless to measure speed differences between simple programs in C/asm
C optimizes pretty much all it's possible in simple code, but when the code gets complex, then you may have a lot of optimizations in asm, but asm is too much work, so I would recommend you to just develop things like main-loops and the most called routines, for procedures used 100 times a second it will spare almost no advantage over all the work employed.

And of course, profiling is your best friend in these cases.
 
For heavily computationally bound code even "easy to read ASM" will often perform much better than the compiler because GCC is actually pretty bad at it. When converting the alpha pass in gpSP from C to ASM the result was over 200% faster. There's very little scheduling involved in ARM9 to "help the pipeline", the only place where a stall can happen is after ldr's, so you should watch out for those (and the compiler does), but this only makes so much of a difference unless your code is heavily memory bound. There are no register dependence hazards because it uses register forwarding.

For memory bound code involving streaming a lot then it might not make a difference because you'll be thrashing through cache anyway. GP2X's memory subsystem is slow so code like this will always be bad - if you have any redundancy you're much better off rearranging things to fit in the cache (so that means if you make 4 passes on the framebuffer do a few scanlines at a time for each pass)

For relatively simple code then GCC can probably do as well as someone writing the ASM code. And you can sometimes make the code easier for GCC to deal with, but the end result is uglier C code.
 
Back
Top