Re: CPU synthetic benchmark
Ron Johnson put forth on 10/14/2010 2:28 PM:
> On 10/14/2010 01:52 PM, Martin Spinassi wrote:
>> Hi list!
>>
>> I'm searching for some good CPU synthetic test. I've found a few, but
>> their last update where from ~1996, and don't know if they are the right
>> tools to test modern CPU chips.
>>
>
> The only problem with old code is that it might not compile with modern
> GCC.
This is minor. The bigger problem with benchmark code from the mid 90s
is that all the floating point code targets the 80 bit x87 FPU and IEEE
754 data precision format. A realistic FP performance test of modern
x86 CPUs is going to use the 128 bit wide SIMD vector pipelines
(SSE,2,3,4). The performance difference between the two FPU pipelines
is going to be huge, a factor of 3 at minimum and possibly up to a
factor of 8 or more. This is because the x87 FPU isn't pipelined and
there are far fewer registers available, and it can't process arrays in
a single instruction.
> Otherwise, the Byte Unix Benchmark, Dhrystone, Whetstone & LINPACK are
> as (in)valid today as they were 30 years ago.
AFAIK, the first 3 of these you mention haven't been updated in well
over a decade. BYTE Magazine ceased publication in 1998. The modern
versions of LINPACK do take advantage of the SIMD pipelines in modern
x86(64) CPUs so they are valid tests today. The TOP 500 project uses
parallel LINPACK results to rank the 500 fastest supercomputers in the
world twice yearly, and the bulk of those systems use x86-64 CPUs.
The SPEC CPU tests at http://www.spec.org are the "default" industry
standard for measuring CPU performance, however, the code is not open
source, and a fee is required AFAIK to get access to it.
If you're really wanting to get real comparable performance numbers for
your CPU, I'd suggest you simply browse the SPEC CPU results pages
instead of attempting to run benchmarks on your system. There are
results published from multiple vendors systems for many/most CPU models.
http://www.spec.org/cpu2006/results/cpu2006.html
(note: the above page is large and may take a while to load)
--
Stan
Reply to: