The real problem with determining IPC is that it isn't set. It can vary wildly between different programs. For example, Quake 3 might end up with an IPC of 1.6 on P4 and 1.8 on Athlon, but then Return to Castle Wolfenstein might have IPCs of 1.3 and 1.5. Throw in the fact that certain applications are completely bottlenecked in areas other than the CPU (i.e. on RAM, hard drive, graphics, etc. performance), and IPC becomes even more difficult to quantify.

Then you throw in the problem of chipsets, as Pumpkin pointed out, and it becomes almost useless. A P4 with only 256K L2 cache running at 2.8 GHz on an 800 MHz FSB with dual-channel RAM would likely beat out a P4 with 512K cache running at 3.06 GHz on a 533 FSB with single channel RAM by a decent margin. What are the "model numbers" going to be, were such chips to actually exist?

In Intel's defense, at least it sounds like they're saying the model names are really there as a guideline for the "Dummies" out there looking at computers, and they will still continue to list the GHz, Cache, FSB, etc. of their CPUs. Thankfully, most resellers of AMD CPUs also list this information. AMD almost went the route it sounds like Intel is going to take with their Opteron and Athlon FX lines, and I find the "model names" to be much more preferrable to "3200+".Reply

phantom505: Not to sound like a lameass Intel fanboy, but you are wrong on a few things. Intel beat AMD to 90nm. AMD still has no 90nm chips. Intel cpu's could use DDR chipsets from VIA for the Pentium III roughly at the same time they were introduced for the Athlon (again from VIA). Historically (until Prescott), Intel chips have had a lower power consumption than equivalent AMD chips, especially in the mobile arena where power consumption really matters. Yes, lately it seems like Intel has been following AMD with x86-64 and now the new processor rating system. It was pretty much inevitable that Intel would have to do those things. Whether they continue to follow is anyone's guess. Reply

Face it, there is not good way to describe processor speed with the exception of some sort of somewhat hokey benchmark like AMD uses. People are entirely too critical about that. They are doing their best to give consumers a pretty good idea of where their processers lie.

Unlike AMD, Intel that decided to ride out the lie as long as possible now finds itself having to get line with AMD, yet again. Sort of interesting how that keeps happening to follow AMD on almost EVERYTHING, DDR, transition to 90nm, x86-64, power consumption, the list goes on. AMD follows, what? SSE, SSE2, SSE3, just because otherwise Intel with their highly optimized software would run almost as fast. So as long as you make the software specifically for Intel then of course it will run better on say a P4 vs a K8. Personally I can't wait for them to declare that they were the first to use SOI and on chip memory controllers.Reply

Eman #24, I didnt say I liked it('MHz is liked because it is an absolute index'). In fact I've never seen Intel push it either nor AMD rubbish it (although indirectly they promote IPC). I've only heard on the web hearsay and anecdotal evidence that higher Mhz is better for sales. Personally I am not sure of the truth of this. But, like you, I prefer the MHzxIPC index (first proposed to my knowledge by Abraxas). However as others have stated in these posts, IPC is more difficult to quantify than clockspeed which is an absolute (WYSWYG- non-debatable). As you suggest the FTC could set the standard. I think it should be taken up and pushed by AT (known P4 lovers) initially.Reply

Pumkinierre, you stated "MHz is liked because it is an absolute index". How exactly is that the case?

About the only thing which can be said for MHz/GHz is that it is accurate for similar architectures since one half of the IPC x GHz product is the same for both processors (the same would be true if the clockspeed was the same and the IPC was varied).

