As an HPC software developer and user of OMPI, I'd like to add my $0.02
here even though I am not an OMPI developer.
Nothing in George's response seems to me to preclude the interested
institutions (listed as FROM in the RFC) from forking a branch to pursue
this work until there can be standardization of Java bindings. If the
JAVA bindings really are as "orthogonal" to the rest of the code as the
RFC authors claim, then merging a branch back to the trunk when they
have a stable/standard interface should not be onerous.
I know from experience in other projects that work that SHOULD "have
zero impact" on those not using it seldom does. There is always
something that pops up, such as small autotools mistakes that break
nighlty tarballs and goofs like that. If nothing else, the existance of
the JAVA bindings would seem to impose an additional testing burden on
developers making changes to internal interfaces and data structures.
For that reason I agree w/ George that there is not yet sufficiently low
risk/reward to support adding Java bindings in OMPI's trunk.
So I'd propose that the work be done on a branch and the RFC can be
reissued when there is both
a) a standard to which the bindings can claim to conform
b) an implementation which has been shown to be stable
-Paul
On 2/7/2012 12:18 PM, Ralph Castain wrote:
Nobody is asking us to make any decision or take a position re standardization.
The Hadoop community fully intends to bring the question of Java binding
standards to the Forum over the next year, but we all know that is a long,
arduous journey. In the interim, they not only asked that we provide the
bindings in our release, but also are providing the support to maintain them.
If members of the Python or R communities were to step forward, offer to do the
work and maintain it, and could show it had zero impact on the rest of the code
base, I for one would welcome their bindings. Can't see the harm - can always
be removed if/when they ceased to support them on their own.
On Feb 7, 2012, at 12:33 PM, George Bosilca wrote:
This doesn't sound like a very good idea, despite a significant support from a
lot of institutions. There is no standardization efforts in the targeted
community, and championing a broader support in the Java world was not one of
our main target.
OMPI does not include the Boost bindings, despite the fact that it was
developed at IU. OMPI does not include Python nor R bindings despite their
large user community. Why suddenly should we provide unstandardized Java
bindings?
I think we should not tackle such inclusion before there is at least a
beginning of a standardization effort in the targeted community. They have to
step up and address their needs (if they are real), instead of relying on us to
take a decision. Until then, the fast growing targeted community should
maintain the binding as a standalone project on their own.
george.
On Feb 1, 2012, at 15:20 , Ralph Castain wrote:
FROM: LANL, HLRS, Cisco, Oracle, and IBM
WHAT: Adds Java bindings
WHY: The Hadoop community would like to use MPI in their efforts, and most of
their code is in Java
WHERE: ompi/mpi/java plus one new config file in ompi/config
TIMEOUT: Feb 10, 2012
Hadoop is a Java-based environment for processing extremely large data sets.
Modeled on the Google enterprise system, it has evolved into its own
open-source community. Currently, they use their own IPC for messaging, but
acknowledge that it is nowhere near as efficient or well-developed as found in
MPI.
While 3rd party Java bindings are available, the Hadoop business world is leery of depending on
something that "bolts on" - they would be more willing to adopt the technology if it were
included in a "standard" distribution. Hence, they have requested that Open MPI provide
that capability, and in exchange will help champion broader adoption of Java support within the MPI
community.
We have based the OMPI bindings on the mpiJava code originally developed at IU,
and currently maintained by HLRS. Adding the bindings to OMPI is completely
transparent to all other OMPI users and has zero performance impact on the rest
of the code/bindings. We have setup the configure so that the Java bindings
will build if/when they can or are explicitly requested, just as with other
language support.
As the Hadoop community represents a rapidly-growing new set of customers and
needs, we feel that adding these bindings is appropriate. The bindings will be
maintained by those organizations that have an interest in this use-case.
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
