Author: Eugene Nalimov
Date: 12:08:29 08/07/03
Go up one level in this thread
Unfortunately, "clock per clock" rating methodology is wrong. Let's assume that corporation "A" made CPU that due to some design decisions (short pipeline, huge L1 cache, lot of large and comples instruction decoders that are on the critical paths) unable to achieve very high clock rate, though due to exactly those design decisions it delivers good performance at the clock rate it achieves. Corporation "B" (or should I call it "I"?) made different design decisions (e.g. long pipeline, small but very fast L1 cache, trace cache that keeps already decoded instructions, etc.) that allows much higher clock rates. Overall, on Spec2k those CPUs acheives similar performance (though microarchitecture of CPU "B" is several years older than of CPU "A"). But when you are starting to compare CPUs on "clock per clock" basis, you are badly hurting CPU "B". Yes, it cannot compete on equal frequency, because it was *designed* with high frequency in mind. Let's assume that you can somehow turn off majority of L1 cache in CPU "A", so that you can compare those CPUs with equal L1 cache. Will it be fair? No, because CPU "A" was designed for large L1 cache in mind (with smaller cache it probably can run at higher frequency). Why comparison of those CPUs at the same frequency is more fair? Thanks, Eugene PS. I believe you did not provide another interesting data: speed of your program running *on the same CPU* when compiled with 32- and 64-bit compilers. AMD64 runs 32-bit applications natively with high speed (unlike Itaniums), so this way you can measure just effect of 64- vs. 32-bit data and 16 vs. 8 registers. On August 07, 2003 at 08:23:26, Gian-Carlo Pascutto wrote: >On August 07, 2003 at 07:42:22, Joost Buijs wrote: > >>I don't understand where you get your specdata from. >>According to spec.org it looks like this: >> >>SPECint 2000 uni processor: >> >>Xeon 3.06 GHz. 1294 >>Opteron 1800 Mhz. 1170 >>Athlon XP 2200+ 1080 > >I've been quoting clock for clock performance throughout the thread (using >1.8Ghz baselines), not the raw scores, mostly because the 2.0Ghz Opteron >is available but not SPEC tested yet. > >From eyeballing the result, it seems the numbers you quote agree with >me that the 2.0Ghz Opteron is faster than anything else. > >Note that the Opteron number you quote is Intel C in 32 bit mode on Windows. >This seems to be faster than a native GCC 3 (they don't give the exact version >unfortunately) compile. Amazing - this means there is still a lot of room for >further improvement as the compiler gets better. I used the native GCC >compile numbers. > >The Pentium 4 was in a similar situation with Intel C 6 and 7 giving a >big performance boost to some programs (You can also see this in the SPEC >results). Unfortunately I haven't seen a single version so far that doesn't >crash when compiling Deep Sjeng, so those numbers mean very little to me. >GCC 3.2.2 on the other hand gives the exact same results in 32 bit Athlon >vs the 64 bit Opteron versions - no bugs there! > >-- >GCP
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.