Tobias Burnus wrote: > Toon Moene wrote: >>>> Can somebody with access to SPEC sources confirm / deny and file a bug >>>> report, if appropriate? I just started working on SPEC CPU2006 issues this week.
> Seemingly yes. To a certain extend this was by accident as "-msse3" was > used, but it is on i586 only effective with -mfpmath=sse (that is not > completely obvious). By the way, my tests using the Polyhedron benchmark > show that for 32bit, x87 and SSE are similarly fast, depending a lot on > the test case thus it does not slow down the benchmark too much. Certain AMD CPUs had shorter latencies for scalar single precision sse, but generally the advantage of sse comes from vectorization. > > If I understood correctly, the 32bit mode was used since the 64bit mode > needs more than the available 2GB memory. Certain commercial compilers make an effort to switch to 32-bit mode automatically on several CPU2006 benchmarks, as they are too small to run as fast in 64-bit mode. > > Similarly, the option -funroll-loops was avoided as they expect that > unrolling badly interacts with the small cache Atom processors have. > (That CPU2006 runs that long, does not make testing different options > that easy.) I'm surprised that spec 2006 is considered relevant to Atom. The entire thing (base only) has been running under 10 hours on a dual quad core system. I've heard several times the sentiment that there ought to be an "official" harness to run a single test, trying various options. > I would have liked that the options were reported. For instance > -ffast-math was not used out of fear that it results in too imprecise > results causing SPEC to abort. (Admittedly, I'm also careful with that > option, though I assume that -ffast-math works for SPEC.) On the other > hand, certain flags implies by -ffast-math are already applied with -O1 > in some commercial compilers. SPEC probably has been the biggest driver for inclusion of insane options at default in commercial compilers. It's certainly not an example of acceptable practice in writing portable code. I have yet to find a compiler which didn't fail at least one SPEC test, and I don't blame the compilers. There are dependencies on unusual C++ extensions, which somehow weren't noticed before, examples of using "f77" as an excuse for hiding one's intentions, and expectations of optimizations which have little relevance for serious applications. > > David Korn wrote: >> They accused us of a too-hasty release. My irony meter exploded! Anyway, a fault in support for a not-so-open benchmark application seems even less relevant in an open source effort than it is to compilers which depend on ranking for sales success.
