[slurm-users] Using hyperthreaded processors

Valerio Bellizzomi valerio at selnet.org
Fri Nov 6 12:43:06 UTC 2020


On Fri, 2020-11-06 at 13:00 +0100, Diego Zuccato wrote:
> Il 04/11/20 19:12, Brian Andrus ha scritto:
> 
> > One thing you will start finding in HPC is that, by it's goal,
> > hyperthreading is usually a poor fit.
> Depends on many factors, but our tests confirm it can do much good!
> 
> > If you are properly utilizing your cores, your jobs will actually be
> > slowed by using hyperthreading.  They are not 'extra' cores, but a
> > method of swapping a core to a different workload during an idle cycle.
> > The operative word being 'idle'. The goal of HPC is get resource usage
> > as close to 100% as possible, so there should be no 'idle' cycles.
> IIUC that's wrong.
> Multithread cores have two independent execution units, but a single MMU
> (and, from memory, a single FPU, but the tests gave different results).
> So you can have at most one process per core, but if you have
> multithreaded (threads share address space, processes don't) code it
> will run at about twice the speed it achieves when running on a single
> thread.
> 
> Tested with FPU-intensive code on our cluster.
> 
> What thrashes performance is trying to run different processes in the
> two threads of a core.
> 
> Just my $.02
> 


Usually hyperthreading will halve the memory-bandwidth available to one
thread running in one core, the other half being used by the second
thread.






More information about the slurm-users mailing list