標題: [硬件] VR-Zone SB-E Price [打印本頁]

---

作者: qcmadness    時間: 2011-8-16 09:43     標題: VR-Zone SB-E Price

Core i7-3820: 4c8t, 3.6GHz/3.9GHz, 10MB L3 cache, 130W TDP, $294
Core i7-3930K: 6c12t, 3.2GHz/3.8GHz, 12MB L3 cache, 130W TDP, $583
Core i7-3960X: 6c12t, 3.3GHz/3.9GHz, 15MB L3 cache, 130W TDP, $999

果然無平野:smoke

http://vr-zone.com/articles/inte ... urprises/13298.html

---

作者: ccw    時間: 2011-8-16 09:48

引用:

原帖由 qcmadness 於 2011-8-16 09:43 發表
Core i7-3820: 4c8t, 3.6GHz/3.9GHz, 10MB L3 cache, 130W TDP, $294
Core i7-3930K: 6c12t, 3.2GHz/3.8GHz, 12MB L3 cache, 130W TDP, $583
Core i7-3960X: 6c12t, 3.3GHz/3.9GHz, 15MB L3 cache, 130W TDP, $999
...

$294 very ok la.
It will out-perform 2600k in software like Photoshop CS5 with its quad channel ram.

---

作者: qcmadness    時間: 2011-8-16 10:01

引用:

原帖由 ccw 於 2011-8-16 09:48 發表

$294 very ok la.
It will out-perform 2600k in software like Photoshop CS5 with its quad channel ram.

no

2600k can oc while 3820 cannot

---

作者: ccw    時間: 2011-8-16 10:06

引用:

原帖由 qcmadness 於 2011-8-16 10:01 發表

no

2600k can oc while 3820 cannot

Sure if you take OC as an adv of 2600k, while personally I insist on sticking with stock freq.
And is it really freq dependent on tasks like Photoshop CS5?

I have heard that a i7 950 can beat 2600 in CS5 with its tri-channel ram, it looks Ram speed can be the bottleneck of performance in some cases.

[ 本帖最後由 ccw 於 2011-8-16 10:13 編輯 ]

---

作者: qcmadness    時間: 2011-8-16 10:15

引用:

原帖由 ccw 於 2011-8-16 10:06 發表

Sure if you take OC as an adv of 2600k, while personally I insist to stick with stock freq.
And is it really freq dependent on tasks like Photoshop CS5?

I have heard that a i7 950 can beat 2600 in C ...

yes, freq dependent

http://www.anandtech.com/bench/CPU/25?i=287.288.363.192.100.47

---

作者: ccw    時間: 2011-8-16 10:34

引用:

原帖由 qcmadness 於 2011-8-16 10:15 發表


yes, freq dependent

http://www.anandtech.com/bench/CPU/25?i=287.288.363.192.100.47

Oh, you are correct, even in CS5:
http://www.tomshardware.com/char ... dobe-Photoshop-CS-5,2426.html

---

作者: qcmadness    時間: 2011-8-16 10:40

photoshop最重要係freq, 之後先到no. of cores...

---

作者: ccw    時間: 2011-8-16 10:43

引用:

原帖由 qcmadness 於 2011-8-16 10:40 發表
photoshop最重要係freq, 之後先到no. of cores...

I see, I did heard someone claiming that the no. of ram channels made a difference for CS5(not 4),
while I cannot remember where I read that.

It was once forwarded by me to this forum.

---

作者: qcmadness    時間: 2011-8-16 10:45

引用:

原帖由 ccw 於 2011-8-16 10:43 發表

I see, I did heard someone claiming that the no. of ram channels made a difference for CS5(not 4),
while I cannot remember where I read that.

It was once forwarded by me to this forum.

都唔出奇... 但係相信影響無cpu freq咁大

---

作者: ccw    時間: 2011-8-16 10:50

引用:

原帖由 qcmadness 於 2011-8-16 10:45 發表

都唔出奇... 但係相信影響無cpu freq咁大

That's what makes me think that SBE 4C8T w/ quad channel rams can be favoring some specific tasks that i7 2600 may show its weakness at.

For it being priced the same as i7 2600, no doubt it is a new hot cake for computer builders, while some may stick with 2600k for its overclock-ability.

---

