Intel's first mobile Core i7 processors - codenamed 'Clarksfield' - incorporate a feature the chip company is calling Turbo Boost. It's not new - the technology is a part of every 'Nehalem' architecture-based CPU the company has released to date. So, Turbo Boost can be found in desktop chips and it's in Xeon server parts too. …
mobile don't care
For mobile users, the speed gain with power hike is not noticeable, but the battery life will be more noticeable. I don't think this is the right target but then maybe there is no other opportunity. Servers and enterprise should be all multithread by now (so running every core).
"mobile don't care "
They will. These were lessons learned on PXA. In many cases higher clock speed = faster to sleep = lower energy.
This is because the Core i7 as a whole stays within its proscribed thermal limits.
Surely you meant within its prescribed limits - if it was within its proscribed thermal limits it would be outside its prescibed thermal limits - no?
...my possible dumbness...
I see that this overclocks(?) one core if the others aren't being used... so long as its not too hot.
Couldn't this be done on all of them... _as long as its not too hot_.
So like, automatic CPU overclocking? Or am I missing something different...
Physical cores vs. Virtual (hyperthread) cores
While I'm not sure Vista cannot make the difference between physical CPUs vs. hyperthreaded ones, I hope that is not so.. Linux has been able to do so for the past.. what, 4-5 years now ? I'd hate to imagine what would happen if, say, the only two CPU consuming threads are run on the same physical core, but different hyperthreaded ones, just because the OS couldn't tell the difference.
OK, I'll bite
Where do you get that overclock widget?
It would depend on power*time (or its integration) difference. Maybe you halve the time (double the clock), but the power is going to be more than that by the voltage increase squared, right?
Sounds more like they underclock under normal circumstances and return to normal speed when needed.
The turbo boost sounds more like a marketing gimmick to me - 'slows down to cool down' won't sell as many chips!
It very much depends on use case & how well the power is managed. If you double the clock & run for half the time then yes energy used is same or greater (depending on voltage) but, with good power managment, if you run fast there is more opportunity to sleep longer & deeper.
RE: Physical cores vs. Virtual (hyperthread) cores #
If Windows sucks because it is just now releasing an OS that differentiates between physical and virtual cores, where does that leave Mac? The article handed you a pro-Linux talking point on a silver platter. Did you miss the preceding paragraph about Apple’s grand central dispatch? If your thinking was less Microsoft-centric your OS of choice might be taken more seriously.
Its all in the leakage...
Modern <=90nm silicon processes no longer lose most of their energy in switching gates (more is the pity) but in simple leakage across the transistors. This exponentially increases as things are made smaller and exponentially increases with temperature. The energy loss happens even if the gates are "idle"!
Fast logic transistors == horrible leakage
So to solve this problem engineers add header and footer power switch transistors (bad logic transistors, so slow) to turn "hard off" whole sections of circuit. This Intel strategy means Intel can have its cake and eat it too.
Running some cores faster and turning "hard off" others saves all that lovely "idle" leakage. The thermal mass of the packaging and die will prevent excessive temperature rises in that one core saving exponential thermal effects.
- Hi-torque tank engines: EXTREME car hacking with The Register
- Review What's MISSING on Amazon Fire Phone... and why it WON'T set the world alight
- Product round-up Trousers down for six of the best affordable Androids
- Antique Code Show World of Warcraft then and now: From Orcs and Humans to Warlords of Draenor
- Why did it take antivirus giants YEARS to drill into super-scary Regin? Symantec responds...