what does the L2 chache do?

[Prism123]

I noticed that the p4 6XX series has a 2 mb l2 cache, what exactly does this do, and what performance boost does this give it.

I also noticed that some amds had a 512 cache(newcastle and winchester I think) and some had a 1 mb(the ones with hammer in teh name) what does this mean? Does having a lower cache than teh 6xx series effect their performance in some areas?

 

[liquidtrance123]

I believe its kind of like short term storage for things going to be processed and things already processed that are going out to system memory. I think info is stored there waiting to be processed and also stored there after processing and waiting to goto system memory. Could be wrong tho i never really read much into it.

 

[pxc]

Pretty much what liquidtrance123 said above: it's a buffer between the CPU and main memory.

A CPU can access data:
immediately from registers (few fixed number of registers available)
within a couple of clock cycles from L1 cache (small size)
around a dozen clock cycles from L2 cache (usually larger than L1, but most apps won't fit inside it)
couple of hundred cycles from main memory (slowest)

The less time the CPU has to wait for code and data, the more work can be done.

I've simplified, but who really wants to get into register renaming (multiple copies of registers), ROB (reordering instructions for more efficient execution) or stalls (forced waits in a thread)?

 

[Scali]

The L stands for 'level'... So in general, Ln cache is the cache at level n, where level 0 is the CPU itself. So L1 is the cache closest to the CPU, L2 is the 'cache of the cache'... some systems even have L3, or more, either in the CPU or on the mainboard.

In short, it means that the 6xx has a larger buffer between mainmem and the CPU... in cases where you have to access memory a lot, it may be faster (assuming it will not fit in a smaller cache). But since 1 mb is already very large, the step from 1 mb to 2 mb doesn't affect performance all that much in general...
Another catch is that a 2 mb cache requires more complex addressing, which means it has a slightly larger latency than the 1 mb cache, which further reduces any potential gain from the extra cache.

So it does give a performance boost, but it's not all that large, and you won't notice in all applications...

 

[BigTaf]

All the above answers are pretty well correct the only thing i didnt see mentioned is what cache is actually used for, Commonly used instructions. A program dealing with constantly changing equations is less likely to benefit from the cache compared to a program which repeats a similar task over and over

 

[Scali]

All the above answers are pretty well correct the only thing i didnt see mentioned is what cache is actually used for, Commonly used instructions. A program dealing with constantly changing equations is less likely to benefit from the cache compared to a program which repeats a similar task over and over

The cache is used for any kind of memory. Both instructions and data.
Indeed, the commonly used instructions/data. Technically instructions are data aswell, in a Von Neumann-architecture, like all modern CPUs are... only in L1 cache the distinction is made, because the instruction cache is connected directly to the instruction decoder, while the data-cache is connected to the load/store unit. This causes problems when you try to access the same memory page as both code and data... Because the cache is mutually exclusive, using a page as code first, will push it out of the data cache, and vice versa.

Basically cache is a buffer with a strategy that stores the Least-Recently-Used data.
L2 and higher level caches are basically just placed somewhere on the bus between the CPU and the memory. L1 is pretty much a part of the CPU's execution core itself.

 

[Josh_B]

The 512K or 1024K of cache on the Athlons makes less of a performance difference than on a P4.

Because of the P4's longer pipeline, the P4 loses more performance during a pipeline stall. Pipeline stalls mean the entire pipeline must be flushed out. (All 31 stages of it...) The Athlons have 10/15 stages for ALU/FPU on the K7, or 12/17 on the K8. Quite literally, the P4 has twice as long of a pipeline as a K7.

Why does this matter? Well, the L1/L2 refill the pipeline. The more "stuff" (instructions/data) that you can store close to the CPU, the faster you can recover from stalls. Also, as others have mentioned, code that is not branch-prediction heavy can sit in the L1 or L2, and have access within 17 clock cycles (K7) to the execution core. If the CPU had to go back to main memory, it would be exponentially less efficient.

Don't forget that the K7/K8 are exclusive cache architectures, and thus do not replicate the L1 in the L2 cache. Intel has implemented this on their CPUs to reduce latency in the event of cache misses, but Athlons have traded lower latency for more capacity. Finally, Athlons don't require as large an L2 cache, mainly because their L1 is already 128KB, which is much larger than the 12/20K on the P4's. (Yes, yes, I know on the P4, it's considered 'trace cache'...)

 