作者: qcmadness    時間: 2011-8-16 11:54

引用:

原帖由 ccw 於 2011-8-16 10:50 發表

That's what makes me think that SBE 4C8T w/ quad channel rams can be favoring some specific tasks that i7 2600 may show its weakness at.

For it being priced the same as i7 2600, no doubt it is a new ...

so little tasks benefit from extra memory channels...

---

作者: rickywk    時間: 2011-8-16 12:12

傳聞話唔跟cpu fan/heatsink喎

---

作者: ccw    時間: 2011-8-16 13:19

引用:

原帖由 rickywk 於 2011-8-16 12:12 發表
傳聞話唔跟cpu fan/heatsink喎

Looks confirmed for SBE without HSF,
and high end BD will be having liquid cooling......

---

作者: Henry    時間: 2011-8-16 15:43

引用:

原帖由 qcmadness 於 2011-8-16 10:01 發表

no

2600k can oc while 3820 cannot

No OC multi =/= no OC bus.

---

作者: Henry    時間: 2011-8-16 15:45

引用:

原帖由 qcmadness 於 2011-8-16 11:54 發表

so little tasks benefit from extra memory channels...

Video editing.
Why CUDA can do much faster than CPU, one of the reason is RAM bandwidth.

---

作者: ccw    時間: 2011-8-16 16:07

引用:

原帖由 Henry 於 2011-8-16 15:43 發表

No OC multi =/= no OC bus.

But it is quite certain that without OC multi, not much gain can be achieved.

---

作者: qcmadness    時間: 2011-8-16 16:14

引用:

原帖由 Henry 於 2011-8-16 15:45 發表

Video editing.
Why CUDA can do much faster than CPU, one of the reason is RAM bandwidth.

of course not...

CUDA / Quicksync do faster because they are not flexible

---

作者: ccw    時間: 2011-8-16 16:21

引用:

原帖由 qcmadness 於 2011-8-16 16:14 發表

of course not...

CUDA / Quicksync do faster because they are not flexible

Like a pair of human hands vs a bunch of robot arms

---

作者: Henry    時間: 2011-8-16 17:13

引用:

原帖由 qcmadness 於 2011-8-16 16:14 發表

of course not...

CUDA / Quicksync do faster because they are not flexible

simple maths, but many ops which is not much predictable and few can be cached in L2, so bandwidth to RAM is important. (need big fast pool)
QS not to comment, as mechanism is different.
CUDA, if low bandwidth, should also eat C.

---

作者: qcmadness    時間: 2011-8-16 19:59

引用:

原帖由 Henry 於 2011-8-16 17:13 發表

simple maths, but many ops which is not much predictable and few can be cached in L2, so bandwidth to RAM is important. (need big fast pool)
QS not to comment, as mechanism is different.
CUDA, if low ...

cuda / qs做得好既, 都係d predictable既code... 你既concept有少少問題

---

作者: Henry    時間: 2011-8-16 23:20

引用:

原帖由 qcmadness 於 2011-8-16 19:59 發表

cuda / qs做得好既, 都係d predictable既code... 你既concept有少少問題

我講既係Data，唔係code.

---

作者: qcmadness    時間: 2011-8-17 00:29

引用:

原帖由 Henry 於 2011-8-16 23:20 發表

我講既係Data，唔係code.

SIMD data唔駛太大的memory bandwidth

predict到, prefetch到既, 根本唔需要大bandwidth
graphics要咁大bandwidth有時係因為predict唔到

---

作者: Henry    時間: 2011-8-17 01:22

引用:

原帖由 qcmadness 於 2011-8-17 00:29 發表

SIMD data唔駛太大的memory bandwidth

predict到, prefetch到既, 根本唔需要大bandwidth
graphics要咁大bandwidth有時係因為predict唔到

The matrices to be processed in film ripping is similar to those in 3D games, often not so predictable. SIMD and AVX do help some due to data batching and perform vector or matrix operations each time instead of only one value.
But it doesn't mean bandwidth can be saved.

---

作者: Henry    時間: 2011-8-17 01:26

引用:

原帖由 ccw 於 2011-8-16 16:21 發表

Like a pair of human hands vs a bunch of robot arms

The robot arms have no use if the transporting band is so slow.

---

作者: qcmadness    時間: 2011-8-17 01:46

引用:

原帖由 Henry 於 2011-8-17 01:22 發表

The matrices to be processed in film ripping is similar to those in 3D games, often not so predictable. SIMD and AVX do help some due to data batching and perform vector or matrix operations each tim ...

if you know the latency of a SIMD / AVX instruction, you will know why i say that the bandwidth is not important

and do you remember why p4 > c2d has doubled the SSEx performance while the bandwidth remained the same?

---

作者: qcmadness    時間: 2011-8-17 01:47

引用:

原帖由 Henry 於 2011-8-17 01:26 發表

The robot arms have no use if the transporting band is so slow.

and benchmarks already show that the bandwidth is more than enough and doubling the bandwidth DOES NOT HELP.

---

作者: qcmadness    時間: 2011-8-17 01:49

and show your data to support your claim that the extra bandwidth will help a lot in some tasks.

---

作者: qcmadness    時間: 2011-8-17 01:55

http://www.anandtech.com/bench/Product/100?vs=108

i7 950: 3.06GHz / 3.33GHz Turbo / 32.0 GB/s
i7 860: 2.80GHz / 3.46GHz Turbo / 21.3 GB/s

The max of ~10% gain is nowhere significant

---

作者: Henry    時間: 2011-8-17 02:53

引用:

原帖由 qcmadness 於 2011-8-17 01:46 發表

if you know the latency of a SIMD / AVX instruction, you will know why i say that the bandwidth is not important

and do you remember why p4 > c2d has doubled the SSEx performance while the bandwidth ...

P4 => lost data in pipeline and need redo, that's why per cycle performance is even worse than PIII.
C2D => basically a PIII-S with P4 cache fetch. (Of course with some innovations inside)
i7 => a balance between C2D and P4, take both advantages plus HT tweak.

latency => CL in RAM/cache
bandwidth => MHz*bits in RAM/cache
2 different aspects.

---

作者: Henry    時間: 2011-8-17 02:59

引用:

原帖由 qcmadness 於 2011-8-17 01:55 發表
http://www.anandtech.com/bench/Product/100?vs=108

i7 950: 3.06GHz / 3.33GHz Turbo / 32.0 GB/s
i7 860: 2.80GHz / 3.46GHz Turbo / 21.3 GB/s

The max of ~10% gain is nowhere significant

Increase in bandwidth needs the help of architecture in order to have improvements.
860 and 950 basically is the same chip.

If as you said, bandwidth is not so important, I think CUDA cards in datacenter or rendering farm should have 128bit/192bit memory instead in order to cut cost.
display card with large OPs is somehow different from a CPU now.
But if CPU have more and more cores and want to gain performance, a large RAM bandwidth should be fulfilled.

[ 本帖最後由 Henry 於 2011-8-17 03:01 編輯 ]

---

作者: qcmadness    時間: 2011-8-17 03:38

引用:

原帖由 Henry 於 2011-8-17 02:59 發表

Increase in bandwidth needs the help of architecture in order to have improvements.
860 and 950 basically is the same chip.

If as you said, bandwidth is not so important, I think CUDA cards in datac ...

if you know tesla has a much lower bandwidth than their desktop counterparts, do you still insist that bandwidth should be as important?

you cannot cut some memory channels in gpus easily because it is tied with ROPs and other parts such as L2 cache that are considered architectural...
you are comparing things that are vastly different

because 860 and 950 are architectually similar, it just proves that adding another memory channel YIELDS LITTLE.

---

作者: qcmadness    時間: 2011-8-17 03:43

引用:

原帖由 Henry 於 2011-8-17 02:59 發表

Increase in bandwidth needs the help of architecture in order to have improvements.
860 and 950 basically is the same chip.

If as you said, bandwidth is not so important, I think CUDA cards in datac ...

and the large bandwidth is only useful when 2-way and 4-way processors are used

you still don't know why intel and amd wants more memory channels for servers

for desktop, even single channel memory will not scarify much unless IGP / iGPU is used

---

作者: qcmadness    時間: 2011-8-17 03:44

you still need some backing benchmarks to prove that adding more memory channels does help

---

作者: qcmadness    時間: 2011-8-17 03:52

http://www.anandtech.com/show/45 ... ing-the-best-ddr3/8

引用:

