Are CPUs more stable with one or more cores disabled?
2014-06
zyboxenterprises
I was reading this article, and I couldn't help noticing this:
...7003.38 MHz, with two CPU cores enabled and hyper-threading disabled.
Does disabling some CPU cores & disabling Hyper-Threading (or thermal throttle for AMD CPUs) really increase system stability, especially when overclocking?
Frank Thomas
The OC described in your article involved increasing the core voltage by a huge degree. Additional features needed to be disabled to reduce heat generation while operating at that voltage and frequency.
"Stability" can mean a lot of things as relates to overclocking, but in this case, thermal stability is likely the highest priority.
MattSteelblade
The first thing that comes to mind, specifically with CPU cores, is that it would be easier to deal with the extreme heat that the cores would be producing. In addition, disabling hyper-threading should also, theoretically, help bring down the temperature which at those speeds and that voltage is probably his number one concern.
lserni
You need to consider two sources of instability, which are "point" temperature and overall heat. If the CPU was a thermal superconductor they would be the same.
So you have a temperature limit that, if reached, will shutdown or damage a core's... core. And a possibly significantly lower temperature limit that the CPU in its entirety should not exceed, because there is some other component that will crash.
Normally heat is removed from the whole surface covered by the heatsink, and it is generated mostly in the core(s) and in lesser measure in the ancillary hardware depending on the power consumption rate per unit of volume (or of surface, since the CPU architecture is basically flat).
Raising the CPU voltage and frequency has the effect of increasing heat generation in the core. If this increase, minus the removed heat at steady-state, drives the temperature too high for the core, then it does not matter how many cores you disable - those still enabled will crash. Or fail due to electromigration after some time.
If the temperature is core-safe, though, you'll observe that the temperature outside the core will be driven upwards as heat seeps from the "redder" zone to the "yellow" zones.
And it can happen that when the temperature of a "yellow" zone (which is normally, say, 50 °C) is driven to 65 °C by the cores running at 95 °C instead of 80 °C, then the hardware in the yellow zone malfunctions and the CPU in its entirety becomes "unstable".
And since this heat is the sum total of the heat from all the cores, hyperthreading sections, and so on, disabling those features may keep the CPU all in the stable zone.
For that matter, even the kind of code which is being executed may influence the power generation; so that you may have failures when running the same code compiled with or without, e.g., SSE3 support. Actually, even the choice of instruction sequence may be relevant, and there are studies in that regard.
KoKo
Yes, but that would be pointless unless for some reason you only care about single core performance, then yes disabling other cores will allow you to overclock a bit more.
Questioner
I currently have a dual-core processor at work and a quad-core at home. I've noticed both PCs are pretty equal as far as launching applications/surfing the web.
The difference I can see is that my dual-core is 2.8GHz and my quad-core is 2.4GHz.
Is it better to have a dual-core with a fast clock speed or a quad-core with a mediocre clock speed?
Your primary problem is software not written for multi-core.
Look at Jeff Atwood's excellent article on Choosing Dual core or Quad Core.
for most software, you hit a point of diminishing returns very rapidly after two cores. In Quad-Core Desktops and Diminishing Returns, I questioned how effectively today's software can really use even four CPU cores, much less the inevitable eight and sixteen CPU cores we'll see a few years from now.
You are answered here (highlight copied from Jeff's article),
However, there were some surprises in here, such as Excel 2007, and the Lost Planet "concurrent operations" setting. It's possible software engineering will eventually advance to the point that clock speed matters less than parallelism. Or eventually it might be irrelevant, if we don't get to make the choice between faster clock speeds and more CPU cores. But in the meantime, clock speed wins most of the time. More CPU cores isn't automatically better. Typical users will be better off with the fastest possible dual-core CPU they can afford.
The issue of the Front-Side Bus (that term always amused me).
With Nehalem things change... as ArsTechnica said last year.
Moore's Law has given processor designers an embarrassment of transistor riches, and nowhere is that more apparent than in Intel's 45nm Nehalem processor. Debuting in 4- and 8-core variants later this year, Nehalem packs a ton of hardware into a single processor socket. (Early numbers put the transistor count of a quad-core Nehalem at 781 million; no numbers for the 8-core model have appeared yet.) But trying to feed all of that hardware with the Intel platform's existing frontside bus architecture would be folly. So, just as importantly, Nehalem also sounds the long-overdue death knell for Intel's positively geriatric frontside bus architecture.
The radical change in Intel's system bandwidth situation that Intel's new QuickPath Interconnect (QPI) represents is perhaps the largest single factor that shaped Nehalem's design. Between QuickPath and Nehalem's integrated memory controller, a Nehalem processor will have access to an unprecedented amount of aggregate bandwidth, especially in two- and four-socket implementations.
AMD moved the memory controller into the processor earlier and used Hypertransport.