Futuremark and CPUID

[Florin]

This memory benchmark test result from PCMark 2005 seems a tad curious.

Although the article focuses on the likelihood of the benchmark picking the wrong code path based on the CPUID value, I wonder if synthetic benchmarks like these should be using multiple code paths in the first place.

While it may be considered a useful concept to use optimisations that play to the benefits of each platform, it seems to me that the resulting benchmark scores should note that a particular path was used.

Aside from that issue, I'm liking Nano. After all this time, who would've bet on any processor from VIA looking as strong as this compared to the competition?

 

[Skrying]

Is it really though? If you check out Tech Report's article where they compare the Atom and Nano against a Pentium M the Nano suddenly seems a lot less impressive. You would have expected it to actually beat the Pentium M consider the rather large development gap and minor power consumption gap. Though Nano's platform might progress, and hopefully that's true, it just seems like both it and the Atom were brought out slightly to soon and not with a mature base platform.

 

[nutball]

My reading of that article was that they were alleging multiple code paths in the application itself, which would be somewhat off colour. Are they so sure it's the application and not the compiler which is generating multiple paths?

 

[pcchen]

To my understanding, a possibility for multiple code paths using vendor IDs is about special CPUID informations. For example, information about cache sizes are not "standardized," so if an application wanted to optimize for cache sizes, it needs to code for different vendor IDs to get the correct cache size. At least this is how it used to be.

 

[Humus]

That would only be a problem if the CPU didn't support all CPUID functions. Everything is well defined, it's just that Intel and AMD has introduced separate CPUID functions for some stuff, but these days both AMD and Intel CPUs support most of the other vendors functions. So unless Via's CPU doesn't support a lot of these functions (which I find unlikely) there should be no problem getting all info you need in a vendor-agnostic fashion. Using the CPU vendor name to select paths should not happen in any reasonably written application, and certainly not in a benchmark. If you do you're making assumptions that could easily turn false for the vendor you optimized for in the next generation. You may in fact deoptimize for it.

 

[pcchen]

The problem is, if you are writing a program which has to be run well on most computers, you can't just "assume" the CPU supports what you think it should support. Therefore, the safest way is to check vendor strings. For example, maybe VIA's new CPU does support every CPUID functions commonly supported by Intel and AMD's CPU. However, if your program assumes this, when someone runs your program on a, say, old Transmeta CPU, it may crash.

 

[ShaidarHaran]

The problem is, if you are writing a program which has to be run well on most computers, you can't just "assume" the CPU supports what you think it should support. Therefore, the safest way is to check vendor strings. For example, maybe VIA's new CPU does support every CPUID functions commonly supported by Intel and AMD's CPU. However, if your program assumes this, when someone runs your program on a, say, old Transmeta CPU, it may crash.

At what point do devs just say "ok, enough is enough - if your CPU doesn't support SSEx, you have no business running our software anyway so **** you"

 

[pcchen]

Well, of course there would be some point for that. For example, most new programs probably won't check for MMX support anymore. I mean, they should still check for MMX support, but they may just stop working if it runs on a CPU without MMX. You don't design a separate code path for non-MMX CPU anymore. SSE is also very close to this, as most computers still in use now have support for SSE.

However, it's a bit different. There are very reliable way to detect MMX and SSE support, so there's no need to check for vendor strings. However, querying for some information (such as cache size, cache line, etc.) through CPUID was not as commonly agreed until recently, so it's still safer to check vendor string before assuming anything.

 

[Humus]

The problem is, if you are writing a program which has to be run well on most computers, you can't just "assume" the CPU supports what you think it should support. Therefore, the safest way is to check vendor strings. For example, maybe VIA's new CPU does support every CPUID functions commonly supported by Intel and AMD's CPU. However, if your program assumes this, when someone runs your program on a, say, old Transmeta CPU, it may crash.

No, the CPUID instruction was designed to be futureproof. You pass your function to EAX. EAX=0 is always supported and returns the VendorID and the highest supported function. So you don't assume certain functions are supported, instead the instruction tells you exactly what you can query. So you only query at most up to highest supported. Under no circumstances should there be a crash if your code is correct.

 

[pcchen]

Actually it's not that simple. Yes, it was designed that way, but then AMD introduced their own "extended CPUID" for their own functions. Then there's a period where Intel and AMD have different support of CPUID, not to mention Cyrix (later VIA) and Transmeta.

Now the extended CPUID is better standardized but it's still not as simple as it should be.

 

[Humus]

But the extended CPUID functions work the same way as the standard. Only difference is you pass EAX=0x8000000 first, and receive the highest extended function supported. There's no difference in how it works between vendors.

 

[pcchen]

Mostly, yes. But there are minor differences. For example, some K7 (Duron?) incorrectly report its L2 cache as 1KB, and some VIA C3 processors report its L2 cache size in different format. These are mostly unfortunately bugs, but they do exist.