Re: [OMPI devel] RFC: Java MPI bindings

I agree - we do have better things to do than argue about things that have no impact on anyone not choosing to use them. If you had read the RFC, you would have seen that the Hadoop businesses are unwilling to trust their future to a 3rd party bolt-on that already shows bit-rot. Hence, the

Re: [OMPI devel] thread safety of the self btl

Indeed. The lists you pinpoint at are used via the OMPI_FREE_LIST_GET macro, which is based on atomic operations. We're all safe on that front. Even if multiple threads call the self BTL functions simultaneously we are safe due to the MPI semantics (the matching logic is protected, it can

Re: [OMPI devel] thread safety of the self btl

On Wed, 8 Feb 2012 20:58:52 -0500 George Bosilca wrote: > The self BTL is different from any other BTL. Any memcpy operation > done by this BTL is automatically protected behind the matching > logic, and therefore does not require extra thread safety protection. > A mutex

Re: [OMPI devel] RFC: Java MPI bindings

3 anonymous accesses and 12 developer accesses from 2010-11-25 till today, that's what the mpiJava project hosted on sourceforge got. It tends to say something about the need for such a binding now, the size of the community requiring such a binding and about the support Open MPI should throw

[hwloc-devel] Create success (hwloc r1.0.4a1r4280)

Creating nightly hwloc snapshot SVN tarball was a success. Snapshot: hwloc 1.0.4a1r4280 Start time: Wed Feb 8 21:12:38 EST 2012 End time: Wed Feb 8 21:15:00 EST 2012 Your friendly daemon, Cyrador

[hwloc-devel] Create success (hwloc r1.2.3a1r4283)

Creating nightly hwloc snapshot SVN tarball was a success. Snapshot: hwloc 1.2.3a1r4283 Start time: Wed Feb 8 21:07:01 EST 2012 End time: Wed Feb 8 21:09:44 EST 2012 Your friendly daemon, Cyrador

Re: [OMPI devel] thread safety of the self btl

On Feb 8, 2012, at 8:58 PM, George Bosilca wrote: > The self BTL is different from any other BTL. Any memcpy operation done by > this BTL is automatically protected behind the matching logic, and therefore > does not require extra thread safety protection. A mutex in the self BTL is > mostly a

Re: [OMPI devel] thread safety of the self btl

The self BTL is different from any other BTL. Any memcpy operation done by this BTL is automatically protected behind the matching logic, and therefore does not require extra thread safety protection. A mutex in the self BTL is mostly a copy/paste mistake. george. On Feb 8, 2012, at 17:57 ,

Re: [hwloc-devel] 1.3.2rc1 has escaped

On 2/8/2012 4:41 PM, Paul H. Hargrove wrote: I do agree w/ Samuel that the BEST solution is to apply "-qhalt=e" ONLY to the test(s) where one expects the compiler to through errors (rather than warnings) for function calls with argument counts which don't match the prototypes. At the

Re: [hwloc-devel] 1.3.2rc1 has escaped

On 2/8/2012 4:43 PM, Samuel Thibault wrote: Paul H. Hargrove, le Thu 09 Feb 2012 01:41:47 +0100, a écrit : On 2/8/2012 4:31 PM, Samuel Thibault wrote: Paul H. Hargrove, le Thu 09 Feb 2012 01:28:53 +0100, a écrit : Option #4: CFLAGS='-qhalt=e -qsuppress=1506-077' Appears to work for me

Re: [hwloc-devel] 1.3.2rc1 has escaped

Samuel Thibault, le Thu 09 Feb 2012 01:43:56 +0100, a écrit : > Paul H. Hargrove, le Thu 09 Feb 2012 01:41:47 +0100, a écrit : > > On 2/8/2012 4:31 PM, Samuel Thibault wrote: > > >Paul H. Hargrove, le Thu 09 Feb 2012 01:28:53 +0100, a écrit : > > >>Option #4: > > >>CFLAGS='-qhalt=e

Re: [hwloc-devel] 1.3.2rc1 has escaped