I think we confirmed what we pretty much knew all along: Sandy Bridge's improved memory controller has all but eliminated the need for extreme memory bandwidth, at least for this architecture. It's only when you get down to DDR3-1333 that you see a minor performance penalty. The sweet spot appears to be at DDR3-1600, where you will see a minor performance increase over DDR3-1333 with only a slight increase in cost. The performance increase gained by going up to DDR3-1866 or DDR3-2133 isn't nearly as pronounced.

SB nowhere requires another 20GB/s memory bandwidth when ~20GB/s is enough.

---

作者: Henry    時間: 2011-8-17 04:48

引用:

原帖由 qcmadness 於 2011-8-17 03:52 發表
http://www.anandtech.com/show/45 ... ing-the-best-ddr3/8



SB nowhere requires another 20GB/s memory bandwidth when ~20GB/s is enough.

I have already read the review long time ago.
As I said, depends on arch, OPs performance, cores, also the tasks.
If CPU cannot feed the RAM bandwidth, CPU is the bottleneck.
If CPU need to wait for RAM, RAM is the bottleneck.

Now SB-E has 6-8 cores, some may have even 10-12 cores (in DP/MP), can they be satisfied with same amount of bandwidth (2 channel) as those has 4 cores?
I don't think so, though 4 channel may be an overkill in single CPU system.

Can those GF110 or GF104 cores be satisfied with only e.g. 1/5 of their enormous bandwidth (20% RAM freq, same bits) under Tesla platforms, I am really eager to know.
As those platforms claimed much more FLOPs can be juiced out than normal CPUs.

---

作者: qcmadness    時間: 2011-8-17 05:01

引用:

原帖由 Henry 於 2011-8-17 04:48 發表

I have already read the review long time ago.
As I said, depends on arch, OPs performance, cores, also the tasks.
If CPU cannot feed the RAM bandwidth, CPU is the bottleneck.
If CPU need to wait for  ...

1. you still have not shown any tasks which scales well with memory bandwidth
2. SB-E for desktop only 4 and 6 oores. 8 cores is your IMAGINARY product
3. http://www.anandtech.com/bench/P ... 5&i=221.222.223 is this clear enough?

---

作者: Henry    時間: 2011-8-17 05:39

引用:

原帖由 qcmadness 於 2011-8-17 05:01 發表


1. you still have not shown any tasks which scales well with memory bandwidth
2. SB-E for desktop only 4 and 6 oores. 8 cores is your IMAGINARY product
3. http://www.anandtech.com/bench/Product/313? ...

1. I am sorry I cannot show this moment, but does not scale well =/= does not scale. (Something similar should be the first test in your link 3)
2. 8 core is still available in LGA2011 form, and I cannot say nobody will use it in single CPU.
3. I would like to know why the result in 1st has difference if it is not bandwidth dependent, though I am convinced with the results.

---

作者: qcmadness    時間: 2011-8-17 11:58

引用:

原帖由 Henry 於 2011-8-17 05:39 發表

1. I am sorry I cannot show this moment, but does not scale well =/= does not scale. (Something similar should be the first test in your link 3)
2. 8 core is still available in LGA2011 form, and I ca ...

1. of course it scales, but is the scaling meaningful is another question
2. i don't think so, server socket for 4 qpi connections is different
3. decompression / compression is particularly bandwidth sensitive

---

作者: qcmadness    時間: 2011-8-17 15:58

Edit: both server and desktop versions of SB-E have LGA 2011
but compatibility is unknown and only 2 QPI lanes are available...

---

作者: bebird    時間: 2011-8-17 16:06

this post becomes very technical

---

作者: Henry    時間: 2011-8-17 16:14

引用:

原帖由 qcmadness 於 2011-8-17 11:58 發表


1. of course it scales, but is the scaling meaningful is another question
2. i don't think so, server socket for 4 qpi connections is different
3. decompression / compression is particularly bandwid ...

Video compression is also compression (under different algorithm), that's why I say it should be bandwidth sensitive.
MP side should also use LGA2011 if not got wrong, as to take over LGA1567.

[ 本帖最後由 Henry 於 2011-8-17 16:15 編輯 ]

---

歡迎光臨 HKSpot (https://bbs.hk-spot.com/)

Powered by Discuz! 6.0 Lite