On Oct 30, 2014, at 12:19 PM, Ralph Castain wrote:
> I believe we did this in the trunk to try and force thread-safety
> implementation, but I don’t believe it was intended to transition to the
> release branch. The only thread-related requirement on the release branch is
> that libevent be co
(2nd try as the first log package was too big)
Hello Howard,
The version 1.8.1 installed on Jun 27 this year run fine, ROMIO is OK.
Trying ro re-run using the same install script: found out that also 1.8.1
version of Open MPI now *cannot* build ROMIO support. Wow.
That means that the regress
Hi Howard,
No, we do not, just the OMPI default.
This post isn’t so much about our packaging requirements, as about default
behavior in upstream Open MPI. We’d like performance to be good by default for
anyone compiling their own Open MPI (and using PSM).
Andrew
From: devel [mailto:devel-bou
I believe we did this in the trunk to try and force thread-safety
implementation, but I don’t believe it was intended to transition to the
release branch. The only thread-related requirement on the release branch is
that libevent be configured with thread-support.
Anyone know of a reason why mu
Hi Andrew,
In your distribution of ompi, do you include versions of ompi to support
different MPI thread safetylevels? In particular, do you include a library
which supports MPI_THREAD_MULTIPLE?
Just trying to better understand the requirements of you ompi package in
terms of MPI thread safety.
Hi,
I'm reporting a performance (message rate 16%, latency 3%) regression when
using PSM that occurred between OMPI v1.6.5 and v1.8.1. I would guess it
affects other networks too, but I haven't tested. The problem stems from the
--enable-smp-locks and --enable-opal-multi-threads options.
--e
