gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

ASM > How much faster is ASM vs. C

#1840 - regularkid - Fri Jan 24, 2003 6:01 am

I'm just starting to get into assembly for the GBA and have a quick question: How much faster is assembly vs. c code? Isn't c code just translated into ASM eventually? Why is assembly so fast? As an example, if I were putting a pixel on the screen in mode 4, how much faster would it be if I used asm over c code? Thanks!
_________________
- RegularKid

#1842 - XeroxBoy - Fri Jan 24, 2003 8:01 am

I can't say exactly how much faster ASM is, but the reason that it's faster is because the programmer has complete and total control over what's happening. The compiler does know exactly what you're trying to do, and may generate extrainious code that merely slows down your code.

#1847 - Daniel Andersen - Fri Jan 24, 2003 11:08 am

According to Structured Computer Organization by Andrew S. Tanenbaum coding in assembly can be as much as 3 times faster. Though, this is only when using clever programming and also it takes much longer time to write assembly language (about 5x).

Due to the fact that 1% of your code often tend to be responsible for 50% of the execution time and 10% for 90%, the ideal thing to do is to code the 1% or 10% in assembly language and the rest in a high-level language like C.

Personally, I like write my code in assembly language but when writing larger projects, a game for instance, it is very inflexible as it is harder to structure; so I recommend you writing mostly in C and then for the critical innerloops (mabey) do some assembly.

Daniel Andersen

#1850 - velvetfr - Fri Jan 24, 2003 2:04 pm

All,

I am using C and ASM ... I usually rewrite all the core functions (most called ones, and the smallest ones) in pure assembly language, and the rest in C. Just for an example, I have in my library a function to set
a pixel in mode 3, with the prototype below:

uint16* video_setpixel_mode3(uint16* frame, uint16 x, uint16 y, uint16 rgb);

This function has been wrote in C and assembly language. It took me 4 instructions in assembly (ARM code used), and for the C compiler
(with -O3) it took 10 instructions in assembly (and without optimization flags, I do not even want to think about, but it took about 30 instructions).

So just to give you an impression, assembly+brain more performant than
a C compiler. Also, all that his less portable of course, but at which price (having something smaller in size and faster at runtime).

#1855 - Splam - Fri Jan 24, 2003 4:04 pm

I've personally seen increases of up to 5x or 6x going from C compiled to thumb running in rom, to hand coded arm running in iwram, and that was after optimising the hell out of the C routine. As long as you know your asm inside out and can optimise for register usage etc then it's always worth it :)

#1856 - joet - Fri Jan 24, 2003 4:29 pm

And always bear in mind that it's well worth getting logic and everything working first before attempting any optimisation - otherwise you spend ages optimising in ASM only to end up using a completely different algorithm because your needs have changed ...

#1857 - Splam - Fri Jan 24, 2003 4:44 pm

I tend to write a routine in C first as it's so fast to code in, then when the logic is worked out I can see exactly how many registers are needed and the flow of the code (NOT by looking at the asm the compiler produces as it's usually dross), then rewriting in asm is a lot faster because you don't get half way through and run out of registers ;)

#1861 - regularkid - Fri Jan 24, 2003 6:36 pm

Cool! Thanks, that helps. I just wanted to make sure that converting my rendering code from C to ASM would be worth it. It sounds like it would be. Thanks!
_________________
- RegularKid

#1994 - chrisbtoo - Mon Jan 27, 2003 1:21 pm

regularkid wrote:
I just wanted to make sure that converting my rendering code from C to ASM would be worth it.


A good place to start might be to get the compiler to dump out the assembler "source" for your rendering code. If you're using gcc, pass the -S to the compiler (remembering to add in optimisation flags too (-O2, for example).

That way you can get a reasonable handle on the job that the compiler is making of your code, and you can use it to pinpoint the areas where you need to focus your attention.

Remember: simply recoding in assembler isn't a guarantee that your code will go faster. You actually have to make a better job of it than the compiler :-)

#1996 - Sweex - Mon Jan 27, 2003 1:57 pm

IMHO you can "help" the compiler compiling your functions into fast assembly code. The use of bitshifting for instance, could save you a multiplication in some cases. If you're programming cleverly in C/C++ you can help the compiler a hand. Still, it won't beat the "assembly+brain" performance as velvetfr so nicely put it!

#4513 - delbogun - Wed Apr 02, 2003 10:37 am

is there a general rule on what parts is better to use assembly than c?

#4517 - Lord Graga - Wed Apr 02, 2003 11:08 am

delbogun wrote:
is there a general rule on what parts is better to use assembly than c?


Usualy, it doesn't matter in 2D games like RPG's, platformers, etc, etc.
Where it REALLY matters is when playing music, rendering 3d and making tiny stuff to fit in little space (1K compo's, lame intro's, etc.)

#4783 - MrMr[iCE] - Wed Apr 09, 2003 4:23 pm

Sometimes you dont even need to convert to asm. If you're not good with asm, letting the C compiler generate ARM code and stuffing that code into IWRAM is a huge improvement. If thats not enough, then going to asm, coupled with iwram, will be a very fast solution. Also keep in mind lookup tables that are accessed a lot will speed up code a bit if they are stored in IWRAM.
_________________
Does the corpse have a familiar face?