Reg Hardware

Comments on: Idle wild: how Intel's mobile Core i7 speeds up to slow down

mobile don't care 

Posted Tuesday 13th October 2009 13:43 GMT

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).

@soft electrons 

Posted Tuesday 13th October 2009 14:53 GMT

"mobile don't care "

They will. These were lessons learned on PXA. In many cases higher clock speed = faster to sleep = lower energy.

Proscribed? 

Posted Tuesday 13th October 2009 20:36 GMT

Stop

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?

forgive... 

Posted Tuesday 13th October 2009 21:31 GMT

...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 

Posted Tuesday 13th October 2009 21:43 GMT

Thumb Down

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 

Posted Wednesday 14th October 2009 02:21 GMT

Where do you get that overclock widget?

@BobTB 

Posted Wednesday 14th October 2009 03:23 GMT

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?

@soft electrons 

Posted Wednesday 14th October 2009 09:32 GMT

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.

Hmm 

Posted Wednesday 14th October 2009 09:34 GMT

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!

RE: Physical cores vs. Virtual (hyperthread) cores # 

Posted Wednesday 14th October 2009 13:21 GMT

Gates Halo

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... 

Posted Thursday 15th October 2009 06:43 GMT

Go

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.

Awesome,

M