Compiler Performance in modern CPU's

[Shalmanese]

Hi,

I got a friend who is tossing up between AMD and Intel primarily for coding and some heavy gaming on the side. Looking at the benchmarks from the usual suspects, there doesnt seem to be any standard benchmark for compiler performance. This is fairly important to him so do you reckon you could point me in the right direction.

Also, how does Bus speed, CAS, etc affect compiler performance.

 

[Soulkeeper]

i'm sorry I looked for like 45minutes
i know there is a site out there that benchs all the latest processors with both the MS compiler and the Intel compiler
and also there is another site http://www.linuxhardware.org/ that compiles the kernel on a linux system if you plan to use linux or the gcc compiler

from what i remember the athlons edge out the P4 with compiling code
fast memory and lots of cache is always good
low latencies on the memory make a large difference, much larger than in games
as far as fsb speed goes the faster the better just like memory bandwidth


hope i helped

 

[Soulkeeper]

here is a good graph
this shows an athlon xp 2400+ on a 266mhz fsb with memory running at 333 or 266 on a kt333 system compared to a P4 2.4 and 2.8 on an i845 system
the athlon seems to edge it out

as for the Intel and Ms compiler, i'll stop back if i see specific benchmarks
but athlons seem to still stomp the P3/P4 on compiling code

 

[Cerb]

...you mean the P4? It's a lower-is-better graph .
Although the differences are minimal.

 

[KF]

>..you mean the P4? It's a lower-is-better graph .
>Although the differences are minimal.

For a third opinion on that simple graph (less is better): The P4 2400 looks poor in comparison to an Athlon 2400+, although it is a mystery why. I would think it is more dependent on I/O, the P4s advantage, than processor power. When we go to to P4 2800 533FSB, the Athlon 2400+ looks poor.

But the total time involved is about 3 minutes. According to what I have read from programmers, what they are really concerned about is compiling that takes hours. In 3 minutes, they are barely getting things loaded into memory.

 

[Shalmanese]

Actually, 3 minutes ia a incredibly long time to wait. When you are developing, you might want to see how a single change is affecting your code. You might be compiling once every minute or so.

 

[zephyrprime]

According to what I have read from programmers, what they are really concerned about is compiling that takes hours. In 3 minutes, they are barely getting things loaded into memory.

Any compile that takes that long would warrant splitting up the job between multiple processors/computers. A 3 minute compile is pretty long actually.

 

[ChampionAtTufshop]

Originally posted by: Shalmanese
Actually, 3 minutes ia a incredibly long time to wait. When you are developing, you might want to see how a single change is affecting your code. You might be compiling once every minute or so.

yeah
during my ever so limited c++ days in comp sci, i would change one line or two of code, compile/run (take 10-15secs) , and "50 errors" lol
...3hrs to compile to find out you have 500 errros would SUCK
lol

if its taking that long, then you should look into a "farm" type of thing

 

[Cerb]

...or a dually. Dual Xeon or AMD systems would do quite well (and both are equally castrated when it comes to memory bandwidth)

 

[laugh]

i think a P3 tualatin can be on par with a P4 2G. Tualatin is a lot cheaper considering the highly overclockable celeron w/ 256K cache. The P3 w/ 512K cache is even faster.

Dunno why P4 is so weak -- it's just a high frequency maniac. Clock speed wise, P4 is no good even for Northwood.

 

[zephyrprime]

I tried to find some comparisons but I couldn't find anything that wasn't already mentioned. I did find this though (which isn't quite on topic but oh well):
comparison of compilers
Despite it's fancy math, it's testing methodology concerning the basic settings and libraries linked in by the various compilers is lacking as is information concerning the specific programs being compiled.

It's interesting to see that compile time increases exponentially with increasing line count. Perhaps this is due to cache size? I wonder how a Xeon would perform.

 

[KF]

People seemed to object when I said it could take many hours to compile a real program.

>Actually, 3 minutes ia a incredibly long time to wait.
Anybody look at the graph link? It took 3 minutes to recompile the linux kernal. I suppose it is broken into many sub sections. Regardless, it is likely that the time to complete the work was mostly spent locating and loading the pieces from the HD.

>When you are developing, you might want to see how a single change
> is affecting your code. You might be compiling once every minute or so.

I'm not much of a programmer, but I do some programming. When I recompile my "main", it takes longer to move the mouse to the recompile button than to get the error reports back. If I do a complete rebuild, it might take 10 seconds, and it seems to me that is mostly Windows swapping things around in memory and on the HD.

A Real programmer I used to follow online laughed when someone thought a million line program was a major undertaking. The programmer thought it would take him personally only a few weeks to generate a million lines. (He would be putting it together from previous work and purchased code packages, not typing it all personally.) Admittedly I haven't followed any of this for a couple of years, but it did take many hours to do a complete recompile of several million lines of code. This fellow had enough RAM to do it all in a RAM disk. He didn't just wait around for it to complete, because he had plenty of work he could accomplish while waiting.

If a program is broken down into appropriate pieces, as it should be, getting the result of a change of one line shouldn't take long, because most of the pieces have already been done, and all that happens is relinking. When you do a complete rebuild with optimization, it will take a while.

 

[Armitage]

Originally posted by: KF

If a program is broken down into appropriate pieces, as it should be, getting the result of a change of one line shouldn't take long, because most of the pieces have already been done, and all that happens is relinking. When you do a complete rebuild with optimization, it will take a while.

I'll second this. A good build system should only recompile relevent sections when those "one line" changes are made. This is often a single file which is ussually very fast. A change to a header file that is included in many source files will require the rebuild of all those source files as well which could take awhile.

For a large program the linking step can take a long time as well. Ussually significantly less then a clean build of the code, but maybe significantly longer then the compile step for your "one line" change.

So, even the "one line' changes can add up to alot of frustration

Of course, a clean build (recompiling all source files) for a large project can take a long time ... try building KDE from source sometime! This can be a real PITA when your experimenting with compiler options for optimization and such, although you can often isolate chunks of code you expect to be bottlenecks for this kind of testing. An SMP system can help greatly, and ussually requires no changes to the build system (add the -jnum_cpu option to make on unix builds). If that's still to long, there are tools that let you distribute the build process across a cluster as well, but that's ussually a bit more involved.

Back to the original poster ... is your friend primarily concerned with compilation speed, or performance of the compiled code?

 

[zephyrprime]

The programmer thought it would take him personally only a few weeks to generate a million lines. (He would be putting it together from previous work and purchased code packages, not typing it all personally.)

You can't include other packages when considering line sizes like that. Anyone can just use a bunch of packages and claim a huge line count but it's doesn't mean your program is actually big at all.