The only other thing that can be said for clockspeed is that Intel marketing loved clockspeed when that is all their processors could claim (certainly in many cases it wasn't performance).

As I have posted in the past, would you brag about your processor that it needed a 30% clockspeed advantage to perform as well as your main competitor... I sure wouldn't.Reply

AMD tried to come up with a more meaningful performance metric with their True Performance Initiative, but since Intel didn't want a real measure of performance it didn't get anywhere.

I find it interesting that many who defend(ed) the totally bogus "clockspeed is everything" (when they know/knew in fact that it was a bullshit way to measure performance of different CPU architectures), are now slamming IPC as a bad measurement metric.

Why not come up with performance test suite based on something much more accurate: the product of clockspeed and IPC? Maybe the FTC should step in like in the case of audio amplifier power specs.

It would show high GHz x low IPC (Intel) = low GHz x high IPC (AMD).Reply

Sorry about the 'expomemtially' - exponentially. At least I'm consistent.I thought it was expornentially at first. That would have been a real Freudian slip. Hell, I've got to use my P4 for something!Reply

Yes, Derek #11, you cant quantify everything with a single index. In oz, we say 'horses for courses' ie different strengths animals for different race lenghts and conditions. Cpus with different pipeline length and no., branch predictors, cache architecture and chipset interface cannot be lumped under one index. That's why I'm against the AMD PR rating. If you throw in chipsets, GPUs, RAM etc. the number of variables escalates expomemtially. I'm all for direct subjective testing (no demos/synthetics beyond scaling experiments ie exactly the same system at different MHz or memory settings etc.). However no one does this, because it requires extensive testing and grouping of results (like phyla in biology). Nevertheless if you are going to label a cpu, the Abraxas index (AI), MHzxIPC, would be a good one.

MHz is liked because it is an absolute index. You wont get that with IPC but I'm sure a good assembler/machine code programmer would be able to set up a routine that would cover the instruction set in a similar fashion to expected application code, and be close to absolute. The branch prediction doubt (Kristopher #14) would be covered by the fact that branching statements are in the instruction set and different lenght loops and non branch sequences would be included in the routine. The size of the routine should be contained within the smallest L1 cache (L2 caches preferably switched off) and no reading/writing to main memory during execution.

The only other performance index would be the memory/cache subsystem which could be described by the memory/cache subsystem latency (MSL). This naturally would be dependent on chipset and RAM (run at default or standard -JEDEC specs.) So I propose the Pumpkin Index (PI) for systems:

Wow, it took CRAMITPAL more than 17 hours to respond to a thread just begging for his usual dumbass mutterings. Must be a new record.

I agree with johnsonx that using a third party wouldn't work. For one thing, neither AMD nor Intel would likely agree on a common metric and wouldn't be bound to it. To make it effective, there must be a baseline processor for comparison and that baseline must not change over the years so as to avoid consumer confusion.

A common nomenclature might cause more confusion. For example, if there was an Athlon64 570 and a Pentium 4 570, to the average consumer (and even some not-so-average ones) there won't be any reason to choose one over the other. Sure AMD could claim 64-bit support on the box and Intel could claim HT, but when it comes down to it, they'll just look at the number. Granted, by using a common nomenclature, they should be getting equal performance no matter which CPU they choose. But since Intel is the most recognized brand name, it would likely be chosen over an equivalently marked AMD.Reply

Expect BOGUS performance ratings from InHell to defraud consumers as they've done since the Pig$ was rushed to market like the PressedCrap, aka Pig 4 E (for Enema edition). InHell has fallen and can't fix their design/production/performance issues so they once again chose to misrepresent the facts to save face and bilk consumers. This has all been documented on the Pig 4 and that's why InHell has a multi BILLION dollar Class Action Suit against them in court right now for FRAUD !Reply

A 3rd party processor rating scheme won't cut it either. Look what happened when 3dMark was taken as a de-facto rating system for 3D GPU's: vendors started writing driver optimizations just for 3dMark, and perhaps even designed hardware with 3dMark in mind (just a guess on my part). Then there was griping about how 3dMark might favor some hardware designs over others.

Imagine how bad it would be for CPU's if, for example, Sandra were enshrined as the official rating system. Each architechtural change would have one CPU maker clamoring for Sandra to include their new instructions or optimizations, with the other CPU maker(s) crying foul. Each new release of Sandra would be hailed by the CPU vendor who's scores went up by a bit, and accused of bias by those who lost ground. Finally, internal cpu microcode would probably start getting optimized for Sandra instruction sequences, at the expense of real-life performance.

Like it or not, the rating system we are stuck with is the one that each CPU vendor implements for their own products, be it Mhz, performance ratings, or model numbers.

nice to see my name mentioned :). i see why intel would do this, as its been pretty obvious that a 1.7mhz pentium M is faster than any pentium 4-M on the market.

i stand by my previous statement, while average IPCxmHz is not necessarily perfect, its the best solution anyone has to offer. AMD processors (aside from HT ability) are faster than intel CPUs at everything. Intel has an advantage in encoding apps, which are so far the only apps that benefit from HT.

if intel named a 3.6ghz P4 prescott the 575, AMD would just name a 2.4 ghz A64 the 580. It adds even more marketing lingo to the whole system. its time for a completely 3rd party organization to step in for processor naming, or for OEMs to start building their systems saying "a 2.2 ghz athlon 64 is about 10% faster than a P4 3.2ghz due to a more efficient design." let the manufacturers do the mudslinging and marketing, not the cpu makers.Reply

The problem with assigning a product number or rating based on average IPCxMHz is just as bad as AMDs method of rating against a reference processor.

In AMDs case, performance of a current processors is not always going to be exactly equal to the performance of a thunderbird at whatever MHz: Different programs will be more or less efficient in different situations.

In the case of average IPCxMHz, any given processor will have a completely different IPC for different programs in different situations.

Averaging IPC over all programs has essentially the same "goodness" as averaging relative performance of a specific processor over another.

Not only that, but IPCxMHz is still not the be all end all of performance in processors ...

if processor 1 is faster at instuction A and slower at B than processor 2, even if both processors have the same IPC and MHz, processor 1 will win benchmarks to which instruction A is critical and lose benchmarks that rely on instruction B.

It may seem like average IPCxMHz is the best solution, but even actual IPCxMHz for given code will only be a good indicator of relative performance between processors of the exact same architecture. going by average IPCxMHz is just as good (or bad) as AMDs scheme ... Though, I suppose both methods are a little better than pure MHz if you want to argue that point.

The bottom line is that the *only* real indicator of performance is the actual runtime of the programs you want to use.

I appologize if I didn't explain all that very well ... the point is a subtle one, and its pretty late so I might not be making much sense. :-)Reply

Somebody in an earlier post (abraxas?) suggested an IPCxMHz rating. An average IPC (instructions per clock cycle) could be established with a suitable test program. This would at least solve the horsepower side of the cpu spec. (sorely lacking in present descriptions and benchmarks). It would also stop the bleating about MHz or IPC being more important depending on the manufacturers product range. Cache size and FSB would still have to be quoted separately as their performance is subjective to application.Reply

Doesn't this remind anyone of the Intel iComp rating system from the way-back time? I still remember buying servers (from more than one vendor) equipped with "Intel Pentium 735/90" or "810/100" processors (in other words, the 90Mhz Pentium had an iComp rating of 735, while the 100Mhz had a rating of 810). The original iComp system gave a rating of 100 to an i486SX @ 25Mhz as a baseline. iComp 2.0 came out a couple years later, and I think a Pentium 75Mhz got the 100 point baseline rating then. Intel had some documents carefully explaining that Mhz wasn't everything. But the market didn't really bite on iComp, so it faded away...Reply

It was my understanding that the rating system employed by AMD was based on the thunderbird scaling higher ( like a 1700+ would be how fast a tbird would have to run to do the same work)and not to correspond with intels speeds.Reply