Paul H. Hargrove, le Thu 09 Feb 2012 01:41:47 +0100, a écrit : > On 2/8/2012 4:31 PM, Samuel Thibault wrote: > >Paul H. Hargrove, le Thu 09 Feb 2012 01:28:53 +0100, a écrit : > >>Option #4: > >>CFLAGS='-qhalt=e -qsuppress=1506-077' > >>Appears to work for me for xlc-8.0 and xlc-9.0. > >That

Re: [hwloc-devel] 1.3.2rc1 has escaped

On 2/8/2012 4:31 PM, Samuel Thibault wrote: Paul H. Hargrove, le Thu 09 Feb 2012 01:28:53 +0100, a écrit : Option #4: CFLAGS='-qhalt=e -qsuppress=1506-077' Appears to work for me for xlc-8.0 and xlc-9.0. That still looks dangerous to me: we don't know whatever warning might be added in

Re: [OMPI devel] thread safety of the self btl

On Feb 8, 2012, at 5:57 PM, Christopher Yeoh wrote: > I've noticed that the self btl does not do any locking. It has one > lock defined but its not actually used anywhere. > > So I'm just wondering if that is an oversight or if there is a reason > that we know for sure that there will never be

Re: [hwloc-devel] 1.3.2rc1 has escaped

On 2/8/2012 8:58 AM, Jeff Squyres wrote: Please test! http://www.open-mpi.org/software/hwloc/v1.3/ I have access to BG/L, BG/P, Cray-XT and Cray-XE systems. Are there any tests I could/should consider running on those? -Paul -- Paul H. Hargrove

Re: [hwloc-devel] 1.3.2rc1 has escaped

On 2/8/2012 1:44 PM, Brice Goglin wrote: Ah, we need to use $hwloc_c_vendor instead. That's where's $hwloc_check_compiler_vendor_result ends up before being cleared. It looks like something is very wrong here: Examining the 1.3.2rc1 tarball I seem to see $hwloc_c_vendor is read but NOT

[OMPI devel] thread safety of the self btl

Hi, I've noticed that the self btl does not do any locking. It has one lock defined but its not actually used anywhere. So I'm just wondering if that is an oversight or if there is a reason that we know for sure that there will never be concurrent access to that particular btl with threads

Re: [hwloc-devel] 1.3.2rc1 has escaped

On 2/8/2012 1:10 PM, Paul H. Hargrove wrote: On 2/8/2012 8:58 AM, Jeff Squyres wrote: * Detect when a compiler such as xlc may not report compile errors properly, causing some configure checks to be wrong. Thanks to Paul H. Hargrove for reporting the problem and providing a patch.

Re: [hwloc-devel] 1.3.2rc1 has escaped

On 2/8/2012 1:37 PM, Brice Goglin wrote: Let's ignore this for 1.3.2. libnuma sucks, we're wasting way too much time trying to make it sane. I'll look later if I find an easy way to reproduce. OK, fine by me. I've verified that if I "disarm" that test, then the remaining tests PASS. -Paul

Re: [hwloc-devel] 1.3.2rc1 has escaped

On 2/8/2012 8:58 AM, Jeff Squyres wrote: * Fix conversion from/to Linux libnuma when some NUMA nodes have no memory. Tests on the virtual node I have access to where that problem report originated is still not quite right. There is now a different assertion failing than I had seen before:

[OMPI devel] Matched probe support

