C. Bergstrom wrote: > While for my own selfish reasons I'm happy AMD may have some chance at > a comeback, but... I caution everyone to please ignore SPEC* as any > indicator of performance..
The non-profit Standard Performance Evaluation Corporation and volunteers who work for it (including me) would be pretty dismayed that anyone believes that it has no relevance to performance evaluation. I think Killion's reference to " Some SPEC results are being posted on http://www.spec.org/cpu2006/results/res2010q1/ " was entirely appropriate and useful for this thread about CPU performance. In this forum, people rightly and most-often quote SPEC rate metrics (e.g. SPECfp_rate_base2006 ) which test the performance of all sockets/cores on a system. The speed metrics (SPECfp_peak2006, SPECint_peak2006) are more difficult to interpret, since with many of the codes you are evaluating single-core, single-thread performance. But auto-parallel compiler flags are allowed, and not all compiler vendors have been equally successful in making those parallel flags work on the SPEC suite. So on the peak speed metrics you may be comparing one core of one CPU brand with multiple cores of another CPU brand if you are not careful. Certainly the SPEC benchmarks are not perfect. There is a certain time period needed to develop a new version of the SPEC CPU suite, as you see from the names of the most recent versions: CPU95, CPU2000, and CPU2006. As you get more years since the last version, the CPU and compiler vendors have had more time to optimize to the current suite of benchmarks. Those vendors who have more resources can spend more on this optimization to the suite. But a new benchmark suite is in development (I am not part of that effort this time, so I don't know when it will be available ... I know they are doing some ambitious things), and it will, once again, be more of an indication of CPU/compiler performance without years of optimization opportunity. But still, for a broad-based applications-based benchmark suite to evaluate single-system & CPU performance, it's tough to beat SPEC CPU2006. And for multiple-node, cluster performance, I would like to plug SPEC MPI2007. Certainly if you have the time and resources to benchmark your apps. with several systems and compilers, that is the most relevant data. That's not a luxury everyone has. And even if you can do that, the SPEC results help to narrow the set of CPUs/systems you might want to evaluate in more depth. -Tom > This will be especially true for any > benchmarks based on AMD's compiler. Your code will always be the best > benchmark and I'm happy to assist anyone offlist that needs help > getting > unbiased numbers. > > Best, > > ./C > > > #pathscale - irc.freenode.net > CTOPathScale - twitter > _______________________________________________ > Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin > Computing > To change your subscription (digest mode or unsubscribe) visit > http://www.beowulf.org/mailman/listinfo/beowulf _______________________________________________ Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
