On Mar 18, 2008, at 12:10 PM, Dirk Eddelbuettel wrote:
| What platforms in particular are not supported that Debian wants?
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
FWIW, I'm not aware of any current OMPI members who care about these
platforms.
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
Perfect; thanks.
Is/Was HP part of Open MPI ? Or are they 'neutral', or worse in
'enemy
territory' ?
HP is a big company. :-)
I believe that part of HP doesn't care about Open MPI, but most of the
HPC portion HP is probably against Open MPI because HP sells their own
MPI (HP MPI). So HP will likely never be a formal member of the Open
MPI Project.
But we all work together; the MPI implementor community is fairly
small and many of us know each other. We have good working
relationships. Part of the goal of Open MPI is to come up with good
ideas and let others use them. :-)
| 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.
I sent the link for the project to a few OMPI developers yesterday,
and our collective IANAL opinion is that only one sub-library in
libatomics_ops needs to be avoided (because it's specifically GPL) --
all other library bits are MIT and therefore are ok.
| 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.
It's not the C that's the problem -- it's the assembly. It *looks*
like they use inline assembly only, and not all compilers support
that. This is somewhat of a dealbreaker for us -- meaning that we
couldn't make this the default / only option available.
More below.
| 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.
The consensus yesterday was:
- license looks ok, but needs official review
- looks like they support all the atomic ops we need except for timers
- we could probably make a patch for a --with-libatomic-ops configure
switch that would swap out our default atomic ops with libatomic_ops
Brian (the developer who isn't officially on our project anymore, but
OMPI is still in his heart...) said he could look at making up such a
patch. I wouldn't want to estimate a timeline, though.
We probably will not be embedding this package in Open MPI because:
- it doesn't work for all compilers
- it doesn't work for all OS's / platforms
- and therefore it won't be our default/core
Hence, linking to it via an external header / library is fine.
--
Jeff Squyres
Cisco Systems
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
