Hacker News Reader

Comment by mikepurvis | Hacker News Reader

Right, but the suggestion is that when "one core" is running, you switch around which core it is that's actually hot, so they're taking turns generating the heat.

Obviously there's some cost there in sharing registers, cache, etc, but it's an interesting notion.

View on HN

I see, that is an interesting notion. But how do you "share registers" at 10 GHz, without massive stalls during context switches? The suggestion seems require that the cores are separated by some considerable physical distance, in order to allow for heat dissipation. However this distance also means that data sharing between the cores would be slow and also very power intensive in itself. I'm not a chip designer though, just wildly guessing.

I don't think you'd need to. I expect you'd be able to run the core very fast for a number of milliseconds before having to switch.

If performed at the hardware level, you may also get some improvement by having the core push its register and low level cache state directly to the next processor, rather than have them pull the data through shared cache or RAM. Unlike a typical context switch, the process is not being resumed from idle, but has an active cache state.

The Windows Kernel already does this automatically, at a period of around 10-100ms. If you look at a single threaded program it will actually utilise all cores not one, by default its not locked affinity and the thread skips around.

Interesting, do you have a source for this? I'm curious to know more about the rationale for doing such a thing.

The Linux kernel does the same thing. Run htop and run a single threaded workload. You'll see it migrate around between all the cores.

Reply on news.ycombinator.com