[matt92tau]

Originariamente inviato da suneatshours86

santo iddio. veramente drammatica la situazione. è peggio di quanto pensassi


" Swap CentaurHauls for AuthenticAMD, and Nano's performance magically jumps about 10 percent. Swap for GenuineIntel, and memory performance goes up no less than 47.4 percent. This is not a test error or random occurrence; I benchmarked each CPUID multiple times across multiple reboots on completely clean Windows XP installations. The gains themselves are not confined to a small group of tests within the memory subsystem evaluation, but stretch across the entire series of read/write tests. Only the memory latency results remain unchanged between the two CPUIDs.

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.

None of this constitutes proof of wrongdoing, but it flies in the face of Futuremark's neutrality claims. Bad code is a fact of life, but companies that write benchmarks for a living and sell those benchmarks as evaluation tools have a responsibility to ensure that their software delivers the neutral framework that it promises. Based on the information I've gathered thus far, it seems Futuremark may have created three paths—one for Intel, one for AMD, and one generic "other" path. There's nothing wrong with optimized code paths, but our results would seem to indicate that some paths are decidedly more optimized than others. "

Viene quindi da domandarsi: perchè anche solo suite di test gratuiti debbano ottimizzare in modo non equo i codici amd, intel e via?


siamo tutti consapevoli del fatto che la risposta sta in un semplice simbolo....


$

Quoto