This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
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
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.
>> 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
>> devel mailing list
> devel mailing list
Paul H. Hargrove PHHargrove_at_[hidden]
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900