All - With r25865, the trunk now has support for the MPI-3 matched probe functionality. Currently, all PMLs other than OB1 will throw a not implemented error when mprobe, improbe, mrecv, or imrecv are called. I will adding support to CM for matched probe (which will likely require changes to

Re: [hwloc-devel] 1.3.2rc1 has escaped

On 2/8/2012 8:58 AM, Jeff Squyres wrote: * Detect when a compiler such as xlc may not report compile errors properly, causing some configure checks to be wrong. Thanks to Paul H. Hargrove for reporting the problem and providing a patch. Looks like I botched this one! I have added two

Re: [OMPI devel] 1.4.5rc5 has been released

On 2/8/2012 11:14 AM, Paul H. Hargrove wrote: On 2/8/2012 3:25 AM, TERRY DONTJE wrote: + Building w/ Solaris Studio 12.2 or 12.3 on Linux x86-64, with "-m32" required setting LD_LIBRARY_PATH. Can the LD_LIBRARY_PATH be substituted with a rpath change in LDFLAGS of the build? Terry sent

[OMPI devel] Autotools update

Some of you may have already noticed: As the v1.5 RM, I took the executive decision this morning to bump up the tarball versions of the GNU Autotools on the v1.5 branch this morning. Some of you may remember that we have a policy of not changing autotools versions in a release series unless we

Re: [hwloc-devel] 1.3.2rc1 has escaped

On 2/8/2012 9:18 AM, Samuel Thibault wrote: Jeff Squyres, le Wed 08 Feb 2012 17:59:04 +0100, a écrit : Please test! http://www.open-mpi.org/software/hwloc/v1.3/ Could somebody test it on AIX, and with xlc? Thanks, Samuel No AIX, but I will hit xlc on Linux again today. Do we care

Re: [OMPI devel] 1.4.5rc5 has been released

On 2/8/2012 3:25 AM, TERRY DONTJE wrote: + Building w/ Solaris Studio 12.2 or 12.3 on Linux x86-64, with "-m32" required setting LD_LIBRARY_PATH. Can the LD_LIBRARY_PATH be substituted with a rpath change in LDFLAGS of the build? Terry sent more specific instructions for that offlist, and I

Re: [hwloc-devel] 1.3.2rc1 has escaped

Jeff Squyres, le Wed 08 Feb 2012 17:59:04 +0100, a écrit : > Please test! > > http://www.open-mpi.org/software/hwloc/v1.3/ Could somebody test it on AIX, and with xlc? Thanks, Samuel

[hwloc-devel] 1.3.2rc1 has escaped

Please test! http://www.open-mpi.org/software/hwloc/v1.3/ Here's the changes since 1.3.1: * Fix missing last bit in hwloc_linux_get_thread_cpubind(). Thanks to Carolina Gómez-Tostón Gutiérrez for reporting the issue. * Fix build with -mcmodel=medium. Thanks to Devendar Bureddy for

Re: [OMPI devel] 1.4.5rc5 has been released

On 2/7/2012 9:57 PM, Paul H. Hargrove wrote: On 2/7/2012 2:37 PM, Paul H. Hargrove wrote: + "make check" fails atomics tests using GCCFSS-4.0.4 compilers on Solaris10/SPARC Originally reported in: http://www.open-mpi.org/community/lists/devel/2012/01/10234.php This is a matter of the

Re: [OMPI devel] 1.4.5rc5 has been released

On 2/7/2012 4:25 PM, Paul H. Hargrove wrote: On 2/7/2012 8:59 AM, Jeff Squyres wrote: This fixes all known issues. Well, not quite... I've SUCCESSFULLY retested 44 out of the 55 cpu/os/compiler/abi combinations currently on my list. I expect 9 more by the end of the day (the

Re: [OMPI devel] 1.4.5rc5 has been released

Add 3 more to the PASS list: linux/x86-64 open64 w/ -m32 openbsd5/amd64 llvm-gcc-2.9 (C and C++, no FORTAN) openbsd5/i386 llvm-gcc-2.9 (C and C++, no FORTAN) -Paul -- Paul H. Hargrove phhargr...@lbl.gov Future Technologies Group HPC Research Department

Re: [OMPI devel] 1.4.5rc5 has been released

On Tue, Feb 7, 2012 at 7:54 PM, Paul H. Hargrove wrote: [snip] > Of those 54: > + 47 require nothing "extra" (just --prefix, CC & friends, and CFLAGS & > friends for non-default ABIs) > [snip] I found 5 more, making a total of 52 out of 59 configs that PASS with no "extra"