Re: [Bug-gnubg] question: gnubg performance and benchmarks

[Ingo Macherius]

>> My question is that I am planning to buy a new PC and my only real
>> criteria is how fast it will run GNUBG rollouts. So, are there any
>> thoughts on:

>> Processor? - AMD/Intel?

> They're about equal, I believe. Correct me if I'm wrong.

It depends very much on the compiler you use and how well it can utilize the 
SIMD extensions of the P4/AMD-XP processors. See this list, thread "benchmarks, 
speedups, experiments" for in detail studies of at least these compilers: Intel 
8.1, GCC 3.4.1 and GCC 4.0.0. On my test machine (address@hidden), depdending 
on the compiler and processor optimizations I have a range between 20000 to 
32000 eval/s. Key are the SIMD extensions, SSE1 and SSE2 in Intel-land and 
3DNow and 3DNowExt in GCC-land.

AMD supports SSE2 only in the latest processors (AMD-64), the widely spread 
AMD-XP family has support for SSE(1) only. On my P4 desktop, SSE1 manages 27000 
eval/s and SSE2 manages 32000 eval/s. On my AMD-XP 2000+ notebook I get 27000 
eval/s, so SSE for AMD is pretty performant (lower Ghz and still as fast as my 
P4 using SSE). I'm aware of a address@hidden Ghz that manages about 37000 
eval/s for an Intel compiler compiled binary. I can not judge the AMD-64 or 
AMD-Opteron, but I think it may well be as fast or faster using only SSE 
compared to a P4 using both SSE and SSE2. Look for benchmarks with SSE1 and 2 
and floating point operations, this is where gnubg spends it's time :)

> > Operating System (I probably have to use XP sadly for work
compatibility)?

> Not much difference here either.

At runtime I don't think it's a big difference. At compile time the Intel 
compiler would be free for non-profit on Linux and costing USD 399 for windows, 
so that may be an argument for Linux.

> The big difference is the compiler that compiles the program. I believe
> Ingo is working on this and I think his study will gain some speed. Ingo?
> How's it going?

The fastest binary I managed to build so far was done using the Intel C++ 
Compiler 8.1 with full optimizations and using the SSE2 extensions. I have no 
results SSE3 or the AMD 3DNow extension family. The latter are supported by 
gcc, but the Intel compiler won't support AMD extensions for obvious reasons. 
Nevertheless, the main impact on speed is vectorization of SIMD commands, i.e. 
parallel math units. This is where gcc 3.4 really sucks. My theory is that if 
gcc 3.4.x fails so badly to vectorize SSE, it will also fail to do the same for 
the similar 3DNow commands. So I would not recommend using gcc 3.4 for fast 
binaries at the moment. It looks like the upcoming gcc 4.0.0 has better 
SSE2/3dNow vectorization support, but there has been no release yet, just 
snapshots. I tried one and the gnubg binary produced by this gcc 4.0.0 dumped 
core.

Thus my recommendation for a fast/cheap rollout machine today would be an Intel 
P4 or P5 ("Prescott") with SSE2 or SSE3 running Linux and using the free Intel 
C++ compiler for Linux. 

Ingo (not paid or whatever by Intel, btw, just a sped freak)

[1] http://www.intel.com/software/products/compilers/clin/index.htm

______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193