[ILUG] 2.6 Kernel + Hyperthreading

[Paul Jakma]

On Thu, 9 Sep 2004, Ronan Cunniffe wrote:

> Yes, but not much! :-)

Hmm, well that depends too on your POV. Yours is very much from the 
sci-comp perspective ;)

> For anything that even remotely resembles the above snippet, the 
> CPU is going to be dead-accurate in branch prediction, meaning 
> effectively no branches, probably no bubbles at all if either 
> function() or inputs[i] are anyway complicated, and a single thread 
> can saturate the FPU resources of the chip.

Right.

> Eh, what's a server workload?

Multiple varied tasks, possibly a fair amount of IO.

Indeed, desktop is a bit like that too.

> Does yours look like this (note the runtime...) ?
>
>  PID USER    PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 32541 user    27   2  1760  532 1492 R 51.7  0.1   9754:24 zazp1.x
> 32545 user    27   2  1760  532 1492 R 49.7  0.1   9754:40 zazp2.x

No it doesnt. Nor do most people's ;)

> HT would only be a good idea if there was constant and massive 
> shuffling of data in from disk, and this could be handled 
> predictively by a helper thread.  This assumes that you're writing 
> your own code, which is rarely true.  Most science apps are 
> explicitly written to a 1-thread-per-node model, with any 
> parallelism achieved by using MPI.

Right, but most people's workloads are *not* like that. Hence exactly 
why Intel added HT. ;) For most server/desktop uses, HT likely *is* a 
win.

Course, you need to benchmark your own uses to find out.

> Ronan

regards,
-- 
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
Reporter, n.:
 	A writer who guesses his way to the truth and dispels it with a
 	tempest of words.
 		-- Ambrose Bierce, "The Devil's Dictionary"