• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Why is SNB-E's memory bandwidth worse than SNB's?

Page 2 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
Is that the date apple will get them or is this the date macpros will be boxed and ready for my grubby little hands to subvert its clock cycles?

Neither. That's the official date Intel will release the Xeon E5 chips. It will go into vendors hands before that, and very likely we'll see systems at that day as well. I'm not sure if Apple will do it the same day though.
 
Why threads become a factor in this test? it doesn't make sense to me...Low power in 1 thread version with parts of IMC closed?
 
I am pretty sue Nehalem was 100% a better processor than Penryn. That was a pretty BIG jump in performance at lower mhz even.
http://www.anandtech.com/show/2658/4
Some things prefer the fat cache offered by Penyrn. Not many, but enough to make it not unequivocally better. It was a big enough controversy to warrant its own article.

Consumers wanted Penyrn with an IMC. Enterprises wanted more scalability. Enterprises won.
 
http://www.anandtech.com/show/2658/4
Some things prefer the fat cache offered by Penyrn. Not many, but enough to make it not unequivocally better. It was a big enough controversy to warrant its own article.

Consumers wanted Penyrn with an IMC. Enterprises wanted more scalability. Enterprises won.

My disagreement is with your logic here. Nehalem improved in SO many areas over Penryn. If you improve in 9 areas, and slide a little in the 10th, the overall product IS equivocally better. I have yet to really see a benchmark where Nehalem was slower per clock than Penryn in anything. I could be wrong though.
 
Is that the date apple will get them or is this the date macpros will be boxed and ready for my grubby little hands to subvert its clock cycles?

I thought there were rumours that Apple might wait until IB-E to refresh Mac Pro? Maybe I have it backwards and that was something them skipping IB-E for Haswell-E.
 
I thought there were rumours that Apple might wait until IB-E to refresh Mac Pro? Maybe I have it backwards and that was something them skipping IB-E for Haswell-E.

I hope not. The current macpro is 2 years old! I honestly don't think they will wait. People are fed up and we know they aren't killing the macpro because their has been no eol announcement like with Xserve.

I heard ib-e is another 13 months away at least. It would be nice to get sb-e and then skip ib and get a haswell macpro
 
I heard ib-e is another 13 months away at least. It would be nice to get sb-e and then skip ib and get a haswell macpro

Or it could be simply that they are going to release it with Sandy Bridge EP chips. They use Westmere EP chips, and they are not cheap. I haven't seen many Apple rumors that were credible, people spreading them hype them too much so its unrealistic in any sense.

Haswell-E coming in 13 months is not likely. That's when the regular chips are arriving. Server chips will take additional time. If anything, I can see Ivy Bridge E(not EP, aka Xeons), coming a few months earlier from the typical 1 year schedule and see the light of day in Q3/Q4 this year.
 
Shows 312GB/sec for L3.

sisoft-3960x-cache.png
 
Same thing that plagued BD. It's like a moore's law of exponents. If you go from 1 to 2 it is a small penalty. But when you go from 2 to 4 the penalty is 4 times as large. More interconnects, more wires, more latency. It makes me wonder how much faster memory would be if the bus was still just 64 bits. Mr Rambus is laughing.
 
My disagreement is with your logic here. Nehalem improved in SO many areas over Penryn. If you improve in 9 areas, and slide a little in the 10th, the overall product IS equivocally better. I have yet to really see a benchmark where Nehalem was slower per clock than Penryn in anything. I could be wrong though.
Keep in mind these are stock tests (Read: Turbo On).
17780.png
17767.png
 
Maybe the ring stops are still there?

This here is the winner. If they want to be able to do sensible chip harvesting, they need to be able to turn off *any* of the cores, not just the ones at the end. This means it's unfeasible to "shortcut" the ring.
 
Keep in mind these are stock tests (Read: Turbo On).
17780.png
17767.png

well you did prove your point with those 2 benchmarks.

But overall he is still correct.

Not to mention those numbers are well within the margin for error.

some of those test show a 1.2 fps increase......
 
http://www.realworldtech.com/page.cfm?ArticleID=RWT072811020122

Apparently SNB-E's LLC clock is ~1-1.5GHz? Doesn't that mean it's WAY slower than a consumer SNB chip?

RWT posted a new article about SNB-E, which had this correction:

We significantly under-estimated the ring bus and LLC frequency at 1-1.5GHz. It turns out that the cache and two 32B data rings in the system fabric run at core frequency providing up to 844GB/s of fabric bandwidth, which is amazing given the power constraints. This reduces the cache and memory latency and also simplifies the validation. More importantly, it is a huge improvement in bandwidth over Westmere-EP, where the LLC was implemented as a single partition. In that respect, the Sandy Bridge-EP cache is much more similar to the highly scalable Westmere-EX.
 
I'm gonna be honest...really, really impressed with SNB-EP with what they were able to do with 130-150W. Good job, Intel. Now, all I need is several grand of totally disposable cash and then I can get two 2687W chips to play with 😛
 
Back
Top