according to gaming benchs, it performed pretty much the same...
i blame this on the o/s and gaming not supporting multicore or cpus with 2+ cores...
There were gains, albeit not HUGE ones like Quake 4 SMP 1.x showed on dualcore rigs... I go into it & why below in my P.S. (balancing off other process' threads would create the gains in theory/imo).
Plus, the Operating Systems of modern VM nature like Linux &/or Windows NT/2000/XP/Server 2003 are & do support multiple thread usage, & thus, SMP/DualCore CPU arrangements... their process schedulers handle this already properly & have for years (better w/ each OS iteration build version in fact).
As far as games?
See these tests in these threads below!
(Some games are here already that vastly leverage it for FAR better performance, such as Quake 4 SMP 1.2-1.3, noted in that thread url below, noting up to 87% performance increases (45-50% on average iirc), w/ tests from 2 diff. fairly respected sites & decent analysis + charts for your reference):
=================================================
Quake 4 Dual-Core Performance: AMD & Intel:
------------------------------------------------
"Biased or not, beta or no, there’s a lot to like about the latest patch for Quake 4, whether you have an Athlon 64 X2 or a dual-core/Hyper-Threaded Intel chip. The two architectures each pick up phenomenal performance gains."
http://www.firingsquad.com/hardware/...ance/page3.asp
----------------------------------------------------------------
Quake 4 SMP Patch Benchmarks Revised:
------------------------------------------------
"their SMP patch does wonders with 50% improvements and is a must download for every dual core owner out there, AMD or Intel. If this isn't enough we also have word from Tim that in the 1.1 update to Quake 4 we will see even more SMP improvements and fixes, so we will definitely be testing that out.
Also where id leads, others follow. Obviously for id to patch the game and enable this SMP support and show what a huge advantage it can have goes against some of the naysayers earlier."
http://www.amdzone.com/modules.php?o...tid=225&page=2
=================================================
* More games DO need to take advantage of these OS' process scheduler IN THEIR OWN CODE, by implementing properly designed/no race condition bearing multithreaded code (no need really for SetProcessAffinity (or rather, SetThreadAffinity, because SetProcessAffinity will HOSE performance gain on Multithreaded apps, where as SetThreadAffinityMask works for multithreaded apps, SPECIFICALLY optimized for SMP) EXPLICIT multithreaded code/smp specific code really either)...
APK
P.S.=> On these QuadCore CPU's, you'd need (technically/theoretically) 4 distinct threads to REALLY take advantage of the fact today's OS' process scheduler kernel mgt. engines CAN handle sending threads (smallest atomic unit of execution usually (There are "fibers")) to diff. CPU's to run on synchronously!
ALL to get "more" out of games & such...
This may be WHY these CPU's are not showing "GIGANTIC" gains over running them on DualCore/2xCPU SMP rigs, BUT... they did show some gains nevertheless!
Whereas DualCore CPU built systems did rather hugely (as the examples above in the URL's note/exemplify on Quake 4 SMP 1.x)...
I wager they do NOT have 4 separate threads running possibly: In fact, I ought to look @ Quake 4 SMP 1.3 here & test that using taskmgr.exe & see how many threads it does run in fact, & I would strongly wager it is NOT 4... 2-3 maybe!
EDIT PART: The folks @ Tom's Hardware "2nd my conclusion" in this regard, w/ a statement from their closing conclusions:
------------------------------------------------
"Gaming fans, however, can confidently stick with the Core 2 Duo/Extreme or the legendary Pentium D 805. That's due to a lack of adaptations for four CPUs - in practice, only a maximum of two processors are used in games."
------------------------------------------------
Still, there should be SOME gain (& there was, but it was from the process scheduler moving other programs' threads to other CPU's to "unburden" the one your game runs on)!
E.G. -> If your game is running on a saturated CPU, other process/programs SHOULD be able to be "moved around" to run threads of their's (child &/or parent threads) to the least used/least saturated present CPU cores... via the OS process scheduler doing so, & NOT 'burdening' (additionally that is) CPU cores running your game! apk
