Dear all,
the Score-P community is currently in the process to support the
OpenSHMEM API in its performance measurement infrastructure Score-P [1].
And we are near a release of a new major version of it. Now that Open
MPI also provides an OpenSHMEM implementation, we extended our testing
also
here it goes, https://svn.open-mpi.org/trac/ompi/changeset/31751
On Wed, May 14, 2014 at 9:19 AM, Bert Wesarg wrote:
> Dear all,
>
> the Score-P community is currently in the process to support the OpenSHMEM
> API in its performance measurement infrastructure Score-P [1]. And we are
> near a re
Good catch. I fixed the TCP BTL (r31753). It is the only BTL I can
test so that's the most I can do here.
However, I never get OPAL_ERR_DATA_VALUE_NOT_FOUND out of the modex
call when the key doesn't exists. I looked in dstore and the correct
value one should look for is OPAL_ERR_NOT_FOUND. I gues
WHAT: Add some basic support so that reduction functions can support GPU
buffers.
All this patch does is move the GPU data into a host buffer before the
reduction call and move it back to GPU after the reduction call.
Changes have no effect if CUDA-aware support is not compiled in.
WHY: Users
Looks like this is a scif bug. From the documentation:
scif_poll() waits for one of a set of endpoints to become ready to perform an
I/O operation;
it is syntactically and semantically very similar to poll() . The SCIF
functions on which
scif_poll() waits are scif_accept(), scif_send(), and sc
Indeed, if the constructor is called then the destructor should be as
well. Adding the destructor call might be a good idea, despite the
fact that it delays everything till the end of the execution. The
benefits during the execution is minimal, it only keeps valgrind happy
at the end.
Btw, can we
Couple of suggestions:
* detect that this is an older scif lib and just don't build or enable the scif
btl
* have a flag that indicates "you should exit", and then tickle the fd so
scif_poll exits
Ralph
On May 14, 2014, at 7:45 AM, Nathan Hjelm wrote:
> Looks like this is a scif bug. From t
Nathan,
> Looks like this is a scif bug. From the documentation:
and from the source code, scif_poll(...) simply calls poll(...)
at least in MPSS 2.1
> Since that is not the case I will look through the documentation and see
if there is a way other than pthread_cancel.
what about :
- use a
It sounds more like a suboptimal usage of the pthread cancelation
helpers than a real issue with the pthread_cancel itself. I do agree
the usage is not necessarily straightforward even for a veteran coder,
but the related issues remain belong to the realm of implementation
not at the conceptual lev
On Wed, May 14, 2014 at 07:55:54AM -0700, Ralph Castain wrote:
> Couple of suggestions:
>
> * detect that this is an older scif lib and just don't build or enable the
> scif btl
>
> * have a flag that indicates "you should exit", and then tickle the fd so
> scif_poll exits
Thinking along these
There seems to be a consensus on the fact that closing an fd should trigger the
return from poll. Unfortunately this assumption is wrong, and not condoned by
any documentation available online.
To be more clear, all documentation I know tend to point in the opposite
direction: it is unwise to c
That is exactly how I decided to fix it. It looks like it is
working. Please try r31755 when you get a chance.
-Nathan
On Thu, May 15, 2014 at 12:03:53AM +0900, Gilles Gouaillardet wrote:
>Nathan,
>
>> Looks like this is a scif bug. From the documentation:
>
>and from the source co
On 05/14/2014 03:15 PM, Mike Dubman wrote:
here it goes, https://svn.open-mpi.org/trac/ompi/changeset/31751
Thank you very much. I will test against the latest nightly builds for
trunk and v1.8 and report back.
Regards,
Bert
On Wed, May 14, 2014 at 9:19 AM, Bert Wesarg wrote:
--
Dipl
13 matches
Mail list logo
