Intel Core i7 3960X (Sandy Bridge E) Review: Keeping the High End Alive
by Anand Lal Shimpi on November 14, 2011 3:01 AM EST- Posted in
- CPUs
- Intel
- Core i7
- Sandy Bridge
- Sandy Bridge E
Gaming Performance
Most games have a tough enough time stressing more than four cores, so the move to the 3960X won't do much for gaming in most cases (particularly when GPU bound). That being said, the added cache may help give SNB-E a slight bump over its quad-core brethren.
Civilization V
Civ V's lateGameView benchmark presents us with two separate scores: average frame rate for the entire test as well as a no-render score that only looks at CPU performance.
In GPU bound scenarios the 3960X is no different than the 2600K. Civ V is a unique game in that its CPU workload does scale reasonable well across multiple cores:
Here the 3960X is nearly 30% faster than the 2600K.
Crysis: Warhead
Dawn of War II
The larger cache helps give the 3960X a 9% advantage over the 2600K in Dawn of War II. At 1680 x 1050 the game isn't entirely GPU bound on our 5870.
DiRT 3
We ran two DiRT 3 benchmarks to get an idea for CPU bound and GPU bound performance. First the CPU bound settings:
DiRT 3 is an example of a CPU bound title (at lower resolutions) that doesn't scale well with core count or cache size. The 3960X is barely 2% faster than the 2600K.
Metro 2033
It is interesting to note that while SNB-E and SNB perform similarly here, both parts do offer a performance improvement over the Gulftown based 990X.
Rage vt_benchmark
While id's long awaited Rage title doesn't exactly have the best benchmarking abilities, there is one unique aspect of the game that we can test: Megatexture. Megatexture works by dynamically taking texture data from disk and constructing texture tiles for the engine to use (note that Rage doesn't store textures in a GPU-usable format). As a result whenever you load a texture, Rage is transcoding the texture on the fly. This is normally done by the CPU.
The Benchmark: vt_ are all the virtual texture commands. Vt_benchmark flushes the texture cache and then times how long it takes to transcode all the textures needed for the current scene, from 1 thread to X threads. Thus when you run vt_benchmark 8, for example, it will benchmark from 1 to 8 threads (the default appears to depend on the CPU you have). Since transcoding is done by the CPU this is a pure CPU benchmark. I present the best case transcode time at the maximum number of concurrent threads each CPU can handle:
Starcraft 2
World of Warcraft
WoW does enjoy the 3960X's larger cache, here we see a 13% increase in performance compared to the regular Sandy Bridge parts.
Facebook
Twitter
RSS
163 Comments
View All Comments
Phylyp - Monday, November 14, 2011 - link
Good review, thanks. I'm researching a new gaming PC, so this review is timely. Right now, seeing the comparative performance of the 2600K vs 3960X makes me want to wait for Ivy Bridge's 2600K replacement to see what sort of VFM that offers, compared to the 3930K.DaFox - Monday, November 14, 2011 - link
> Here we see a 40% increase in performance over the 2600K and FX-1850.On Page 5.
StealthGhost - Monday, November 14, 2011 - link
I'm guessing by these results 2600k / 2500k is going to be a much better buy for gaming vs the 3930kThe 2600k setup (mobo/cpu) I have is, from the prices in the motherboard and CPU review, 485 dollars cheaper than a 3930k+lga2011mobo setup ($400 vs $885). More than double what I paid and while the review for that one isn't out yet, even the 3960x isn't worth double just for gaming (obviously not what it is made for but people will buy it for gaming anyways).
I'd like to see i7 930 vs the 3930k in the review if at all possible since that is the replacement, no? Obviously 2600k as well.
Any idea when that one will be up?
yankeeDDL - Monday, November 14, 2011 - link
Tomshardware had the exact same conclusion.The 3960X is a workhorse and, arguably, the fastest CPU available to desktops today, however, at $999 its value is just not there.
For a shademore than 1/2 its price you get something only marginally slower, and only in certain scenarios. Gamers, for example, have very little benefits from the extra $350 over the 3930.
StealthGhost - Monday, November 14, 2011 - link
Yeah according to their review in BF3 the $999 processor would give me 0 gains since I have one card (GTX 570). If I have 2 which I might later this month it would give me 3.5 fps more, but then I wouldn't be able to afford the 2nd card in the first place haha.Core scaling and cache useage isn't there yet for a lot of games I guess.
B3an - Monday, November 14, 2011 - link
It's pathetic that the new game engine used for BF3 dont even make use of more than 4 cores, or extra cache. And this engine is meant to be for future games... not impressed.Makaveli - Monday, November 14, 2011 - link
so why don't you design a better engine ??Anand Lal Shimpi - Monday, November 14, 2011 - link
As soon as we can get our hands on a 3930K sample :)iwod - Monday, November 14, 2011 - link
QuickSync is really for casual users only. It doesn't offer any advantage over x264 apart from the saved CPU time. x264 is faster then QuickSync with Ultrafast mode, with better quality, and much better quality with other mode then QuickSync can ever get.So QuickSync is good if i want to transfer my media files to my portable, where quality doesn't really matter since i have the original file backed up. It is used for convenience.
Anyone getting a SB-E and doing encoding would properly better off with x264 then QuickSync.
The next version of QuickSync is said to have vastly improved quality and speed.
Manabu - Tuesday, November 15, 2011 - link
Intel's QuickSync quality is somewhere around x264 superfast/veryfast, for the same bitrate. Ultrafast isnt the best tradeoff for speed and quality, as it gives up everything for speed.But I agree, someone with an Sandy Bridge E would be better off using x264 if he learns how to.
A good comparison on speed and quality between GPU and CPU only encoders:
http://www.behardware.com/articles/828-1/h-264-enc...
The only thing they missed is that, if you only care about quality, and not an specific filesize/bitrate, you should be using CRF, and not 2-pass, and much less one pass with --bitrate.