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."

Comments

Re:Money

[SimonGhent]

Easy. Intel paid them to make it that way.

If anyone can come up with a better explanation I'd be interested to hear it.

CPUIDs

[bestinshow]

VIA's is "CentaurHauls"
AMD's is "AuthenticAMD"
Intel's is "GenuineIntel"

There's no "VIA" nor is there "GenuineAMD".

Clearly PCMark2005 is buggy (at the best) and cannot be used to compare different CPU families in this test. At the worst it is intentionally flawed, and shouldn't be used at all.

It's a shame that not one VIA Nano review benchmarked the built-in Padlock functionality. Not one OpenSSL benchmark.

Re:Money

[JamesP]

Yes, I remember that...

But why would icc make AMD better than "no name" beats me.

Re:Money

[Fumus]

What I don't get is why game developers don't release freeware benchmark versions of their engines.
Saying that a config has 9000 points is pretty much useless. Saying that it gets an average of 40FPS in the UT3 benchmark at high details, and 1680x1050 is much more informative.

Unfortunately, this also is a little bit more complicated, and as we know everything simpler is more popular with the dumb masses.

Re:Money

[Bert64]

If your benchmark tool is going to use multiple code paths, then they should be configurable, so that you can benchmark different systems both using the same code and more optimal code. That way you'd get an idea of how much speedup various features provide.

As an example, john the ripper's SSE2 support for cracking DES - on a core2 the SSE2 version is considerably faster and compiling the C version never comes anywhere close regardless of compiler and flags, but on an AMD compiling the generic C code with appropriate flags and a modern version of gcc produces slightly faster code.

Running the SSE2 ver on a 2.3ghz core2 quad achieves about 2mil c/s per core, while a 2.3ghz amd phenom yields about 1.6, but compiling the C source with various flags and gcc versions makes amd slightly faster, while the core2 is nowhere close.

Agree; but could we formalize auditing more?

[KWTm]

The problem with this argument is that with open source software, you don't just have to trust a single random guy for your information. When the source is open, it is often the case that MANY people in the online community will examine the code, and through discussion there emerges a consensus which is far more reliable than the opinion of just one random guy. That isn't to say that the community as a whole is never wrong, but it's vastly more trustworthy and reliable than just some $randomInternetDude.

I agree with you.

I was wondering if there is some way we can get code audited by the community on a more formal basis, perhaps with a bounty system and a reputation system, so that one might donate to get the KDE4 code audited by me ($10), or some KDE contributor ($300), or Linus Torvalds ($10000). Then these people could develop a formal reputation system, like + or - votes on SourceforgeAuditVoting.org. They'd use their PGP signature to sign the audits.

Or something. I would view this as the next phase of the open source economy. Eventually companies might hire people with good reputations, to audit their own intra-company code.