Thanks Paul. Fixed in r25946.
george.
On Feb 16, 2012, at 21:47 , Paul H. Hargrove wrote:
> I just tried to build yesterday's ompi trunk tarball (1.7a1r25937) with the
> Intel compilers.
> Sorry if this was fixed in the past 23 hours or so.
>
>
> My system has GM-2.1.30 installed, and icc
I just tried to build yesterday's ompi trunk tarball (1.7a1r25937) with
the Intel compilers.
Sorry if this was fixed in the past 23 hours or so.
My system has GM-2.1.30 installed, and icc wasn't happy with
btl_gm_component.c:
Creating nightly hwloc snapshot SVN tarball was a success.
Snapshot: hwloc 1.3.3a1r4309
Start time: Thu Feb 16 21:06:54 EST 2012
End time: Thu Feb 16 21:09:47 EST 2012
Your friendly daemon,
Cyrador
Creating nightly hwloc snapshot SVN tarball was a success.
Snapshot: hwloc 1.4.1a1r4310
Start time: Thu Feb 16 21:04:10 EST 2012
End time: Thu Feb 16 21:06:54 EST 2012
Your friendly daemon,
Cyrador
Creating nightly hwloc snapshot SVN tarball was a success.
Snapshot: hwloc 1.5a1r4308
Start time: Thu Feb 16 21:01:01 EST 2012
End time: Thu Feb 16 21:04:10 EST 2012
Your friendly daemon,
Cyrador
Doh!
Many thanks -- I'll apply this in all the right places...
On Feb 16, 2012, at 3:20 PM, Paul H. Hargrove wrote:
>
> After seeing some odd behaviors in a build of the trunk last night, I took a
> closer look at the configure probe for -fvisibility support and found that
> recent changes
After seeing some odd behaviors in a build of the trunk last night, I
took a closer look at the configure probe for -fvisibility support and
found that recent changes where applied incompletely/incorrectly. What
is currently in opal/config/opal_check_visibility.m4:
Le 16/02/2012 17:12, Matthias Jurenz a écrit :
> Thanks for the hint, Brice.
> I'll forward this bug report to our cluster vendor.
>
> Could this be the reason for the bad latencies with Open MPI or does it only
> affect hwloc/lstopo?
It affects binding. So it may affect the performance you
Actually, Libtool evaluates the dependencies of libotf.la where -lz should
appear:
$ cat otflib/libotf.la | grep dependency_libs
# Linker flags that can not go in dependency_libs.
dependency_libs=' -lz'
In base of that Libtool should add -lz to the linker command line, or not?
However, adding
Thanks for the hint, Brice.
I'll forward this bug report to our cluster vendor.
Could this be the reason for the bad latencies with Open MPI or does it only
affect hwloc/lstopo?
Matthias
On Thursday 16 February 2012 15:46:46 Brice Goglin wrote:
> Le 16/02/2012 15:39, Matthias Jurenz a écrit :
On Thursday 16 February 2012 16:50:55 Jeff Squyres wrote:
> On Feb 16, 2012, at 10:30 AM, Matthias Jurenz wrote:
> > $ mpirun -np 2 --bind-to-core --cpus-per-proc 2 hwloc-bind --get
> > 0x0003
> > 0x000c
>
> That seems right. From your prior email, 3 maps to 11 binary, which maps
> to:
just a stupid question: in another sm-related thread the value of the
$TMPDIR variable was the problem, could this be the problem here as well?
Edgar
On 2/16/2012 9:30 AM, Matthias Jurenz wrote:
> On Thursday 16 February 2012 16:21:10 Jeff Squyres wrote:
>> On Feb 16, 2012, at 9:39 AM, Matthias
On Feb 16, 2012, at 10:30 AM, Matthias Jurenz wrote:
> $ mpirun -np 2 --bind-to-core --cpus-per-proc 2 hwloc-bind --get
> 0x0003
> 0x000c
That seems right. From your prior email, 3 maps to 11 binary, which maps to:
Socket L#0 (16GB)
NUMANode L#0 (P#0 8190MB) + L3 L#0 (6144KB)
On Thursday 16 February 2012 16:21:10 Jeff Squyres wrote:
> On Feb 16, 2012, at 9:39 AM, Matthias Jurenz wrote:
> > However, the latencies are constant now but still too high:
> >
> > $ mpirun -np 2 --bind-to-core --cpus-per-proc 2 ./NPmpi_ompi1.5.5 -S -u
> > 12 -n 10
>
> Can you run:
>
>
On Feb 16, 2012, at 9:39 AM, Matthias Jurenz wrote:
> However, the latencies are constant now but still too high:
>
> $ mpirun -np 2 --bind-to-core --cpus-per-proc 2 ./NPmpi_ompi1.5.5 -S -u 12 -n
> 10
Can you run:
mpirun -np 2 --bind-to-core --cpus-per-proc 2 hwloc-bind --get
I want to
Le 16/02/2012 15:39, Matthias Jurenz a écrit :
> Here the output of lstopo from a single compute node. I'm wondering that the
> fact of L1/L2 sharing isn't visible - also not in the graphical output...
That's a kernel bug. We're waiting for AMD to tell the kernel that L1i
and L2 are shared
The inconsistent results disappears when using the option '--cpus-per-proc 2'.
I assume it has to do with the fact that each core shares the L1-instruction
and L2-data cache with its neighboring core (see
Hi Jeff,
Sorry for the delay, but my victim with 2 ib devices had been stolen ;-)
So, I ported the patch on the v1.5 branch and finally could test it.
Actually, there is no opal_hwloc_base_get_topology() in v1.5 so I had to
set
the hwloc flags in ompi_mpi_init() and orte_odls_base_open() (i.e.
/jsquyres appreciates phargroves debugging mojo
On Feb 15, 2012, at 5:17 PM, Paul H. Hargrove wrote:
> The following 1-line change resolves the problem for me, and I see no
> potential down-side to it:
>
> --- openmpi-1.7a1r25927/opal/mca/event/libevent2013/libevent2013_module.c~
>
svn.open-mpi.org (Trac and SVN) appears to be down.
I have contacted IU to see what's up.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
Yowza. With inconsistent results like that, it does sound like something is
going on in the hardware. Unfortunately, I don't know much/anything about AMDs
(Cisco is an Intel shop). :-\
Do you have (AMD's equivalent of) hyperthreading enabled, perchance?
In the latest 1.5.5 nightly tarball,
Jeff,
sorry for the confusion - the all2all is a classic pingpong which uses
MPI_Send/Recv with 0 byte messages.
One thing I just noticed when using NetPIPE/MPI. Platform MPI results in
almost constant latencies for small messages (~0.89us), where I don't know
about process-binding in
I could reproduce the build error with Clang 2.9. Adding the operator< to
DefRec_BaseS fixes the problem, although this operator is not used.
Thanks for the hints!
I'll commit this fix and create a CMR to v1.5 soon.
Matthias
On Thursday 16 February 2012 04:22:33 Paul H. Hargrove wrote:
>
As I already discover (see
http://www.open-mpi.org/community/lists/devel/2012/02/10444.php), MacOS
10.4 is NOT listed as a supported platform any longer. So, this message
is really just for the archives.
From "man ld" on a MacOS 10.4 system (x86 or ppc):
MACOSX_DEPLOYMENT_TARGET
24 matches
Mail list logo
