Re: [OMPI users] scheduling to real cores, not using hyperthreading (openmpi-2.1.0)

I’m not entirely sure I understand your reference to “real cores”. When we bind you to a core, we bind you to all the HT’s that comprise that core. So, yes, with HT enabled, the binding report will list things by HT, but you’ll always be bound to the full core if you tell us bind-to core The de

Re: [OMPI users] No more default core binding since 2.0.2?

> Am 10.04.2017 um 17:27 schrieb r...@open-mpi.org: > > >> On Apr 10, 2017, at 1:37 AM, Reuti wrote: >> >>> >>> Am 10.04.2017 um 01:58 schrieb r...@open-mpi.org: >>> >>> Let me try to clarify. If you launch a job that has only 1 or 2 processes >>> in it (total), then we bind to core by defa

Re: [OMPI users] No more default core binding since 2.0.2?

> On Apr 10, 2017, at 1:37 AM, Reuti wrote: > >> >> Am 10.04.2017 um 01:58 schrieb r...@open-mpi.org : >> >> Let me try to clarify. If you launch a job that has only 1 or 2 processes in >> it (total), then we bind to core by default. This is done because a job that

Re: [OMPI users] No more default core binding since 2.0.2?

> Am 10.04.2017 um 00:45 schrieb Reuti : > […]BTW: I always had to use -ldl when using `mpicc`. Now, that I compiled in > libnuma, this necessity is gone. Looks like I compiled too many versions in the last couple of days. The -ldl is necessary in case --disable-shared --enable-static was given

[OMPI users] scheduling to real cores, not using hyperthreading (openmpi-2.1.0)

Dear OpenMPI users & developers, I'm trying to distribute my jobs (with SGE) to a machine with a certain number of nodes, each node having 2 sockets, each socket having 10 cores & 10 hyperthreads. I like to use only the real cores, no hyperthreading. lscpu -a -e CPU NODE SOCKET CORE L1d:L1i:L2

Re: [OMPI users] No more default core binding since 2.0.2?

> Am 10.04.2017 um 01:58 schrieb r...@open-mpi.org: > > Let me try to clarify. If you launch a job that has only 1 or 2 processes in > it (total), then we bind to core by default. This is done because a job that > small is almost always some kind of benchmark. Yes, I see. But only if libnuma w