Slashdot Mirror
PCMark Memory Benchmark Favors GenuineIntel
javy_tahu writes "A review by Ars Technica disclosed that PCMark 2005 Memory benchmark favors GenuineIntel CPUID. A VIA Nano CPU has had its CPUID changed from the original VIA to fake GenuineAMD and GenuineIntel. An improvement of, respectively, 10% and 47% of the score was seen. The reasons of this behavior of FutureMark product are not yet known."
Is this like changing the user agent in a browser?
Pretty much, yes.
That should be AuthenticAMD, not GenuineAMD.
But that would be expecting editors to actually, you know, edit.
If anyone can come up with a better explanation I'd be interested to hear it.
TFA offers the following:
At the very least, this suggests some incredibly sloppy coding on Futuremark's part, as the company may be enabling or disabling CPU optimizations based on a processor's vendor name in CPUID instead of actually checking CPUID for SIMD support. In this case, PCMark 2005's memory subsystem test doesn't appear to be aware that Nano supports SSE2 and SSE3, and is instead running a decidedly less-optimized code path. There are two factors, however, that make this explanation a bit difficult to swallow.
First, there's the issue of timing. PCMark 2005 was released (obviously) in 2005, and was obviously coded with an eye towards supporting current and future processors. This is standard operating procedure for Futuremark, which always builds benchmarks designed to last for at least a year, and often two. VIA's C5N-T (Nehemiah) core may have only supported MMX and 3DNow!, but the C7 launched in 2005, and that processor supported SSE2 and SSE3 from day one. Even if proper extension support wasn't built into the first version of PCM2K5, we tested version 1.2.0, and that patch was released on or around 11-29-2006.
Second, there's the issue of performance when Nano is identified as AuthenticAMD. If performance between the AMD and Intel CPUIDs was identical, there wouldn't really be a story here, but it isn't, and that's curious. Futuremark could plausibly argue that VIA's C3/C7 processors weren't exactly on the radar back in 2004-2005, but AMD and K8 certainly were, and K8 launched with full SSE and SSE2 support, with SSE3 added in 2005.
There's more, but I don't want to quote the entire article.
There is no "I disagree" mod for a reason. Flamebait, Troll, and Overrated are not substitutes.
The CPUID instruction provides feature bits that software should use to determine which instructions are available. Using the vendor string is not a reasonable way of detecting the presence/absence of instruction set extensions like SSE.
My server
I'll give 10:1 odds that Futuremark simply compiled their benchmark with Intel's C++ compiler.
I wrote a detailed explanation back in 2005 about how the Intel C++ compiler generates separate code paths for memory operations to make AMD processors appear significantly slower, and how you can trick the compiled code into believing your AMD processor is an Intel one to see incredibly increased performance. See this article for additional details.
It's hard for thee to kick against the pricks.
CPUID can be intercepted so it shouldn't be a big deal to grab the call and return whatever you want.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Yes, it does: http://en.wikipedia.org/wiki/CPUID
The thing is, the x86 CPUID instruction gives you many different things in EAX/EBX/ECX/EDX depending on what you put into EAX before you execute it. The "GenuineIntel"/"AuthenticAMD" strings are what you get when you put 0 in EAX. When you put 1 in EAX, you get various feature bits in ECX and EDX, such as support for SSE/SSE2/SSE3. Any code worth its salt will base any decisions on those feature bits from CPUID function 1, not on the string you get from CPUID function 0.
The Phoronix Test Suite.
It's Linux only, but a CPU that performs better on Linux will perform better on Windows.