Printable View
Cache dont make much heat. On 16MB Tulsa its 0.75W per MB cache. Logic however does. Even with IMC Intels cache will reach new heights. Main memory is just way way too slow. Its something like 100GB/sec vs 10GB/sec not even to mention latency.Quote:
Originally Posted by Saiyan[CHW]
Amen. A lot of people seem to think that a IMC works miracles but it doesn't. IIRC AMD's IMC has only 10-15% lower latency than i975. That's nice but not even close to L2 or even L3 cache.
10-15 percent??Quote:
Originally Posted by Fred_Pohl
More like 20ns But only if you compare AMD IMC with the slowest DDR2 to 975X with high-end >1GHz and low latency settings.
*Ahem* umm Latency for Intel from CPU to Northbridge and to Memory and Back is about 200 - 300ns (depending on memory and quality of Northbridge)Quote:
Originally Posted by Fred_Pohl
Latency for a Socket AM2 Ranges from 40ns To 80ns (depending on the quality of the memory)
The reason that it doesn't seem to have much effect on Intel is because of the Prefetch design of the Processor. IMC can get away with a Simple prefetch unit, Intel's FSB method however can not.
The L1 cache is on the critical pathways of the CPU so it has a direct impact on how high you can get the clockspeed.Quote:
Originally Posted by Shintai
IIRC AMD's cache is "slower" than Intel's but not flat out half as fast, I thought it was Intel's L2 cache that really blew away AMD's in the K8? K8L's L3 should level the playing field on this IMO...
Like nn said cache doesn't generate a lot of heat, logic is the main culprit there. The only thing bad about having lots of cache is that it eats up your silicon budget for core logic and/or makes your die size massive thus lowering yields and increasing costs, otherwise I could care less if AMD/Intel/etc. were throwing 1GB L2/L3's on their cores, in fact I'd be all for it as then you could get rid of low bandwidth and high latency main system RAM.Quote:
Originally Posted by Saiyan[CHW]
IMO the only reason Intel would go the IMC route is because they want to dedicate more of their available silicon towards logic instead of cache (which makes sense given that were heading in the direction of more cores rather than more Mhz to increase performance, think 8+ Conroe cores on a single die, something has to give and I guess they've decided cache is it). Anyways thats _HIGHLY_ speculative, so feel free to poke holes in it.
Supposedly Intel is putting some pretty incredible amounts of cache on their recent chipsets as well...Quote:
Originally Posted by nn_step
Intel is 256bit, 8way. Amd is 128bit, 4way. Intel is more than twice as fast. However AMDs doublesize makes up for it so they are about equal in the hit/miss ratio.Quote:
Originally Posted by mesyn191
not really. Their amounts for their standard retail chips aren't huge by any stretch.Quote:
Originally Posted by mesyn191
You should try Power5's 256-512MB of L3 ;)
Doesn't the K8's dual ported L1 deliver 2x 128 bit reads or 1x 128 bit read and write per clock make that bus width distinction meaningless though?
By huge I was of course comparing to what you might find in the consumer class products, if you're going to make comparisons vs. enterprise class products (didn't think POWER5 was retail?) then yes it does seem pretty weak but that is to be expected.Quote:
Originally Posted by nn_step
right now BOTH AMD and Intel Fetch 16 bytes per cycle Per L1 Cache.Quote:
Originally Posted by mesyn191
regardless of all other bandwidth associated by the L2/L3. That is what is actually being sent into the Processing core.
Thus if you actually do the math, that means a max of 1.5 SSE4 calculations per clock issued. Conroe/K8/Whatever
K8 is an enterprise class product, Opterons remember?Quote:
Originally Posted by mesyn191
And it was kind of retail, you just couldn't buy it at newegg though..
Intel Core 2
AMD K8
L1 data cache
32 KB
64 KB
L1 instructions cache
32 KB
64 KB
L1 latency
3 clock cycles
3 clock cycles
L1 associativity
8-way
2-way
L1 TLB size
Instructions: 128 entries
Data: 256 entries
Instructions: 32 entries
Data: 32 entries
L2 latency
14 clock cycles
12 clock cycles
L2 associativity
16-way
16-way
L2 cache bus width
256 bit
128 bit
L2 TLB size
?
512 entries
Pipeline
14 stages
12 stages
x86 decoders
1 complex and 3 simple
3 complex
Integer execution units
3 ALU + 2 AGU
3 ALU + 3 AGU
Load/Store units
2 (1 Load + 1 Store)
1
FP execution units
FADD + FMUL + FLOAD + FSTORE
FADD + FMUL + FSTORE
SSE execution units
3 (128-bit)
2 (64-bit)
This table explains a lot of things right away. And the most important thing is that the processors with Core microarchitecture have “wider” architecture that allows processing more instructions per clock cycle than CPUs with K8 microarchitecture. Although the execution units of both competing processor architectures can process up to three x86 and x87 instructions per clock cycle, Core Microarchitecture should prove more efficient with SSE instructions. While K8 processors can perform only one 128bit command per clock, Core can process up to three commands like that.
Moreover, Core Microarchitecture boasts another great advantage: more advanced decoding system. Together with the four decoders, macrofusion technology allows decoding up to five instructions per clock (in an ideal case). The competitor processors can only decode three instructions simultaneously. All this indicates that the decoders of Core Microarchitecture based CPUs will be able to better load the processor execution units by performing up to four instructions per clock in the most optimal conditions. In this case the overall commands execution will go 33% faster than by K8 AMD processors.
Here I would like to also mention more efficient data processing algorithms of the CPUs on Core Microarchitecture. The advantages of this microarchitecture show themselves best in the data caching system. Although, the L1 cache of the Core based processors is smaller, it is more associative. And as for L2 cache, it is not only bigger but also has higher bandwidth. Moreover, the shared structure of the L2 cache memory is beneficial for multi-threaded workload.
An important addition to the data prefetch algorithms of the new Core based processors is the unique memory disambiguation technology that has no analogues in the competitor solutions. It makes the upcoming Intel processor more out-of-order (from the code prospective).
In fact, the only indisputable advantage of the AMD K8 microarchitecture that will survive the arrival of Core will remain the integrated memory controller that can definitely ensure lower latency during data processing. However, it is a very tough question if integrated memory controller will be enough for AMD to worthily oppose the Conroe processors, and we still have to answer it later. However, AMD engineers are not keeping their hands in pockets. The future Athlon 64 cores scheduled to come out in early 2008 will be free from some architectural bottlenecks. But, it is a different story and a different article.
http://www.xbitlabs.com/articles/cpu...preview_9.html
if do that, atleast link the source
http://www.xbitlabs.com/articles/cpu...o-preview.html
I did link the source at the bottom. Is this better?
http://www.xbitlabs.com/articles/cpu/print/amd-k8l.html
Instruction Fetching:
Each clock cycle the K8 processor is fetching instructions in aligned 16-byte blocks from the L1I instruction cache into a buffer where the instructions are extracted from the block and are then sent to the decoder’s channels. The 16 bytes per cycle fetch rate allows sending 3 instructions with an average length of up to 5 bytes for decoding on each cycle. In certain algorithms, however, the average instruction length in a chain may be bigger than 5 bytes.
Particularly, the length of a simple SSE2 instruction with register-register operands (for example, MOVAPD XMM0, XMM1) is 4 bytes. If an instruction uses indirect addressing (with a base register and an offset like in MOVAPD XMM0, [EAX+16]), its length increases to 6-8 bytes. In 64-bit mode a one-byte REX prefix is added to the instruction code when the additional registers are employed. Thus, SSE2 instructions may be as long as 7-9 bytes in 64-bit mode. An SSE1 instruction may be 1 byte shorter if it is a vector one (that is, operates on four 32-bit values), but is 7-9 bytes, too, under the same conditions if it is a scalar one (with one operand).
In this situation, the fetch rate of 16 bytes per cycle doesn’t seem fast enough to keep up the decoding speed at a rate of 3 instructions per cycle. This limitation is not important for the K8 processor because vector SSE and SSE2 instructions are decoded at a rate of 3 instructions per 2 clock cycles (or 1.5 instructions per cycle), which is enough to load the two 64-bit FPUs. In the future processor, a rate of at least 3 instructions per cycle must be maintained. Considering this, the fetching in 32-byte blocks, announced in the presentation of architectural innovations of the K8L, doesn’t seem excessive. If the succession of these long commands takes a few neighboring 16-byte blocks, then the average fetching tempo with 16-byte data blocks of 3 commands per clock cannot be achieved.
By the way, Conroe processors fetch instructions in 16-byte blocks, just like K8 processors do, so they can decode the instruction stream at a rate of 4 instructions per clock only when the average instruction length is no longer than 4 bytes. Otherwise the decoder cannot process not only 4 but even 3 instructions per clock. To fight this in short loops, the Conroe has a special 64-byte internal buffer that caches loops up to 64 bytes long (four 16-byte blocks) and allows fetching data in such loops at a rate of 32 bytes per cycle. If a loop is longer than 4 blocks, it cannot be cached in this buffer.
The fetching of the next block of instructions is done using the branch prediction mechanism if there are any branch instructions present. Branches are predicted in the K8 processor by means of simpler algorithms than those employed in the Conroe. For example, the K8 cannot predict alternating indirect branches (this may have a negative effect on the execution of object-oriented polymorph code) and is also doesn’t always predict correctly regular patterns. The branch prediction mechanism will be improved in the K8L, but there’s no detailed info about that yet. The branch tables and counters will probably be made larger, and the algorithm of predicting branches alternating in regular patterns may be improved.
AMD sure marketed it as such but that was largely considered a joke against something like POWER5, or PA-RISC, heck even Itanium.Quote:
Originally Posted by nn_step
Kind've retail? Never seen a "kind've" retail store before, must be local only...Quote:
Originally Posted by nn_step
It is a great list but it is missing one important point:Quote:
Originally Posted by Fred_Pohl
Core2 also has speculative prefetch for the L2 data cache.
That means Core2 can fill cache lines in that cache even before it is sure they will be needed. If the code execution later turns out to need other data, then it can discard it. The K8 cannot do this, the K8 can only prefetch when it is sure which cache line will be needed.
That is a huge deal when running code that is not super-optimized. Because in the traditional setup your L2 cache is pretty much never capable of having data that you didn't use before ready, and you will stall until the memory fetch finishes. With speculative prefetch you have a much higher chance of finding the data you want even if it wasn't in the cache from previous operations.
I think that without that feature any CPU cache above 1 MB is probably useless for general-purpose, not superoptimized code.
I haven't had time to confirm, but I think this plays a major role for one performance oddity I see with Core2: while it is normally 20% faster than AMD64 at the same clock, it sometimes goes to 50% and I have seen 90%. And that is code that is known to be totally free of SSE. I think prefetch is the most likely cause of this.
that is a very valid point, however in recent years the quality of compilers are making well Optimized code more and more common.Quote:
Originally Posted by uOpt
Now the direct implications of that prefetch would most prevalently appear in the compiling of software. However after the said compilation, there isn't going to be much of a noticeable difference. At the same time it is rare for the standard user to build applications from source, even though it is easy as hell with FreeBSD
I don't see where's the joke...Opteron are used in Cray supercomputers, for instance.Quote:
Originally Posted by mesyn191
No.Quote:
Originally Posted by nn_step
And I work on a compiler :)
Of course there's progress. But nobody comes close to compile optimally (not even for C/C++/Fortran, not to mention other languages) for an optimization nightmare like Netburst.
All that code that runs well on Netburst is either
- very simple so that the compiler can figure it out
- it is hand-optimized with SSE code that actually makes use of the parallelism in SSE. A dirty secret is that although most compilers make use of SSE by now and get a speedup out of it compared to that rotten x86 instruction set - but they were using it as a one-data piece at a time machine.
- Both (almost always), such as encoding/decoding.
Anyway, the true advantage of AMD64 over Netburst was that code that did not go through a lot of hand-optimizations performed well enough. Games, scripting languages etc.
And now Intel leapfrogged and Core2 actually does it better than AMD64. Run normal code fast. And that is what the user wants. Before whole classes of software have no time for hand optimizations, namely games.
That is true, actually. The 90% speedup case that I mentioned is actually for compilation of a large software system, when turning on all the compiler bells and whistles.Quote:
Now the direct implications of that prefetch would most prevalently appear in the compiling of software. However after the said compilation, there isn't going to be much of a noticeable difference. At the same time it is rare for the standard user to build applications from source, even though it is easy as hell with FreeBSD
%%
And I didn't realize until now that the Core2 has such a much larger TLB covered area in L1 compared to the AMD64. That might as well have to do with it, too.
So what is the number of L2 TLB entries?
Intel refuses to publish or reference that number anywhere.Quote:
Originally Posted by uOpt
We can make estimates but we can't know for sure.
Conroe's L1 cache does 1 256 bit load per cicle.
K8L's L1 cache allows 2 128bit loads and is twice as big.
So cache-wise K8L is a lot better than Core2.
Xbit doesn't say if K8L's decoders are any better than K8's, aside of decoding SSE instructions in less macro-ops (due to the widder 128 bit SSE units).
Can anyone confirm if it has 4 decoders?
If that isn't true, what is the point in fetching 32 bytes of code per cicle?
K8's 3 decoders decode 3 simple instructions per cicle, 1 simple and 1 double or 1.5 double instructions per cicle, that means it outputs 3 macro-ops per cicle.
Complex instructions thru the vectorpath also are limited to 3 macro-ops per cicle.
With average 4 Byte-long x86 instructions, a 32 Byte chunk contains 8 instructions, but K8L can only decode 3 per cicle (assuming it has 3 decoders) or less, so the bufers will be full in just a few cicles...
And when it comes to SSE execution, Conroe still leads, do 3x 128 bit SSE per cicle, K8L will do 2.
This should be very easy to see in the OS. The OS must know the number of TLB entries to initialize the page tables. I'll have a look tomorrow.Quote:
Originally Posted by nn_step
Now thats something interesting:
http://img5.pcpop.com/ArticleImages/.../000377896.jpg
128 bit L2 to NB bus, witch makes sense, since the IMC is 128 bit (dual channel).
Why isn't K8 like this?
In tandem with lots and lots of custom Cray logic soldered (something similar to Horus IIRC) on the motherboard so that they can scale past 8 sockets well (well is a relative term BTW, compared to Itanium or POWER5 the performance scaling is still pretty lousy).Quote:
Originally Posted by Piotrsama