This topic has gotten a *lot* of off-list discussion. :-) Just to tie up the thread for the web archives: this topic will be discussed on the Tuesday teleconf next week. Terry: please add this to the Tuesday agenda.
On Feb 8, 2012, at 9:53 PM, Ralph Castain wrote: > 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 > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
