[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