Re: [OMPI users] The effect of --bind-to in the presence of PE=N in --map-by

Hi Ralph, I didn't notice your reply. So our mails might pass each other. As you pointed out, I might be wrong. Give me a time to remember every thing about the bind-to directve. Regards, Tetsuya 2016/05/20 8:36:53、"users"さんは「Re: [OMPI users] The effect of --bind-to in the presence of PE=N in

Re: [OMPI users] The effect of --bind-to in the presence of PE=N in --map-by

Yes, slot is nearly equal to core. Ralph would know the difference very well, please ask him about the detail. Tetsuya 2016/05/20 8:29:41、"users"さんは「Re: [OMPI users] The effect of --bind-to in the presence of PE=N in --map-by」で書きました > Thank you, Tetsuya. So is a slot = core? > > On Thu, May

Re: [OMPI users] The effect of --bind-to in the presence of PE=N in --map-by

No!! A “slot” is purely a bookkeeping construct that schedulers use to tell you how many procs you can run. It has nothing to do with a core or any other physical resource. It is true that we generally configure our schedulers to set the max #slots on each node to equal the #cores on the node -

Re: [OMPI users] The effect of --bind-to in the presence of PE=N in --map-by

Not really. When you add PE=N, then you are asking us to assign each proc to N cpus. Thus, we have no other option but to bind you to cpu - otherwise we cannot honor that request. So in the absence of the —use-hwthread-cpus, we are going to bind you to 4 cores. There is no “bind-to slot” as a s

Re: [OMPI users] The effect of --bind-to in the presence of PE=N in --map-by

Thank you, Tetsuya. So is a slot = core? On Thu, May 19, 2016 at 7:26 PM, wrote: > Hi Saliya and Ralph, > > I guess Ralph is confusing "bind-to core" with "bind-to slot". > > As far as I remember, when you add "PE=N" option to the map-by directive, > you can only use "bind to slot". > > So if yo

Re: [OMPI users] The effect of --bind-to in the presence of PE=N in --map-by

Hi Saliya and Ralph, I guess Ralph is confusing "bind-to core" with "bind-to slot". As far as I remember, when you add "PE=N" option to the map-by directive, you can only use "bind to slot". So if you want to bind a process to specific slots(almost same as cores), you should use "bind-to slot".

Re: [OMPI users] The effect of --bind-to in the presence of PE=N in --map-by

Thank you, Ralph. That's what I was looking for. Saliya On Thu, May 19, 2016 at 4:08 PM, Ralph Castain wrote: > No, it means that each proc will be bound to 4 cores > > What you have specified is that you want us to run 3 procs on each socket, > each proc bound to 4 cores. That is what we will

Re: [OMPI users] The effect of --bind-to in the presence of PE=N in --map-by

No, it means that each proc will be bound to 4 cores What you have specified is that you want us to run 3 procs on each socket, each proc bound to 4 cores. That is what we will do - as I said, the —bind-to socket directive will be ignored. > On May 19, 2016, at 1:03 PM, Saliya Ekanayake wrote:

Re: [OMPI users] The effect of --bind-to in the presence of PE=N in --map-by

So if bind-to-core is in effect, does that mean it'll run only on 1 core even though I'd like it to be able to utilize 4 cores. For examples, I'll be creating 4 threads within the process and would like to pin them to each core the process has been bound to. On Thu, May 19, 2016 at 3:46 PM, Ralph

Re: [OMPI users] The effect of --bind-to in the presence of PE=N in --map-by

Perhaps we should error out, but at the moment, PE=4 forces bind-to-core and so the bind-to socket is being ignored > On May 19, 2016, at 12:06 PM, Saliya Ekanayake wrote: > > Hi, > > I understand --map-by will determine the process placement whereas --bind-to > will keep the processes pinned

[OMPI users] The effect of --bind-to in the presence of PE=N in --map-by

Hi, I understand --map-by will determine the process placement whereas --bind-to will keep the processes pinned to the given resource. If this understanding is correct, then I've got a doubt with the following. On a node with 2 sockets and 12 cores each, --map-by ppr:3:socket,PE=4 --bind-to soc

Re: [OMPI users] MPI_Finalize() small issue with mutex destruction

Here’s the 1.10 version of the PR: https://github.com/open-mpi/ompi-release/pull/1172 > On May 19, 2016, at 9:18 AM, Nicolas Joly wrote: > > On Thu, May 19, 2016 at 09:13:15AM -0700, Ralph Castain wrote: >> No issue at all - I?ll check the

Re: [OMPI users] MPI_Finalize() small issue with mutex destruction

On Thu, May 19, 2016 at 09:13:15AM -0700, Ralph Castain wrote: > No issue at all - I?ll check the latest versions and ensure the > problem is present in them. Out of curiosity - what version of OMPI > are you describing? njoly@lanfeust [tmp/mpi]> mpirun --version mpirun (Open MPI) 1.10.1 I discov

Re: [OMPI users] MPI_Finalize() small issue with mutex destruction

No issue at all - I’ll check the latest versions and ensure the problem is present in them. Out of curiosity - what version of OMPI are you describing? > On May 19, 2016, at 9:06 AM, Nicolas Joly wrote: > > > Hi, > > I just discovered a small issue with MPI_Finalize(). When sanity > checking

[OMPI users] MPI_Finalize() small issue with mutex destruction

Hi, I just discovered a small issue with MPI_Finalize(). When sanity checking a threaded tool on my NetBSD/amd64 workstation i turned on a PTHREAD_DIAGASSERT environnement variable to report any issue that may be triggered ... And a simple MPI test program seemed to be affected : njoly@issan [t

Re: [OMPI users] Building vs packaging

I don't know about .deb packages, but at least in the rpms there is a post install scriptlet that re-runs ldconfig to ensure the new libs are in the ldconfig cache. On 16/05//2016 18:04, Dave Love wrote: "Rob Malpass" writes: Almost in desperation, I cheated: Why is that cheating? Unless