1M Total L2 cache for Windsor?
Printable View
1M Total L2 cache for Windsor?
1 meg per core
you'd hope so, but it's not specific. for the current chips they give per core numbers, but aren't specific for windsor or the other next gen parts.
AMD chips are not cache cows.Quote:
Originally Posted by onewingedangel
Quit getting hung up on comparisons to Conroe, just because 4MB+ is worthwhile for that chip doesn't mean that is also true for what AMD is putting out.
They have totally different cache structures (ie. exclusive vs. inclusive, large L1's vs. mod.-small L1's, differing amounts of bandwidth and latency between L1's and L2's, etc.), and so a direct comparison is difficult if not impossible to make.
FWIW past 512KB L2 performance gains are minimal for AMD chips which makes sense since cache eats up die space so AMD would do everything possible to optimize thier CPU so that is less reliant on cache, Intel on the other hand has more fab space than they know what to do with so it makes lots of sense for them to put tons of cache on thier chips.
Q3-06 to H1-08 isn't a length of time? According to AMD their focus for 2007 is to get 65nm production ramping, add power saving, SOI process improvements and security features to the existing K8 (Brisbane, Sparta) and launch K8L Opterons in late 2007 and K8L Athlons in H1-08.Quote:
Originally Posted by Carfax
Hey, I can make those too! The problem with 3rd party roadmaps is that they're made by 3rd parties. :rolleyes:Quote:
Originally Posted by The Ghost
AMD's L2 cache is so slow in comparison to Intel's L2 that AMD can't afford to make it any larger (and subsequently slower). Now if AMD could produce a fast, efficient L2 cache like Intel's, they would most likely benefit from larger cache sizes as Intel does.Quote:
Originally Posted by mesyn191
Quote:
Originally Posted by The Ghost
I am sorry, but where is the source of this?
What are you talking about? Latency-wise they're almost dead even:Quote:
Originally Posted by Fred_Pohl
http://www.anandtech.com/cpuchipsets...spx?i=2748&p=2
Any bandwidth differences between the 2 is because AMD uses a 128 bit bus vs. Intel's 256 bit bus, that has nothing to do with L2 "speed".
AMD is fab space limited, not process limited, this affects all thier arch. decisions first and fore most.
2way vs 8 way anyone??
then do your self a favor and do a search on amd bribaneQuote:
Originally Posted by Fred_Pohl
like maybe one like this
http://www.mikeshardware.co.uk/Roadm...AMD%20Brisbane
how many more would you want john ?? :stick:
What makes you think they can't do this and ramp .65 at the same time? They've intro'd core refresh on a new process before you know, as has Intel...Quote:
Originally Posted by Fred_Pohl
From a process standpoint fabbing the current K8 rev. and K8L would be just as hard barring yield issues due to die size.
and this would be the reason why amd is going to use z-ram on it's L3 cache because it's L2 is so slow ?? amd does not need a large cache because it's memory controller is so efficient :slap:Quote:
Originally Posted by Fred_Pohl
the person asked me not to give his site as the source , but from all that i have read it is legitQuote:
Originally Posted by vitaminc
I meant "slow" as in unable to provide nearly as much bandwidth to the cores when they need it, making the cores wait, hence "slow". Yes, AMD's L2 cache has similar latency to Intel's L2 but with substantially less bandwidth, woefully inferior prefetching and a much greater cache miss rate. Then there is also the issue of Core 2's far superior shared L2 cache vs AMD's exclusive L2 cache. What I'm saying is that the reason larger L2 caches don't benefit K8 very much is because as the cache size is increased, latency goes up but bandwidth doesn't. This means that K8 won't benefit from a larger L2 cache because the bandwidth to make use of it isn't there.Quote:
Originally Posted by mesyn191
The bottom line is that if AMD's L2 cache was as wide and efficient as Intel's, there would be an immediate benefit from increasing the L2 cache size above 1MB per core. Obviously, accessing a fast L2 cache is far better than going to main memory even with an ODMC and a 10-15% latency advantage over Intel's NBMC.
I've seen the same Brisbane = K8L rumor parrotted at several different places. That doesn't make it any less fictional.Quote:
Originally Posted by The Ghost
BTW, who is John?
And if Intel made everything else work as fast as Amd does, maybe they won't needed dumb amounts of L2 cache, resulting in new generation cpu's that once the cache is trashed, have wrost performance that old generation cpu's.Quote:
Originally Posted by Fred_Pohl
Lukely for Intel, in desktop that isn't really a issue, i think.
And another one:
http://www.matbe.com/actualites/1317...dmap-quadcore/
Brisbane and Deerhound both have rev.g (K8L)
It all points to Amd dual cores at 65nm powered by K8L, by december, January.
It's not what I think they can or can't do. It's simply a matter of trusting what AMD says they're going to do more than what certain rumormill sources speculate they're going to do. If I've learned anything over the years it's that rumormill speculation has never proven to be more accurate than official AMD roadmaps and statements.Quote:
Originally Posted by mesyn191
anyone here wanna help me make a 10% share buy of AMD so i can get all the answers?
WTF are you babbling about? Core 2 Duo is at least 20% faster than X2 at the same clock speeds, regardless of cache size. AMD's ODMC gives them only a 10-15% latency advantage in main memory accesses and that is still a lot slower than accessing L2 cache. Get a clue.Quote:
Originally Posted by DoubleZero
There is a lot of speculation out there. Did you see the story by The Inq back in March claiming that AMD was going to announce that 65nm AM2 cpus would be available in June 2006?
sorry about calling you john , that was one of your buddies over at the ZoneQuote:
Originally Posted by Fred_Pohl
try doing your own google search on amd brisbane K8L
http://www.google.com/search?sourcei...d+brisbane+k8l
LOL! So a 10-15% latency advantage in main memory accesses from their ODMC makes cache irrelevant?Quote:
Originally Posted by The Ghost
The reason AMD is adding L3 cache is because, although slower than L2 cache, it is still a lot faster than main memory. If AMD could produce better L2 cache they wouldn't need to add the extra latency of an L3 cache. If and when AMD can produce an efficient, shared L2 cache, they'll drop the L3 in a heartbeat.
I have tried that and found a few hits all based on the original rumor and that 3rd party roadmap you posted. Try googling for 'Brisbane' without 'K8L' or 'K8L' without 'Brisbane' and see how many references you find to Brisbane being K8L. Try checking AMD's official roadmaps while you're at it.Quote:
Originally Posted by The Ghost
I'm sorry if it upsets you to hear this but Brisbane being K8L is nothing more than another speculative rumor designed to encourage people to buy AM2 now with the hope of upgrading to Brisbane in Q1-07 instead of buying Conroe in Q4-06 when it's mopping the floor with AM2.
The bandwidth difference has nothing to do with the L2 cache itself, the bus on the K8 is 128 bit vs. Intels 256 bit bus. That is all there is to it...Quote:
Originally Posted by Fred_Pohl
I'm sorry but you're gonna have to post links backing this up that is true vs. what AMD has right now (ie. P4...). Everything I've heard suggests thier prefetching is pretty good as is thier BPU. As good as Conroe's? Probably not, but then its a new arch. so what do you expect? Conroe still aint' out yet, and vs. Netburst what the K8 has had so far has worked pretty damn good, don't you think? So I think calling it "woefully inferior" is making mountains out of mole hills.Quote:
Originally Posted by Fred_Pohl
Supieror how? For mult. threaded apps sure, a shared cache is better than 2 split L2's but for everything else there is nothing inheritly better about Conroe's cache scheme. Inclusive vs. exclusive is all about saving die space vs. design simplicity BTW.Quote:
Originally Posted by Fred_Pohl
I'm sorry but this is totally wrong, or at the very least highly speculative that all code will be limited by L2 bandwidth. Most code is dependant on latency instead of bandwidth as it is highly random in nature...Quote:
Originally Posted by Fred_Pohl
I would disagree, AMD's problem with the K8 currently is with the decoders, not L2 bandwidth. Whats the point of having a high bandwidth L2 if the core can't make use of it since its waiting for instructions to be decoded most of the time right?Quote:
Originally Posted by Fred_Pohl
Now with K8L that will change, the effectively single cycle SSE2 FPU that it'll have WILL require lots of L2 bandwidth to make proper use of, and in that instance AMD might indeed be limited by thier L2 in situations that stream lots of SSE2 FP code. Right now though the L2 is fine, only thing they'd have to do is modify thier ODMC and supporting hardware in the CPU to support a shared L2 (or as in K8L's case, a shared L3) and it'd be on par with what Conroe has to offer as far as the mem. subsystem goes.
how do you know fred , that it is 20% faster ? did your employer let you play with them ?Quote:
Originally Posted by Fred_Pohl
and doesn't need 65nm to compete with intel , most people have figured that out already , just wait for the release next week
you see that is the difference , we don't have one to test , and what you are comparing isn't the cpu that is going against the mighty powerful conroe by the time conroe gets out in force next year , the bribane will be there waiting on it ,, what % is the conroe suppose to be of all the cpu's that intel is putting out ? 20% ?? personally , i don't see conroe being a factor , you have to make enough cpu's to make worth while , why do you think that intel is putting the woodcrest out first ? because they know that there is no market for them to start with
when a company starts selling off things like their flash and communications units , we know that they are in more trouble that they are letting out , i had a laugh when some one suggested that intel was going to buy out ATI
http://www.theregister.co.uk/2006/05...ndit_forecast/