More Core i7 trichannel "failure" from "thiefs"

[Drwho?]

Are you absolutely sure? From various sources I've heard (and seen) that the difference in performance between dual and triple channel is close to nothing. Actually, I am not quite sure yet, because the extra channel should be adding much more bandwidth than the 500MB's I've seen (DDR3 @ 933MHz, exact same system settings). It's either Lavalys Everest that screws up, although I'm not likely to believe that, or something in the bios/motherboard design of the Intel reference motherboard is making the triple channel run at dual channel, which also would surprise me.

What are the possible underlying causes that make people report a lack of performance gain going from dual channel to triple channel? Software/hardware?

I always said that Core 2 Quad does not need much mem Bandwidth, so, on real application, if memory is not important, you will see very little from Mem Bandwidth.
In the mean time, on application like SETI, Rosetta, folding@home, you got to feed 8 threads, the bandwidth will come handy. If you do H264 with profile level 4, you ll go and see 16 frames in both directions, this will get handy too.

Just remember, to keep 8 threads happy, you ll need the bandwidth, it is just a matter of time before the software use it 100%.
I heard people telling me that nobody will use MMX, it was so hard to use ... Today, you can t boot most of the OS without it.

and yes, I am very sure that 3 Dimms goes faster than 2 Dimms. (on mem test) If it does not, the proto is broken

[massman]

I always said that Core 2 Quad does not need much mem Bandwidth, so, on real application, if memory is not important, you will see very little from Mem Bandwidth.
In the mean time, on application like SETI, Rosetta, folding@home, you got to feed 8 threads, the bandwidth will come handy. If you do H264 with profile level 4, you ll go and see 16 frames in both directions, this will get handy too.

Just remember, to keep 8 threads happy, you ll need the bandwidth, it is just a matter of time before the software use it 100%.
I heard people telling me that nobody will use MMX, it was so hard to use ... Today, you can t boot most of the OS without it.

and yes, I am very sure that 3 Dimms goes faster than 2 Dimms. (on mem test) If it does not, the proto is broken

Thanks for the reply.

If I understand correctly, we should all notice the difference between dual and triple channel, but it's very likely that if we use non-multicore applications that the difference will be very small. The bandwidth that is added because of the extra channel is to provide enough bandwidth to fully cover the 8 threads, but is 'overkill' when using in single/dual threaded applications.

Now, that only leaves the everest bandwidth problems. As far as I know, the Lavalys Everest program is quite accurate when it comes to calculating the memory bandwidth and latency, but in tests I've seen the difference still is only 500MB/s:



Maybe this is the problem:

Lavalys Everest 4.60 new features & improvements:

- Asus EPU and Gigabyte DES support
- Enhanced hardware monitoring capabilities
- Optimized benchmarks for Intel Atom and VIA Nano
- Preliminary support for Intel Core i7 and X58
- Support for the latest chipset and graphics technologies



Only two tests actually show the difference between dual and triple channel, which probably is the correct performance scaling.

[JumpingJack]

Thanks for the reply.

If I understand correctly, we should all notice the difference between dual and triple channel, but it's very likely that if we use non-multicore applications that the difference will be very small. The bandwidth that is added because of the extra channel is to provide enough bandwidth to fully cover the 8 threads, but is 'overkill' when using in single/dual threaded applications.

What it boils down to is that most of today's client applications do not produce a demand that exceeds even modest memory bandwidths, aided with a strong cache structure. Increase in BW either by clocking up the bus or increasing memory clocks gives minor improvements, in most cases -- some exceptions are WinRAR's internal benchmark which all it does is read/writes random data to memory while executing it's compression engine... it shows significant sensitivty to BW. I have also seen noteable sensitivity with Mainconcepts H264 encoder.

So, in what Dr. Who? is saying, at 12 GB/s + memory bandwidth is not really going to impact what you observe in real life -- not because the BW is not real, but because the applications used for desktop never deman throughput that exceeds the capabilities.

You will see the BW play an important role in 2S servers, where those applications are more throughput oriented as opposed to client side which are really just task based.

[justthefax]

Anybody notice the big jump in latency going to tri-channel? Around 15% worse latency

Thanks for the reply.

If I understand correctly, we should all notice the difference between dual and triple channel, but it's very likely that if we use non-multicore applications that the difference will be very small. The bandwidth that is added because of the extra channel is to provide enough bandwidth to fully cover the 8 threads, but is 'overkill' when using in single/dual threaded applications.

Now, that only leaves the everest bandwidth problems. As far as I know, the Lavalys Everest program is quite accurate when it comes to calculating the memory bandwidth and latency, but in tests I've seen the difference still is only 500MB/s:




Only two tests actually show the difference between dual and triple channel, which probably is the correct performance scaling.

[xVeinx]

Anybody notice the big jump in latency going to tri-channel? Around 15% worse latency

And if you look, his timings have changed

[Shintai]

Anybody notice the big jump in latency going to tri-channel? Around 15% worse latency

The clocks and settings of the memory aint the same either.

Plus we dont know the BIOS version.

[JumpingJack]

Anybody notice the big jump in latency going to tri-channel? Around 15% worse latency

Yeah, huge.... trichannel has a whole 25 ns of latency... how terrible.

[Drwho?]

Anybody notice the big jump in latency going to tri-channel? Around 15% worse latency

Actually, the problem is not the hardware here, it is the software, I have my friend Ronen working with the everest guys, I am not sure of the status, but I know from sure that the processor affinities does not allow the max bandwith to be always measured properly.

I will check and update you guys later, Monday.

In the mean time, this 2 numbers shows that Core i7 is the 1st having a real integrated memory controler .. (kidding! don t shoot!)

If you use Sandra, you will see that Banwidth is better with 3.

Francois

[massman]

The crysis is loading times. Most of the restriction is HD based.

Seriously? I don't really find that a propper way to compare hardware, although these are more real-life measurements than raw numbers.

Actually, the problem is not the hardware here, it is the software, I have my friend Ronen working with the everest guys, I am not sure of the status, but I know from sure that the processor affinities does not allow the max bandwith to be always measured properly.

Good, let's hope the preliminary support gets turned into full support sooner than later.

[Shintai]

Seriously? I don't really find that a propper way to compare hardware, although these are more real-life measurements than raw numbers.

Yes, seriously. xtreview just stole the numbers and posted it as their own. (And thereby completely skipping all explanations).

But as said, you can read it yourself.



Also a note that this aint benched on the newest versions to say it mildly.

[AuDioFreaK39]

Thanks for the reply.

If I understand correctly, we should all notice the difference between dual and triple channel, but it's very likely that if we use non-multicore applications that the difference will be very small. The bandwidth that is added because of the extra channel is to provide enough bandwidth to fully cover the 8 threads, but is 'overkill' when using in single/dual threaded applications.

Now, that only leaves the everest bandwidth problems. As far as I know, the Lavalys Everest program is quite accurate when it comes to calculating the memory bandwidth and latency, but in tests I've seen the difference still is only 500MB/s:

Why is the CPU 22MHz faster for the dual-channel benchmark and 11MHz faster on the memory than the triple-channel benchmark?



http://xtreview.com/addcomment-id-66...s-SMT-OFF.html


and also, shouldn't the dual-channel benchmark pwn the single much more than this?

[massman]

it could be early bioses as well who knows

but i would definitely NOT trust software like sandra

32M SuperPi is still the best measure....tapakah is showing a 1% difference with same settings.......that is pretty big for Pi so i'll take it

I'd trust Lavalys/Sandra more than Superpi, to be honest, especially when you want to put a number on the performance scaling of brand new technology. Superpi is good if you want to compare technology you understand, not really that good if you don't know the technology by heart.

Bios release is a possibility, but I can't understand why Intel would send out motherboards that don't feature the benefits of triple channel right away. This is one of the KEY features of the X58/Nehalem platform, it wouldn't make any sense.

In addition, even if the bios isn't ready, why would Intel keep this information internal? They know people will focus on this features, why on earth would they choose for the path that leads to bad publicity when different reviewing websites claim triple channel just doesn't work.

Nvidia 680i gives me almost 100% more bandwidth going from single to dual channel, not sure about Intel chipsets as I have never tested it using Sandra.

Different settings, different results. All I know is that the results of the triple channel that we see now is way too low to be correct. And if they are correct ...

They are so wrong...at least in the tests we ran.

Just got the QPI performance scaling confirmed by another source, so I wonder what tests you ran ;-).

This makes me certain that I'll need a setup myself to test everything out. Why oh why did I pass for the Madshrimps Nehalem coverage ...

Well, NF2 was back in 2002, 6 years ago. Memory bandwidth demand has increased quite alot from those days, and thus the comparison from NF2 is quite much worthless IMO. Besides, I only saw sub 15 % improvements, though, the RAM was cheap kingston and FSB was sub 166 all the time.

Actually, I was comparing with NF2, because that's when I first experienced the benefit of dual channel, just like the Core I7 is the first platform that uses triple channel.

I was running 260+ FSB, maybe not such a fair comparison.

