[Pkg-openmpi-maintainers] Bug#376833: Bug#376833: Next steps

Tue Mar 18 16:10:32 UTC 2008

Hi Jeff et al,

Thanks for the follow-up!  Lots of good points raised, I'll try to reply 'in
full' and apologize in advance for the length of the email.

We havevery good success with Open MPI on

	i386 amd64 alpha ia64 powerpc sparc

and we are out of luck on

	arm    [ and a new variant armel with fpu support was added IIRC ]
	hppa
	m68k   [ though that architecture may get purged ... ]
	mips   [ there are some compute blades using this IIRC ]
	mipsel       
	s390

For these we can fall back to LAM but that is kinda lame (bad pun alert).

| >> Or are you in fact suggesting that supplant what upstream has with
| >> libatomic-ops-dev?  I would hesitate a great before doing that -- I  
| >> tend to
| >> trust upstream in these matters.
| >
| > That's fair.  On the other hand, it can't hurt to try it, and we  
| > have a
| > good bit of time now for users to test it before the lenny release.   
| > If
| > nothing else, it's worth giving it a go in experimental.  As I said,  
| > if
| > you don't get it to it in a couple of weeks, I'll give it a go.
| 
| I'm afraid I know nothing about libatomic-ops-dev -- I did a few quick/ 
| lame google searches and couldn't turn up a home page for this project  
| (including on debian.org).  Could someone point me in the right  
| direction?
| 
| We can investigate it and see if it meets our needs.

[ You can reply on the file debian/copyright to point to the upstream
sources; and these Debian files are visibile via the 'package tracking
system' pages eg http://packages.qa.debian.org/liba/libatomic-ops.html -- and
I do not mean to imply that you could or should have known that. 

This PTS also shows that the package is actively maintained: recent upoads,
no bugs. Good! ]

The copyright at 
http://packages.debian.org/changelogs/pool/main/liba/libatomic-ops/current/copyright
says downloaded from 

	http://www.hpl.hp.com/research/linux/atomic_ops/download.php4

and lists Hans Boehm and David Mosberger as authors, with their hp.com
addresses and with HP as copyright holders.  Pestering these famous kernel
hackers may be next on our agenda then :)

Is/Was HP part of Open MPI ?   Or are they 'neutral', or worse in 'enemy
territory' ?

| > Debian has generally emphasized sharing code wherever possible.  So  
| > for
| > example, ffmpeg and mplayer have been strongly urged to do what it  
| > takes
| > to share the decoder libraries, which are developed together, though  
| > the
| > release schedules of those two "front ends" have been very different.
| > Likewise, I shoehorned the pysparse python sparse solver front end to
| > fit with Debian's superlu and umfpack (suitesparse package)  
| > libraries in
| > place of the versions provided in the upstream source.  I think the  
| > same
| > principal is at work here.
| 
| Without knowing anything about libatomics-ops-dev, three roadblocks to  
| integrating libatomic-ops-dev into Open MPI could be:
| 
| 1. license: Open MPI is BSD -- what's libtatomics-ops-dev?

Looks similar to me -- but see at the link above.

Mentions the GPL for subcomponents tests and sample apps, so looks like this
is not an issue.

| 2. portability: does it work outside of Linux?  Does it work with non- 
| gcc compilers?  The first is surmountable (see below), but the second  
| would be quite difficult to fix -- we would likely need fixes from the  
| libatomics-ops-dev maintainers.

Good points. Dunno -- we tend to be gcc only as far as Debian goes, but this
_should_ be vanilla C. 

| 3. distribution: we have a core philosophy of aggressively trying to  
| decrease the number of dependencies of Open MPI to enable simple  
| download/install by novice users (we can't always succeed in this, but  
| we do try).  To this point, we have embedded a few "core" dependencies  
| in the Open MPI source code distribution itself so that you don't have  
| to have them installed to build/run Open MPI (e.g., particularly on  
| platforms that may not have them already installed, such as OS X or  
| Solaris).  The atomic operations likely fit into this category such  
| that the OMPI community may be resistant to requiring a 3rd party  
| library just to be able to install/run.
| 
| One *possibility* is that we could use the included atomics unless  
| specifically directed to use libatomic-ops (e.g., via a configure  
| option such as --with-libatomic-ops=/foo).  There's lots of "if's" in  
| there, though -- if the license is compatible, if the library meets  
| our needs, ...etc.  So we would need to investigate a few things first.

Right. Or, if it is small, just pull it in. License permitting etc pp  [
Though as I said, we prefer using existing libraries but I understand that
yoru agenda is driven by different concerns. ]

| >> Generally speaking, it may be worthwhile going to upstream now. So  
| >> lemme CC
| >> them, as well as co-maintainer Manuel.
| >
| > Good idea.  I often work with non-responsive upstream developers, so  
| > my
| > first recourse is usually to "just do it", but thankfully that is not
| > the case with openmpi.
| 
| We're not always quick to reply, but we try.  :-)
| 
| >> I should point out to Jeff and Tim that we do get quasi-constant  
| >> grief about
| >> Open MPI not spanning the Debian universe of arches.  I personally  
| >> fall back
| >> to Lam where Open MPI is missing but that is indeed somewhat cheesy.
| >> Longer-term, full support across all hardware platform would be  
| >> great.
| >> But I am talking way out of area of expertise here -- what do you  
| >> upstream
| >> guys think? Let us have it, and don't hold back.
| 
| 
| The biggest problem is maintenance.  I can't easily justify to my  
| employer spending time on maintenance of platforms that we officially  
| don't care about.  Such is true with many of the other Open MPI  
| developers -- we don't really have someone who is "batting cleanup" to  
| pick up all the loose odds and ends on platforms that aren't  
| officially supported.  :-\

Understood. Maybe you can get the IBM folks to look after s390 ;-)

| If libatomic-ops-dev can fix some of these problems (by automatically  
| picking up [atomic ops] support on some platforms that we don't  
| actively support, especially since our main assembly developer is now  
| gone), that would be great.  But it'll require some investigation first.
| 
| I should also point out that we're gearing up for branching for the  
| v1.3 series and are rushing to finish some critical features before  
| deadline.  To be honest and not inflate expectations, I kinda doubt  
| that we'll have the time to be able to perform due diligence on  
| libatomic-ops-dev and/or integrate it before 1.3 branching.  :-(

Debian is not worried about quarterly performance reports so for as long as
we get some pieces on motion, I'd be perfectly happy to defer to this to
1.3.$x with $x 'high' or even 1.4.0.   We are patient :)  I just spent 18+
months working with Argonne and the original author to get PGAPack relicensed
and back into Debian's main ;-)

We want to do this right.

Thanks for listening,  Dirk

-- 
Three out of two people have difficulties with fractions.