The new forums will be named Coin Return (based on the most recent vote)! You can check on the status and timeline of the transition to the new forums here.
The Guiding Principles and New Rules document is now in effect.
Dual Core vs Single Core
Wezoin
Registered User regular
Registered User regular
My brother has an AMD Athlon 64 X2 clocked at 1.6ghz, a game he wants (World in Conflict) demands a 2ghz cpu. Does this mean it requires a 2ghz dual core? Will it run on a 1.6 dual core?
Wezoin on
0
Posts
I don't think I have ever seen it
1.6 -> ~ 2.4GHz
Er, well, sorta.
Assuming that the code is appropriately parallelized to take advantage of having multiple independent processors or cores, then the aggregate performance provided by two cores will generally make up for either core underperforming (unless one of the cores in question is running enough serialized code that needs 2Ghz of power).
Many games make limited (if any) use of parallelism.
If a game is completely single-threaded, then you could have 8 1.6ghz cores in your box, and the game would still only have 1.6Ghz to work with.
The primary benefit of a dual-core CPU is that even if the game only threads to one core, everything else (such as Windows, your media player, instant message clients, web browser, etc.) will be offloaded to the unused core automatically. This means that you've got a dedicated core for your game; background stuff can use up 10-50% of your CPU if it's single core, depending on what programs you use and the speed of the CPU.
Really CPU-intensive stuff that won't multithread can actually perform worse on a dual-core CPU; I experienced this with EQ2 when I first built my computer with a Core 2 Duo E6600: the 2.4GHz clock speed was slower, even with background stuff on the other core, than my P4 clocked up to 3.6GHz. Luckily the C2Ds overclock easily with stock cooling so a little tweaking got a huge performance increase.
Stuff like video encoding or 3d modelling (and AI routines in games) can't take much advantage of multiple cores without specialized code that you aren't going to get in commercial versions. At least, that's what I've been told.
If the game runs like crap on the stock CPU you can consider overclocking to get better performance without having to spend more on a faster CPU. The great thing about overclocking a dual core CPU is that the faster speed is "worth" twice as much, because each core runs faster independently, giving you more "CPU overhead" for background applications in addition to improving performance of the game itself. I used to use Task Manager to shut down all non-critical threads on my P4 to squeeze out a little extra performance, now I just don't care, because CPU1 gets maxed out by my games while CPU0 handles everything else with room to spare.
In short, if the game wants a single-core CPU @ 2GHz a dual core @ 1.6GHz should be fine, because you'll have one dedicated core for the game without other stuff taking up CPU time. And overclocking to 2GHz on an AMD X2 shouldn't be hard so long as you are careful about it and do it in small increments. Just watch your temps and don't suddenly jump your voltage up by like .25v in one go (.05 is about the largest increment I recommend) and you have essentially zero risk of breaking anything.
I may be wrong but I was under the impression that each core is just as [in]efficient as previous P4s, they just have 2, so it gets twice as much done per clock cycle.
Now that I think about this I'm really not sure that's true though.
Not at all. Single Core Two's perform better than P4's.
Pentium 4s were notoriously inefficient per clock cycle. The reasons are somewhat technical, but basically the way Intel got them to the 4 ghz mark was by giving them a really long pipeline which breaks instructions into smaller, faster parts. That allows the processor to work on different parts of successive instructions concurrently, significantly improving the overall clock speed of the processor. A decent analogy is to compare doing all the washing, drying, and folding of one load of laundry before starting the next load to the more efficient method of washing one load while drying another one and folding the third in the meantime.
The problem with this is when you have branching statements where the code can go two different places depending on some condition. Usually that condition will depend on the value of registers that have been recently calculated or updated, which forces you to make one of two choices. Either you can wait for the pipeline to clear (and the longer the pipeline the longer that will take), which makes the processor sit doing nothing for a while, or you can use what's usually called branch prediction. Branch prediction uses some heuristic to guess what the result of the conditional will be and goes ahead as if it's true. If it got it right then great, but if it guesses wrong it has to go back, reset the registers to what they were when the conditional occurred, then start over on the other branch. That's even more expensive than just waiting for the conditional to come out the pipeline, so the effectiveness of branch prediction is directly proportional to how well your prediction heuristic functions.
The gist of it is that while the P4 performed great in certain types of programs (namely those that featured little to no branching), for more general purpose computing it lost a significant amount of performance to flushing its pipeline. Additionally, actual performance is determined by instructions per second multiplied by clock speed. The P4 could do 3 instructions per second while the core 2 can do 4, so despite being overblown Apple's "megahertz myth" did have some truth to it, if not exactly the truth Apple wanted everyone to believe. Since the core 2 can do more work per clock cycle it can actually outperform the P4 with half the clock speed, especially when you take into account the larger cache and other improved features the core 2 gets.