Ralph,
I think you and I may be confusing each other with the meaning of
"standard":
You asked me
So I'm not sure what you are asking that hasn't already been done…
My reply to that question is that when I wrote
a) a standard to which the bindings can claim to conform
I meant "a) JAVA bindings standardized by the MPI Forum."
In other words, I feel that new language binding should kept out of the
trunk until there is a standard from the MPI Forum.
I don't think that is a "chicken-and-egg" problem, because the branch
would be available to the Hadoop community to show the Forum that
existence of the necessary community. IN FACT, download stats for that
branch could be shown as evidence of that interest.
So, now I hope it is at least clear where we disagree.
I am, as I said at the start, NOT an OMPI developer and so I won't argue
this point any further.
-Paul
On 2/7/2012 12:48 PM, Ralph Castain wrote:
On Feb 7, 2012, at 1:43 PM, Paul H. Hargrove wrote:
Forgive me if I misunderstand, but I am under the impression that the MPI Forum
has not begun any standardization of MPI bindings for JAVA. Have I missed
something?
No, they haven't - but that doesn't mean that the bindings cannot conform to
the standard. Remember, the standard doesn't dictate that you can't have Java
bindings - it just doesn't currently require that you do. Big difference in
those two statements.
-Paul
On 2/7/2012 12:39 PM, Ralph Castain wrote:
We already have a stable, standard interface for non-C language bindings, Paul
- the C++ bindings, for example, are built on top of them.
The binding codes are all orthogonal to the base code. All they do is massage
data access and then loop back to the C bindings. This is the normal way we
handle all non-C bindings, so nothing different there.
The work has been done on a branch, and an RFC issued. The bindings conform to
the MPI standard, and the implementation uses an existing external, third-party
binding that has been tested.
So I'm not sure what you are asking that hasn't already been done…
On Feb 7, 2012, at 1:33 PM, Paul H. Hargrove wrote:
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
_______________________________________________
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
_______________________________________________
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
