I got guys askin' me this and I don't think it has much to do with P4's 20 stage pipe....what gives?
Originally posted by: Moohooya
I believe it is due to a larger on board cache. Cache misses are less frequent, and hence fewer memory requests are made.
Originally posted by: PrinceXizor
Actually the base FSB clock on AMD's chips is currently higher than Intel's (166Mhz vs. 133Mhz) but Intel has quantispeed architecture so 100*4=400 and 133*4=533 so AMD has a double pump to 333Mhz. That's why you see new specs for 667Mhz and 800Mhz from intel these are incremental jumps in the base with the quantispeed making up the difference, so (166*4)=667Mhz and (200*4) = 800Mhz.
Originally posted by: imgod2u
Clockspeed and cacheline size would be my guess. The processor has to request instructions every clock and if the instructions are not in cache it has to read from memory. The prefetch algorithm has to work very aggressively when the processor's clockrate is very high because 1. many requests are made and 2. a cache miss would cause a lot more wasted clockcycles.
Each time a request to memory is made, 64 bytes is transmitted from memory to cache (a cacheline). Even if the processor is only asking for 1 instruction whereas an Athlon would ask for 3 instructions per clock, the P4 still gets a 64 byte cacheline transmitted to cache for every request (per clock if it's not in cache) and the Athlon still gets a 32 byte cachline transmitted to cache for every request (per clock). So with a combination of the P4's relatively higher clockspeed and its larger cacheline size, I would say it would suck up a significantly greater amount of bandwidth than an Athlon would. However, it can benefit more from higher memory bandwidth as with a greater cacheline size, you get a greater chance of a cache hit and coupled with a more aggressive prefetch logic, you can almost eliminate the problem of memory latency.
Stating that the Athlon has "384 KB of cache" may be suitable for public relations, but summing up the two-level cache hierarchy into such a neat little figure is flawed when analyzing cache performance. The fact is that as long as the L2 is at least four to eight times the size of the L1, the size of the L1 has little effect on the global L2 miss-rate...this was well established by Przybylski, Horowitz, and Hennessey in "Characteristics of Performance-Optimal Multi-Level Cache Hierarchies" (ISCA 1989). Exclusitivity is merely necessary in the Athlon to prevent its small L2 (relative to the L1) from becoming useless; the P4's 8 KB L1D cache and its trace cache, estimated to be equivalent to 32 KB, is small with respect to its L2. The two respective designs will then have nearly equal L2 miss-rates given the same L2 size.Originally posted by: shr
few other Reasons, First the athlon does not duplicate L1 cache Data into L2 which is why it can technically be said that Athlon has 384KB of cache.
That's quite far off, Bhandarkar and Ding found that in SPEC CPU95 the average is 1.35 uops/x86 instruction on the Pentium Pro. I've never seen any studies that indicate the Athlon or P4 are dissimilar, especially since the Athon's 6-entry uop decode queue would quickly become saturated if the rate was any higher. Regardless, this has no effect on main memory bandwidth requirements.There is also the fact that x86 is a CISC instruction set and both Athlon and P4 are RISC proccessors that translate CISC intstuctions into RISC beffore excecuting, in average the Athlon gets 3 RISC intructions per CISC instrucions translated whereas the P4 gets 4 in average.
The cache miss penalty is higher for the P4 due to its higher clock rate; while its clock rate is higher due to its longer pipline, pipeline length alone has little-to-no effect on cache miss penalty. And while a L2 cache miss may be detrimental to performance, part of the higher penalty is amortized due to the P4's larger reorder window size (126 instructions vs. 54 instructions). Again, this has little effect on main memory bandwidth requirements, which is what is being discussed.Also a Cache miss has significantly more performace hit on a P4 due to its 20 stage pipeline
Originally posted by: Sohcan
Stating that the Athlon has "384 KB of cache" may be suitable for public relations, but summing up the two-level cache hierarchy into such a neat little figure is flawed when analyzing cache performance. The fact is that as long as the L2 is at least four to eight times the size of the L1, the size of the L1 has little effect on the global L2 miss-rate...this was well established by Przybylski, Horowitz, and Hennessey in "Characteristics of Performance-Optimal Multi-Level Cache Hierarchies" (ISCA 1989). Exclusitivity is merely necessary in the Athlon to prevent its small L2 (relative to the L1) from becoming useless; the P4's 8 KB L1D cache and its trace cache, estimated to be equivalent to 32 KB, is small with respect to its L2. The two respective designs will then have nearly equal L2 miss-rates given the same L2 size.Originally posted by: shr
few other Reasons, First the athlon does not duplicate L1 cache Data into L2 which is why it can technically be said that Athlon has 384KB of cache.
That's quite far off, Bhandarkar and Ding found that in SPEC CPU95 the average is 1.35 uops/x86 instruction on the Pentium Pro. I've never seen any studies that indicate the Athlon or P4 are dissimilar, especially since the Athon's 6-entry uop decode queue would quickly become saturated if the rate was any higher. Regardless, this has no effect on main memory bandwidth requirements.There is also the fact that x86 is a CISC instruction set and both Athlon and P4 are RISC proccessors that translate CISC intstuctions into RISC beffore excecuting, in average the Athlon gets 3 RISC intructions per CISC instrucions translated whereas the P4 gets 4 in average.
The cache miss penalty is higher for the P4 due to its higher clock rate; while its clock rate is higher due to its longer pipline, pipeline length alone has little-to-no effect on cache miss penalty. And while a L2 cache miss may be detrimental to performance, part of the higher penalty is amortized due to the P4's larger reorder window size (126 instructions vs. 54 instructions). Again, this has little effect on main memory bandwidth requirements, which is what is being discussed.Also a Cache miss has significantly more performace hit on a P4 due to its 20 stage pipeline
Originally posted by: KF
>That's quite far off, Bhandarkar and Ding found that in SPEC CPU95 the average is 1.35 uops/x86 instruction on the Pentium Pro.
Each native x86 instruction is translated into a specific group of internal RISC ops. What this benchmark (SPEC CPU95) has to do with it, I don't know.
SPEC CPU95 represented an average workstation workload for the purposes of the study.
> I've never seen any studies that indicate the Athlon or P4 are dissimilar, especially
> since the Athlon's 6-entry uop decode queue would quickly become saturated if the rate was any higher.
If the Athlon decoded x86 instructions into 3 uops on average, the microprocessor would often stall on fetch because its decode queue, with 6 entries that are issued at a rate of 3 uops/cycle, would quickly become a bottleneck.What has "rate" got to do with it?
I never said execution rate had an impact on uop translation.Again, a particular x86 instructions is translated into a specific group of instructions that are executable internally. No matter how slow of fast the ops are executed, the number remains the same.
There may be slight differences, but the vast majority of x86 instructions used are decoded into 1-2 uops, 2 if the instruction is register-memory.Yes the ops are different for an Athlon and a P4. Why would they be the same? And the P4 is a completely new design from the PPro/PII/PII.
>The fact is that as long as the L2 is at least four to eight times the size of the L1,
>the size of the L1 has little effect on the global L2 miss-rate.
What happens if L2 is less than 4 to 8 times L1, something which is desirable if you want as much fast memory to run programs from as possible? What happens when the mis-rate is designed (by the programmer) to be 0 at the times where speed is needed the most?
Do you care to dispute their findings? The fact that you don't know the authors doesn't lead much credibility. The relationship between global and local multilevel hit-rates is well understood, obviously also by the K7 design team given that they decided to make the L2 cache exclusive...FYI, John Hennessey, from Stanford, co-championed RISC in the early 80s, and his MIPS project became the MIPS R2000, the first commercial RISC microprocessor. He and Dave Patterson from Berkeley are considered the "fathers" of modern computer architecture.>..this was well established by Przybylski, Horowitz, and Hennessey in "Characteristics of
> Performance-Optimal Multi-Level Cache Hierarchies" (ISCA 1989).
> Exclusitivity is merely necessary in the Athlon to prevent its small L2
> (relative to the L1) from becoming useless;
I have no doubt the designers of the Athlon know infinitely more about designing a real CPU than whoever these authors may be. Real designers also do extensive statistics on real programs to check.
In general I don't see in this thread a specific explanation of why the P4 requires higher bandwidth to perform on the same level as a slower clocked Athlon.
It is a consequence of the long pipeline. The longer pipeline cause a bigger penalty for branch mispredictions. I think it also leads to more frequent pipeline stalls due to dependant instructions. There is also the case where branching to a new location requires things that are not located in cache. You can make up for the pipeline's penalty by running the CPU faster. But running the CPU faster requires the memory to be faster also to keep the cache supplied at the proportionally higher rate.
No, pipeline length alone has nothing to do with main memory bandwidth. I've already explained the cause: memory bandwidth is needed to service blocks for L2 cache misses. This is dependent on the number of memory references per cycle (ISA dependent), L2 cache miss-rate (a function of block size, associativity, size of L2 victim cache, and cache size, independent of L1 size as long as the usable L2 is 4-8 times the size of the L1), IPC, clock rate, and L2 block size. This is a well understood property; read chapter 5 of "Computer Architecture: A Quantitative Approach" by Hennessey and Patterson and "Using cache memory to reduce processor-memory traffic" by J.R. Goodman.
A longer pipeline potentially increases the miss-prediction penalty, but it alone has no immediate affect on the frequency in which L2 blocks must be serviced from main memory. It does potentially decreasing the IPC due to miss-speculation penalty and the clock rate which affects main memory bandwidth, but given two microprocessors with the same miss-prediction penalty and the same clock rate, pipeline length will not affect main memory bandwidth. I'm a graduate student researching computer architecture; these are not wild concepts but rather basic conclusions of memory systems.
Fine, I'll give you a fact. The fact is that the global miss rate for a level 2 cache is equal to the miss rate of the L1 cache times the local miss rate of the L2 cache. The fact is that the local miss rate of the L2 cache varies dependent on the L1 miss rate, and the combined effect is that the L2 global miss-rate, which is what is important when considering multilevel cache missrate, is not dependent on the presence and size of the L1 as long as the L2 is 4-8 times the size of the L1. The has been well understood for years, it's not my fault if you have neither the patience, education, or experience to understand this.Originally posted by: KF
>Do you care to dispute their findings?
I wouldn't dispute findings to the extent that findings are facts. I like facts. Since those facts from those people have no application when the cache ratios are what they happen to actually be in the case of the Athlon, why they should be relevant you have not explained.
You presented absolutely no argument about the relationship between L1 and L2 cache size and global L2 hitrate. The Athlon's hierarchy is absolute proof that the K7 designers took not only the correct, but the only approach to exclusitivity in the L2 given the large L1 cache.> The fact that you don't know the authors doesn't lead much credibility.
No credibility is required, since I presented the full argument. Besides the argument, there is the actual performance of the Athlon which performs in accordance with it.
Microprocessor research and design, in both academia and the industry, is analyzed through existing programs and workloads. If you think design and research is performed solely through statistical analysis, you are sorely mistaken. And please don't turn this into some silly Intel vs. AMD fight, flokster's thread deserves more than that.> The relationship between global and local multilevel hit-rates is well understood,
And statististical conditions have to yield to actual conditions. As I mentioned, running real code and examiniing the results is a gigantic factor in the design of x86 CPUs. With the appropriate utilities, you can in fact get internal CPU data for lots of things because it is so important that Intel has designed in the capability. For several generations of CPUs, Intel has depended on getting programmers to alter their practices to suit the CPU in order to derive a big percentage of the performance potential. If the charactersitics of actual code had not changed, Intel CPUs would have much lower performance. AMD has to design in accordance, or go out of business; a huge incentive to getting cache sizes realistically optimized.
Do you take pride in the fact that the Athlon "stomps the cr*p" out of the VAX-11? The MIPS R2000 is nearly two decades old. And I'd still like to hear some explanation why Patterson's publishings are incorrect, especially considering many of the architects for the K7 likely researched under him. You seem to be holding some grudge over research, which is quite humorous since senior architects at microprocessor companies tend to come from academia, and vice versa.>FYI, John Hennessey, from Stanford, co-championed RISC in the early 80s, and
> his MIPS project became the MIPS R2000, the first commercial RISC
> microprocessor. He and Dave Patterson from Berkeley are considered the
> "fathers" of modern computer architecture.
The designers of the Athlon are also fathers, fathers of a real microprocessor, one which no doubt stomps the cr*p out of a MIPS R2000.
If the Athlon decoded, on average, an x86 instruction to 3 uops, then its 3 decoders would decode, on average, 9 uops/cycle. This would easily fill up its decode queue.>If the Athlon decoded x86 instructions into 3 uops on average, the microprocessor
> would often stall on fetch because its decode queue, with 6 entries that are issued
> at a rate of 3 uops/cycle, would quickly become a bottleneck.
6 spots with only 3 things to go into them would seem to be sufficient. Seeing as how it would be remarkable if a programmer could write a program that would actually allow the Athlon to sustain an execution rate of 3 micro-ops per cycle, the decode queue should not be a bottleneck, even if it did stall at a over a 3 micro-op rate.
Funny, I don't consider a correct answer and valid modeling equations to be "gobbledegook." I'll lay things out, which I didn't do originally because imgod2u did a good job:>No, pipeline length alone has nothing to do with main memory bandwidth.
As if I said it did. My explanation is similar to yours, only it resorts to less jargon, less appeal to authority, and less gobbledegook. The way you explain it, it sounds like it has something to do with different cache hit rates, which it doesn't.
Thank you, this is exactly one of the parameters that effect main memory bandwidth that I have been describing.>A longer pipeline potentially increases the miss-prediction penalty ...
>but given two microprocessors with the same miss-prediction penalty
>and the same clock rate, pipeline length will not affect main memory bandwidth.
A longer pipeline in itself increases the misprediction penalty. The P4 does not reduce misprediction below the Athlon to undo it, probably because there is no way to do so. The way to make up for it is a higher clock. A higher clock needs a higher memory bandwidth.
Okay......this seems to be one of the first times I've actually received such a negative reaction to merely explaining the results of decades of research and design in computer architecture. I'd like to know what the source of this antagonism towards my area of study is.> I'm a graduate student researching computer architecture.
Not exactly a surpise. It is always a pleasure to see posts from very knowledgeable people such as yourself.
>these are not wild concepts but rather basic conclusions of memory systems.
I guess when people take issue with what we have said, we are offended. My apologies. If I could phrase things just right, maybe I could avoid offending people, although not entirely I am sure. I am always surprised at how people take things.
Yep, page 45. Having the DRAM burst length equal to the block size is somewhat beneficial towards main memory latency, though the drawback of larger block sizes is not nearly as dramatic as the number of times that the block size is larger than the DRAM burst length due to memory controller concurrency. In fact, RDRAM and DDR-II are both spec'd to have 32-byte burst lengths.Sohcan: are you sure P4 cache lines are 128 bytes? I thought all x86 processors since the Pentium had 64 byte cache lines, exactly matching memory burst length. This alone would in fact dramatically increase the bandwidth dependency if true.
Close, but no cigar. What you were describing is the reorder buffer, which manages in-order instruction retirement and maintains precise exceptions under speculation and out-of-order execution. Entries in the reorder buffer (which has 72 entries, not 144, if you read the next sentance after the one you quoted) are allocated at instruction issue and decallocated at instruction retirement.Originally posted by: KF
>If the Athlon decoded, on average, an x86 instruction to 3 uops, then
> its 3 decoders would decode, on average, 9 uops/cycle. This would easily
> fill up its decode queue.
My original complaint was that your logic did not support your conclusion (3 ops overflowing enough positions for 6). Since I didn't recall much about the Athlon's architecture, I took a look at again. (In the Athlon code optimization guide, 22007.pdf, appendix A.) Suffice it to say that the Athlons queues are large enough that 9 micro-ops per cycle would not fill up, or stall. I don't know where you got your numbers from; maybe the K6.
"...A DirectPath instruction is limited to those x86
instructions that can be further decoded into one or two OPs...."
The Athlon repacks x86 instructions into MacroOPs that may contain 2 ops. (or possibly 3 in the next case?)
"Uncommon x86 instructions requiring two or more MacroOPs
proceed down the VectorPath pipeline...."
"The ICU takes the three MacroOPs per cycle from the early
decoders and places them in a centralized, fixed-issue reorder
buffer. This buffer is organized into 24 lines of three MacroOPs
each."
24 lines x 3 MacrOPS x 2 OPs = 144 OPs. So there is room for 144 ops (not 6) without overflowing or stalling. (Typical of Athlon overkill.)
shr's original statement, which you said was impossible, was " in average the Athlon gets 3 RISC intructions per CISC instruction... "
Now you are using 9 ops to obtain an impossibility, but that still would not "easily fill up its decode queue." If you are are going to obfuscate with obscure technical references in order to browbeat people into silence, you are going to have to be far more vague. Do not ever refer to something which can be checked.
>The fact that you don't know the authors doesn't lead much credibility
The fact that you don't know the Athlon doesn't lend much credibility
I was applying it to the P4 to demonstrate that its L2 likely has a 30-40% lower global miss-rate, due to the previously mentioned L1->L2 ratio behavior, its larger cache size, and somewhat offset by the Athlon's wider associativity (16-way vs. 8-way on the P4's L2). This is more than reasonable given that Paul DeMone estimated the Athlon and P4's L2 at 256KB to have nearly equal miss-rates (1% and 1.1%, respectively) using the well-known VAX study on cache miss-rates.>Okay......this seems to be one of the first times I've actually received such a
> negative reaction to merely explaining the results of decades
> of research and design in computer architecture. I'd like to know what the
> source of this antagonism towards my area of study is.
Since I presented no antagonism to "explaining the results of decades of research" , there is no source of it for me to explain. My "antagonism" is that directly from the premises you present (4 to 1 cache ratio), it is inapplicable. Athlon's cache is 2 to 1 ( 256K to 128K)
Is that your professional opinion? Universally branding theories and implementations that are decades old as primitive is quite ludicrous. Tomasulo's dynamic scheduling algorithm is at the heart of nearly every high-performance microprocessor today, save the Sun US-III and Itanium family, yet it was developed 35 years ago for the IBM 360/91. Most of the techniques and understanding that go into caches and TLBs are decades old. The structures that support speculative execution are nearly two decades old.>Do you take pride in the fact that the Athlon "stomps the cr*p" out of the VAX-11? The MIPS R2000 is nearly two decades old.
I guess you prefer to miss that point too. The theories and implementations from decades ago are primitive and have been superceded next to what goes into today's processors.
Wow, what reading comprehension you've displayed there. Let's look at what I said again: "Stating that the Athlon has "384 KB of cache" may be suitable for public relations, but summing up the two-level cache hierarchy into such a neat little figure is flawed when analyzing cache performance." I'd like to know where I said that "the Athlon's cache is suitable for public relations." It was quite clear that I was attacking the commonly held misconception about exclusitivity, not the principle or the Athlon's cache. As for "a 4 to 1 L1/L2 cache ratio is required for optimal performance", I NEVER stated that. I was using the principle as part of the cache analysis (in my first post) and to demonstrate the necessity of exclusitivity in the Athlon's L2 to prevent the L1/L2 ratio from effectively being 1:1 (in my second post). Maybe if you had asked me to clarify myself instead of attacking me, this misunderstanding would not have occurred.To say the Athlons cache is "suitable for public relations", and use an outdated computer to back the claim that a 4 to 1 L1/L2 cache ratio is required for optimal performance, is absurd. In every way the resources on the Athlon die are overkill.
You attacked the credibility of the authors on two occasions, which I've noticed is an often-used tactic when one wants to refute a finding or claim but cannot find any technical reason:> And I'd still like to hear some explanation why Patterson's publishings are incorrect, ...
Since the idea that anyone's publishings are incorrect was not presented by me, you will have to explain why they are incorrect, if they are, to me.
Let's see...in reference to Horowitz, Hennessey, and Przybylski: "Real designers also do extensive statistics on real programs to check." The implication that researchers do not extensively test ideas on real programs is quite false. There are also the previously metioned attacks on the authors.>.. especially considering many of the architects for the K7 likely researched under him.
> You seem to be holding some grudge over research, which is quite humorous
> since senior architects at microprocessor companies tend to come from academia, and vice versa.
Why do I seem to you to be holding a grudge against research?
I have no such grudge, I do real research.I stated that research was the reason for the Athlon's and P4's final characteristics. It is true the research was done on _real_ processors running _real_ programs, and the implementations had to pass the rigors of _really_ having to perform, compete and sell, but it was _real_ research. Why do you have a grudge against _real_ research?
Nice selective quoting, I was referring to clockspeed. While clockspeed and IPC affect main memory bandwidth requirements and are individually affected by pipeline length, it is still the case that pipeline length alone has little affect on main memory bandwidth. This is especially true in the case of the P4, for which in many cases IPC * clock rate for the fastest P4 is roughly equal to the same figure for the fastest Athlon.First I got this:
>Sohcan: No, pipeline length alone has nothing to do with main memory bandwidth..
Then this:
>>KF: A longer pipeline in itself increases the misprediction penalty...
>Sohcan: Thank you, this is exactly one of the parameters that effect main memory bandwidth that I have been describing.
Calling what you don't understand "gobbledegook" does not make it so. Given that I received a few pm's thanking me for the explanation, it seems others thought differently.In between, there were extended outbursts of interspersed gobbledegook and brow-beating, as appropriate for a graduate student.
Nothing wrong with that, I think that the Athlon is arguably the finest x86 microprocessor ever produced. Next time don't get out of hand by taking a criticism of PR junk related to the Athlon as a derision of the microprocessor itself.Oh yeah. I am partial to the Athlon.