On Wed, 17 Nov 2004, Jeff Squyres wrote:
> We anticipate a first stable release in 1Q 2005.
Under what license will it be released ?
> would this be a deterrent to you installing Open MPI from a source
> tarball?
For me, certainly not. I have seen also other answers saying the same.
On the other hand, I think that you have to define what classes of
people you would like to address; as parallel computing is becoming
more mainstream (eh, imagine when Intel will release dual- or multi-
core CPUs...) more people will be looking into running their
computation more efficient. I am not thinking now only about what is
considered scientific computation, but things like video and audio
encoding that has a high impact factor in the Windows world and which
could benefit from parallel processing. As Linux and MacOS are now
entering this application space, it should be equally easy (or even
easier :-)) to do the same tasks. This means installation that doesn't
require compilation at all and that is straightforward; however this
should not hinder the "power users" that want the get the last drop of
performance and are willing to spend time tuning and matching with
various extra hardware/software.
It's not very clear to me yet if Open MPI will use a system similar to
LAM/MPI's shared libraries to add optional modules. This would make
binary installation easier, as a maximum-compatibility tcp+shmem
binary distribution could be eventually extended by some other modules
either provided also as binaries by Open MPI or self compiled (to
accomodate extra libraries). In this direction, maybe Open MPI should
provide network enabled repositories for the most popular Linux
distributions or packaging formats, like a yum/apt-rpm repo with RPMs
for Fedora Fedora/Red Hat (& clones) and another one for .debs (unless
Camm Maguire will volunteer to package it for Debian as he did with
LAM/MPI :-)); sorry, I am completely ignorant as to whether such
mechanism exists for MacOS...
For those that compile from source, I would like to (continue to) see
included what is needed for making the binary packages, like the .spec
file for generating RPMs. This will lower the barrier for
distributions/repositories that would like to provide packages; it
will also make it easier for those hard-liners that don't accept
anything not managed by the package management tool(s).
In line with this, I would like to see also the eventual other tools
needed for building being provided by Open MPI (not in the same
package, of course), in both source and binary form. First and
foremost, this will ensure that the exact same versions of the tools
that the Open MPI developers are using are also available to those who
compile it - this will obsolete statements like: "NOTE: The versions
of these tools that are installed on most systems by default are not
recent enough. You may need to update your installed versions." (from
http://www.open-mpi.org/svn/ which also applies to LAM). The tools
themselves should be as portable as possible and should ideally be
standalone (=not dependent on others, especially not dependent of
something like Java/python/perl/ruby/etc. which are not seen very well
at some HPC sites). This would probably be a big plus for the GNU
auto* tools at the moment which run on virtually anything.
Another thing that I consider important is the speed of the
compilation and installation process. For example, right now with LAM
the configure step takes quite some time; I'd be happy if different
build tools would significantly reduce that time. I would argue that
this is important for some end-users as well: when you have a problem,
you write to the mailing list and might receive an answer like "this
is a bug, can you check out from SVN and test" and it might take
several iterations to do it right (not that I doubt the capabilities
of the Open MPI developers, but I assume that all are Homo sapiens
sapiens :-))
> Indeed, if people ask for binaries for too many systems, it's
> questionable as to whether we could actually provide them all,
> anyway.
FreeBSD and Solaris can run Linux binaries so you don't have to care
about them :-)
--
Bogdan Costescu
IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu_at_[hidden]
|
