One use-case is in an open source code base, another I'm not sure about but may
be. I expect both of those will surface (in one way or another) by end of the
year.
The other one is proprietary for now - don't know their long-term plans.
On Oct 9, 2013, at 10:33 AM, Bibrak Qamar wrote:
> Just
Just curious, are these projects open ?
Bibrak Qamar
On Wed, Oct 9, 2013 at 10:30 PM, Ralph Castain wrote:
> Actually, yes! Now that the bindings have been updated, we have several
> projects getting underway - just had a conference call about one of them
> this morning :-)
>
>
> On Oct 9, 20
Actually, yes! Now that the bindings have been updated, we have several
projects getting underway - just had a conference call about one of them this
morning :-)
On Oct 9, 2013, at 9:49 AM, Tom Vacek wrote:
> First, what is going on with the mpi forum? The site seems to be down.
> Anyway,
Right. I was suspecting that MPI would be used like an external interface
to bridge parts of algorithms that can't be efficiently expressed in MR.
MR at present has some limitations, but it is great for some
bread-and-butter tasks.
On Wed, Oct 9, 2013 at 11:54 AM, Bibrak Qamar wrote:
> Yes, I
Yes, I am curious too regarding the architecture of the applications.
Will it be Map-Reduce functionality implemented using Java but for
communications MPI will be used?
Or Will the Hadoop be integrated with MPI (using the Java-Bindings)?
Bibrak
On Wed, Oct 9, 2013 at 9:49 PM, Tom Vacek wrot
First, what is going on with the mpi forum? The site seems to be down.
Anyway, has there been any activity in using MPI codes with Map-Reduce
jobs, which was the original justification for bringing in the java
bindings? I'm just curious. Thanks in advance!
Mellanox --
Is anyone working on the oshmem issue that I identified in
https://svn.open-mpi.org/trac/ompi/changeset/29165?
See
https://svn.open-mpi.org/trac/ompi/browser/trunk/config/oshmem_configure_options.m4?rev=29165#L82
for details.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal
See https://svn.open-mpi.org/trac/ompi/changeset/29408.
On Oct 9, 2013, at 8:00 AM, Mike Dubman wrote:
> Hi Jeff,
>
> I`m unable to reproduce this fail with gcc and -m32 flags.
> I added same command line to jenkins (and in jenkins we trust) - and it
> passed on RHEL 6.4 with stock gcc.
>
>
This commit results in several warnings in recent versions of Automake (e.g.,
1.13.3). Please see the Automake docs for how you're supposed to use
AC_COMPILE_IFELSE with AC_LANG_SOURCE.
-
configure.ac:1089: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected
in body
../../lib/autoc
Doing pointer math with (void*) is not defined.
For example: http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/Pointer-Arith.html
says that gcc allows it, but this is in the "C Extensions" part of the manual.
I suspect that the latest icc allows it by the same rationale, but it's still
technically wr
IIRC, the concern was with where the thread safety should reside. Some classes
(e.g., opal_list) were littered with thread locks for every operation. So if
someone implemented thread protection at a higher level (e.g., protecting the
list while cycling thru it), then all these lower-level lock/u
Hi,
We have icc test in jenkins and it passes.
What icc version do you use and exact command line to configure?
Is it latest trunk?
Thanks
M
On Tue, Oct 8, 2013 at 5:37 PM, Jeff Squyres (jsquyres)
wrote:
> With icc, getting errors about pointer math with (void*) types. See
> attached.
>
> --
>
Hi Jeff,
I`m unable to reproduce this fail with gcc and -m32 flags.
I added same command line to jenkins (and in jenkins we trust) - and it
passed on RHEL 6.4 with stock gcc.
Please check that you run it on latest trunk and please provide a gcc
version if it is not a stock one.
Thanks
M
On
My concern is that increasing the number of interfaces will not make the code
thread safe, as in most cases thread safety is not only a matter of using a _mt
version of the basic class object but a matter of a careful manipulation of
higher level concepts.
We can hardly use the lack of the _MT
14 matches
Mail list logo
