WHAT:Merge the PMIx branch into the devel repo, creating a new
OPAL “lmix” framework to abstract PMI support for all RTEs.
Replace the ORTE daemon-level collectives with a new PMIx
server and update the ORTE grpcomm framework to support
SHARED is only supported when the pthread library does support spinlock,
while in all other case it falls back into using atomic locks. Providing
support only for a small fraction of environments without reporting errors
or providing any alternative on other systems is difficult to accept.
I think
Josh,
The specific compilers that caused the most problems are the older PGI
compilers (any before 13.x).
In this case the user has the option to update their compiler to 13.10 or
newer.
There are also issues with IBM's xlf.
For the IBM compiler I have never found a version that builds/links the
We will update the README accordingly. Thank you, Paul.
Josh
On Thu, Aug 14, 2014 at 10:00 AM, Jeff Squyres (jsquyres) <
jsquy...@cisco.com> wrote:
> Good points.
>
> Mellanox -- can you update per Paul's suggestions?
>
>
> On Aug 13, 2014, at 8:26 PM, Paul Hargrove wrote:
>
> > The following
WHAT: Add a new "opal/threads/spinlock.h" header to OPAL that will typically
use the OS spinlock primitives if present.
WHY: opal_mutex_t is too slow for some use cases and opal_atomic_lock_t is
inefficiently implemented for most architectures
WHEN: timeout is after next week's engineering call
Woot -- thank you!
On Aug 14, 2014, at 1:19 AM, Ralph Castain wrote:
> Fantastic - thanks Paul!!!
>
>
>
> On Wed, Aug 13, 2014 at 9:18 PM, Paul Hargrove wrote:
> I have completed testing the majority of the platforms I have access to.
> The only issue that is not already known to exist in ea
Good points.
Mellanox -- can you update per Paul's suggestions?
On Aug 13, 2014, at 8:26 PM, Paul Hargrove wrote:
> The following is NOT a bug report.
> This is just an observation that may deserve some text in the README.
>
> I've reported issues in the past with some Fortran compilers (most
Fantastic - thanks Paul!!!
On Wed, Aug 13, 2014 at 9:18 PM, Paul Hargrove wrote:
> I have completed testing the majority of the platforms I have access to.
> The only issue that is not already known to exist in earlier releases was
> the missing osx/atomic.h, for which Ralph promptly merged Ge
Done - thanks!
On Wed, Aug 13, 2014 at 9:06 PM, George Bosilca wrote:
> The atomic.h file should also be trimmed of the SPARC relique.
>
> George.
>
>
> Index: opal/include/opal/sys/atomic.h
> ===
> --- opal/include/opal/sys/ato
I have completed testing the majority of the platforms I have access to.
The only issue that is not already known to exist in earlier releases was
the missing osx/atomic.h, for which Ralph promptly merged George's fix.
If I include the re-tested osx-atomics (which passes w/ 1.8.2rc5r32531), I
have
The atomic.h file should also be trimmed of the SPARC relique.
George.
Index: opal/include/opal/sys/atomic.h
===
--- opal/include/opal/sys/atomic.h (revision 32531)
+++ opal/include/opal/sys/atomic.h (working copy)
@@ -162,8 +162,
Fix confirmed using the nightly tarball (v1.8rc5r32531).
-Paul
On Wed, Aug 13, 2014 at 6:16 PM, Ralph Castain wrote:
> Thanks Paul - fixed in r32530
>
>
>
> On Wed, Aug 13, 2014 at 2:42 PM, Paul Hargrove wrote:
>
>> When configured with --enable-osx-builtin-atomics
>>
>> Making all in asm
>>
12 matches
Mail list logo