[Scali]

Because of the P4's longer pipeline, the P4 loses more performance during a pipeline stall. Pipeline stalls mean the entire pipeline must be flushed out. (All 31 stages of it...) The Athlons have 10/15 stages for ALU/FPU on the K7, or 12/17 on the K8. Quite literally, the P4 has twice as long of a pipeline as a K7.

Not all stalls require a flush. Only certain things, like mispredicted branches.
And the size of the cache only affects the amount of cache misses that occur, which don't have an effect on the amount of mispredicted branches.

Finally, Athlons don't require as large an L2 cache, mainly because their L1 is already 128KB, which is much larger than the 12/20K on the P4's. (Yes, yes, I know on the P4, it's considered 'trace cache'...)

Trace cache doesn't store x86 instructions... It stores pre-decoded instructions. It can store 12000 micro-ops, which corresponds to something like 50-60kb of x86 code.
It has only 8k of L1 data cache... it's kept extremely small to maintain a latency of 2 cycles, even at very high clockspeeds.
Athlons have 3 clk latency, despite their lower clock.
So the Intel approach is to maximize the performance of L1 cache as long as you have cache hits, and the Athlon approach is to try and maximize the amount of L1 cache hits.
Despite these vastly different approaches, the caches give similar performance in most practical situations.

 

[EQTakeOffense]

Lol... My God, you're probably scared the poor guy away.

 

[Josh_B]

Not all stalls require a flush. Only certain things, like mispredicted branches.
And the size of the cache only affects the amount of cache misses that occur, which don't have an effect on the amount of mispredicted branches.



Trace cache doesn't store x86 instructions... It stores pre-decoded instructions. It can store 12000 micro-ops, which corresponds to something like 50-60kb of x86 code.
It has only 8k of L1 data cache... it's kept extremely small to maintain a latency of 2 cycles, even at very high clockspeeds.
Athlons have 3 clk latency, despite their lower clock.
So the Intel approach is to maximize the performance of L1 cache as long as you have cache hits, and the Athlon approach is to try and maximize the amount of L1 cache hits.
Despite these vastly different approaches, the caches give similar performance in most practical situations.

Good info, thnx for the corrections. *makes more notes*

 

[ozziegn]

does anyone have the same info as ^ above * but in a more plain english version?

 

[USMC2Hard4U]

I would add, as more of a general rule. Most of the time, more cache is better.

It may not be worth the price premimum, but if you have unlimited money, I would go for the CPU with more cache (if the clock speed is the same anyway)

 

[pxc]

does anyone have the same info as ^ above * but in a more plain english version?

The concept of a pipeline flush isn't that difficult.

There is specialized hardware inside a processor that makes a "guess" of which way a branch will go. For example, after a comparison or test (certain bit(s) are set, state of condition flags, or the value is higher or lower than another) code can continue executing immediately after the test instruction, or jump to another location. The processor will make a guess of which location is next and start executing code at that point. Why? Because prediction is pretty good and the benefit outweighs the negative (below).

This is where a pipeline flush comes in. What if the prediction was wrong? Time to scrap all the polluted instructions in the pipeline and start refilling it with the correct instructions. If the required instructions are in the trace cache, it's a short wait not counting the wasted time executing discarded instructions (up to 30 clock cycles). If not in the L2 cache, a much longer wait while waiting for the code from main memory (hundreds of clock cycles).

---
tangent:
It's not as bad as most people assume: despite having a 2x longer pipeline than a P3, the penalty of even the original Pentium 4 (Willamette core) is only 33% higher in clock cycles. Considering the clock frequencies of P3 vs P4, the P4 isn't slower... a branch mispredict is recovered faster in terms of real time. That improved in Northwood, and worsened in Prescott.

Lots of things have been blamed for the P4 per clock performance disadvantage: decoder, trace cache, pipeline length, execution units, etc. I think the pipeline length is given far too much of the blame. Sure it doesn't help when the pipeline is flushed, but the P4 "sensitivity" to code is more likely spread between many causes. The most critical was straying from P3 optimization rules.

 

[liquidtrance123]

The concept of a pipeline flush isn't that difficult.

There is specialized hardware inside a processor that makes a "guess" of which way a branch will go. For example, after a comparison or test (certain bit(s) are set, state of condition flags, or the value is higher or lower than another) code can continue executing immediately after the test instruction, or jump to another location. The processor will make a guess of which location is next and start executing code at that point. Why? Because prediction is pretty good and the benefit outweighs the negative (below).

This is where a pipeline flush comes in. What if the prediction was wrong? Time to scrap all the polluted instructions in the pipeline and start refilling it with the correct instructions. If the required instructions are in the trace cache, it's a short wait not counting the wasted time executing discarded instructions (up to 30 clock cycles). If not in the L2 cache, a much longer wait while waiting for the code from main memory (hundreds of clock cycles).

---
tangent:
It's not as bad as most people assume: despite having a 2x longer pipeline than a P3, the penalty of even the original Pentium 4 (Willamette core) is only 33% higher in clock cycles. Considering the clock frequencies of P3 vs P4, the P4 isn't slower... a branch mispredict is recovered faster in terms of real time. That improved in Northwood, and worsened in Prescott.

Lots of things have been blamed for the P4 per clock performance disadvantage: decoder, trace cache, pipeline length, execution units, etc. I think the pipeline length is given far too much of the blame. Sure it doesn't help when the pipeline is flushed, but the P4 "sensitivity" to code is more likely spread between many causes. The most critical was straying from P3 optimization rules.

Holy shit....i actually understood that <3

 

[Rembrandt]

I want to thank you guys for the great information. This has been wonderful and more informative than anything I got out of any of my computer science classes on this subject.

 

[USMC2Hard4U]

The concept of a pipeline flush isn't that difficult.

There is specialized hardware inside a processor that makes a "guess" of which way a branch will go. For example, after a comparison or test (certain bit(s) are set, state of condition flags, or the value is higher or lower than another) code can continue executing immediately after the test instruction, or jump to another location. The processor will make a guess of which location is next and start executing code at that point. Why? Because prediction is pretty good and the benefit outweighs the negative (below).

This is where a pipeline flush comes in. What if the prediction was wrong? Time to scrap all the polluted instructions in the pipeline and start refilling it with the correct instructions. If the required instructions are in the trace cache, it's a short wait not counting the wasted time executing discarded instructions (up to 30 clock cycles). If not in the L2 cache, a much longer wait while waiting for the code from main memory (hundreds of clock cycles).

---
tangent:
It's not as bad as most people assume: despite having a 2x longer pipeline than a P3, the penalty of even the original Pentium 4 (Willamette core) is only 33% higher in clock cycles. Considering the clock frequencies of P3 vs P4, the P4 isn't slower... a branch mispredict is recovered faster in terms of real time. That improved in Northwood, and worsened in Prescott.

Lots of things have been blamed for the P4 per clock performance disadvantage: decoder, trace cache, pipeline length, execution units, etc. I think the pipeline length is given far too much of the blame. Sure it doesn't help when the pipeline is flushed, but the P4 "sensitivity" to code is more likely spread between many causes. The most critical was straying from P3 optimization rules.

Whaat CPU gives a better "guess" The Pentium 4 or the Athlon 64?

 

[ashmedai]

Whaat CPU gives a better "guess" The Pentium 4 or the Athlon 64?

If you're asking about pipeline length and/or latency, the A64 is significantly shorter/faster. Also the Prescott is slower than Northwood was, but on the other hand can generally clock faster thereby makes up for the longer pipelines.

As far as predictive accuracy, they're (more or less) both pretty good at it.

 

[USMC2Hard4U]

Yeah, asking more along the lines of what preditcs better.

And I dont want to sound too n00bish but what about "prefetching" what does that exactly mean (in english) and how does it relate to the CPU and Cache.

 

[ashmedai]

Prefetching is when the computer fetches stuff it can reasonably assume you're going to want based on what you're doing at the moment. Applies to everything from processor cache, to web surfing (under Firefox) to XP preloading program executables. It fetches it previous to it being needed. Cache in general does basically that, prefetch just specifies that it is done predictively rather than retained in case it's needed again like with cached web pages.

 

[Scali]

The Prescott should have the best prediction... it has the most advanced logic for it.
But it's not something that's easy to measure.
Also, most of the Prescott is not slower. Nearly all instructions have the same timings on Northwood and Prescott.. But the larger cache gives more latency... That probably affects performance more than the actual pipeline length... especially in the way the P4 works, with its tracecache.