I agree - we do have better things to do than argue about things that have no impact on anyone not choosing to use them.
If you had read the RFC, you would have seen that the Hadoop businesses are unwilling to trust their future to a 3rd party bolt-on that already shows bit-rot. Hence, the desire to hire/fund people to put it in the mainstream. As I said, this doesn't impact anyone. So let's just agree to disagree and move on. On Feb 8, 2012, at 7:34 PM, George Bosilca wrote: > 3 anonymous accesses and 12 developer accesses from 2010-11-25 till today, > that's what the mpiJava project hosted on sourceforge got. It tends to say > something about the need for such a binding now, the size of the community > requiring such a binding and about the support Open MPI should throw to it > ahead. > > Make it grow, flourish, build its own community and then let's reevaluate > your request. Until then, we all have more interesting things to do. > > george. > > http://sourceforge.net/projects/mpijava/stats/scm?repo=HgRepository&dates=2010-07-10+to+2012-02-09 > > > On Feb 7, 2012, at 16:16 , Ralph Castain wrote: > >> No problems, Paul. I appreciate your input. >> >> If everything in the trunk was required to in the standard, then much of the >> trunk would have to be removed (e.g., all the fault tolerance code). As Jeff >> indicated, the trunk is an area in which we bring new functionality for >> broader exposure. I very much doubt there will be much instability for >> anyone not using the Java bindings (though I do expect some degree of >> debugging in that arena), but my ears are open if/when someone finds >> something. >> >> You are welcome to try the branch, if it would help resolve concerns: >> >> https://bitbucket.org/rhc/ompi-jv2 >> >> >> On Feb 7, 2012, at 2:06 PM, Paul H. Hargrove wrote: >> >>> 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 >>> >>> _______________________________________________ >>> 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
