Hi Patrick,

with your compiler-option the execution time decreases from over 800 sec with no compiler options to 240 sec. This is quite surprising for me, that the compiler options are responsible for more time differences than different systems itself !

So from my point of view the results of the benchmark are only comparable when the same compiler options are used on different systems, aren't they ?

Regards,

Peter

I think that the cpu speed is not the bottleneck, rather it's memory access. By most current benchmarks (see tomshardware.com, for instance), a 1.33GHz Athlon should be very close to if not faster than a 1.5GHz P4.

We have several dual-alpha (DS20 21264/667MHz) so I benchmarked these on a medium size (400k cells) Fluent problem with radiation and presumed pdf combustion. The alpha was running at about 65 iterations/hr while the P4 was running about 56 iterations/hr.

The P4 has the quad pumped 100MHz (effectively 400MHz) front-side bus while the older athlons only had a 100MHz front-side bus. The P4's also have the expensive RDRAM in them. I believe that bus speed has to be the issue. That would explain why the P4 is only 4 times faster than a P3 even though the clock speed ratio is higher. Now that the 266MHz fsb athlons with DDR are available, more benchmarking may be in order.

I know that compiler optimizations are a big deal too. I don't know if commercial codes like Fluent are well optimized or not, but I tend to assume that they are optimized for the Intel chips, maybe that leaves AMD in the digital dustbin.

You should not be surprised !. Compiler option are crucial for loop optimisations, double-precision alignment, etc.... Lately you may be right when you claim that the results of the benchmark are only comparable when the same compiler options are used on different systems. But also with the same compiler ?. Other influences come also from architecture : size of the cache, bandwith, etc...

Regards, Patrick