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.

OffTopic > Compiler optimising tech

#157682 - simonjhall - Tue May 27, 2008 8:26 pm

I've been recently reading some of that old stuff that Chris Hecker did in the day for Game Developer Magazine and a few of interest to me are about the optimising ability of your compilers. He goes on to test a bunch of compilers (many of which don't exist any more) and tries to get them to generate the best code *without using assembly* with a bit of gentle persuasion.

http://chrishecker.com/images/a/ac/Gdmcomp1.pdf
http://chrishecker.com/images/d/db/Gdmcomp2.pdf

First article's about PowerPC code and the second is about Intel.
In these articles he talks about the steps that a compiler will perform in order to transform your code into the best meta code before it's turned into machine code and when you can do to make it easier/harder for the compiler to do its job.

After reading them I thought "ok, let's see how much compiler tech has advanced in the last ten years" and tried Visual C++ (.NET 2003) and a PowerPC GCC (4.something) with the some of the examples.
The biggest surprise is that many of the results are worse! The code generation was really poor! (obviously compiler optimisation has improved in other areas though)

Worth a read if you're bored.

This post was dedicated to all the losers out there who are convinced that the inline and const keywords allow your code to run in zero time
_________________
Big thanks to everyone who donated for Quake2

#157689 - silent_code - Tue May 27, 2008 9:16 pm

"zero time" big laugh! X?D
yeah, it's actually scary how much of the "rather recent" holy <youknowwhat> isn't true anymore. now think about how much (i mean much, not many!) people learn off of old tutorials on the net... scary i say!
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

#157714 - Maxxie - Wed May 28, 2008 12:32 am

On a qick look through Listing5 and 6 in the first pdf, i think he is missing, that the compiler has to expect that the different pointers (through the [][] and *) might be the very same dereferenced variable.

In the hand-optimization he is doing a change in the execution order (bundles all reads, sets writes to the end), which would cause different results of Listing5 and 6 if some pointeroverlapping would happen:
In Listing6 the compiler can expect that once it has read the data into a register that the source will not change by an interrupting write (until the next write happens at the end)

In detail: In Listing5 it has to make sure to update the read value after the write as it might be changed. Thus in Listing5, everytime pSourceVector[*] is used it has to fetch it's content again. It needs 3 reads for 3 (we know: equal) multiplications.
In Listing6 it can assume - because only writes only happen to local vars that were created after the pointers - that pSourceVector[*] keeps the same (it can't have changed within own code, and neither via concurrent events [as they are not volatile]) therefor the one read can be applied to three (the compiler knows: equal) multiplications.