To be honest, I should re-read some reviews to draw a decent conclusion, but I think you get my point when I show you the table with 0% improvement going from dual to triple channel. In the past we always DID notice the bandwidth increasements, 'we' as in the (extreme) overclockers. The fact that we are NOT noticing them at the moment is a sign.

What it boils down to is that most of today's client applications do not produce a demand that exceeds even modest memory bandwidths, aided with a strong cache structure. Increase in BW either by clocking up the bus or increasing memory clocks gives minor improvements, in most cases -- some exceptions are WinRAR's internal benchmark which all it does is read/writes random data to memory while executing it's compression engine... it shows significant sensitivty to BW. I have also seen noteable sensitivity with Mainconcepts H264 encoder.

So, in what Dr. Who? is saying, at 12 GB/s + memory bandwidth is not really going to impact what you observe in real life -- not because the BW is not real, but because the applications used for desktop never deman throughput that exceeds the capabilities.

You will see the BW play an important role in 2S servers, where those applications are more throughput oriented as opposed to client side which are really just task based.

In real-life applications, I don't even worry about dual channel. You're not going to notice anything when opening Internet Explorer or Word, but you will notice when you run resource hungry programs such as video encoding or data compression programs. But isn't the Core I7 / X58 platform designed for the normal end-user? I don't see why you bring up the 2S server example, because it has nothing to do with dual/triple channel working or not.

My question is why we don't see any improvement in benchmarks, which very often extrapolate the differences in performance. When we see differences in benchmark utilities, we can be sure (or not) if technology is working, even at 12GB/s.

Why is the CPU 22MHz faster for the dual-channel benchmark and 11MHz faster on the memory than the triple-channel benchmark?

http://xtreview.com/addcomment-id-66...s-SMT-OFF.html
http://xtreview.com/images/corei712and3chanel06.png

and also, shouldn't the dual-channel benchmark pwn the single much more than this?

No idea why they are not clocked exactly the same, not my benchmarks anyway. The small difference in frequency is NOT the reason why the differences in performance are this small, though ;-).

And yeah, the xtreview benchmarks are screwed, I think.

[Drwho?]

I'd trust Lavalys/Sandra more than Superpi, to be honest, especially when you want to put a number on the performance scaling of brand new technology. Superpi is good if you want to compare technology you understand, not really that good if you don't know the technology by heart.

Bios release is a possibility, but I can't understand why Intel would send out motherboards that don't feature the benefits of triple channel right away. This is one of the KEY features of the X58/Nehalem platform, it wouldn't make any sense.

In addition, even if the bios isn't ready, why would Intel keep this information internal? They know people will focus on this features, why on earth would they choose for the path that leads to bad publicity when different reviewing websites claim triple channel just doesn't work.



Different settings, different results. All I know is that the results of the triple channel that we see now is way too low to be correct. And if they are correct ...



Just got the QPI performance scaling confirmed by another source, so I wonder what tests you ran ;-).

This makes me certain that I'll need a setup myself to test everything out. Why oh why did I pass for the Madshrimps Nehalem coverage ...



Actually, I was comparing with NF2, because that's when I first experienced the benefit of dual channel, just like the Core I7 is the first platform that uses triple channel.

I was running 260+ FSB, maybe not such a fair comparison.

To be honest, I should re-read some reviews to draw a decent conclusion, but I think you get my point when I show you the table with 0% improvement going from dual to triple channel. In the past we always DID notice the bandwidth increasements, 'we' as in the (extreme) overclockers. The fact that we are NOT noticing them at the moment is a sign.



In real-life applications, I don't even worry about dual channel. You're not going to notice anything when opening Internet Explorer or Word, but you will notice when you run resource hungry programs such as video encoding or data compression programs. But isn't the Core I7 / X58 platform designed for the normal end-user? I don't see why you bring up the 2S server example, because it has nothing to do with dual/triple channel working or not.

My question is why we don't see any improvement in benchmarks, which very often extrapolate the differences in performance. When we see differences in benchmark utilities, we can be sure (or not) if technology is working, even at 12GB/s.



No idea why they are not clocked exactly the same, not my benchmarks anyway. The small difference in frequency is NOT the reason why the differences in performance are this small, though ;-).

And yeah, the xtreview benchmarks are screwed, I think.

You got a very valid point, only the people with access to the official press kit can access to the lastest BIOS, this one has a very important patch for the memory controler. If you use a prototype of Smackover, without this bios (version has to be superior of 2000), you are not optimum
For other motherboard maker, make sure you get the latest BIOS released this week.