[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: ParGCL/MPI ready to be put into GCL

From: Camm Maguire
Subject: [Gcl-devel] Re: ParGCL/MPI ready to be put into GCL
Date: 23 Jul 2005 03:11:36 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!  Please excuse my delay, and thank you *so* much for
working on this!

I've been working on stabilizing a checkin of my latest tree before
leaving on vacation for 1 week (tomorrow).  I hope to be able to
discuss this with you more when I get back.  Preliminary thoughts below.

Gene Cooperman <address@hidden> writes:

> ParGCL (GCL/MPI) now works fine again.  I'm ready to integrate it into
> GCL.  If you want to preview the latest version, it's at:
>   ftp://ftp.ccs.neu.edu/pub/people/gene/pargcl/pargcl-0.9.3-beta1.tar.gz
> There are two remaining issues:
> 1.  Should I install it directly into the cvs, or do you want to do that?
>   (I used to have an account on savannah (username: gene), but I hadn't used
>    it in more than a year, and it's not currently working for me.)

I'll be happy to if your access is down, but I'm sure it would be
faster if we could restore your access.

> 2.  The ParGCL library has a small footprint (less than 50 KB), and
>   includes its own subset of MPI.  Using
>      ./configure --with-mpicc=
>   one can also use a different MPI.  Currently, I create a separate
>   saved-pargcl, so as to guarantee the integrity of the regular saved-gcl .

Great!  On Debian, one doesn't need mpicc and can add the mpi libs to
the linker command line if they please -- can this be an option too?
we should also remember to set *cc*, *ld* and *ld-libs* in compiler::
in the new image in case the user wants to compiler::link.

>   A.  Should I continue to create a separate saved-pargcl?
>       An alternative is:
>       Build only saved-gcl, and since it's in a separate mpi package,
>               users who don't know or care about MPI won't be disturbed.

I think at present the interested audience will likely be a minority
of users (but not for long!), so perhaps we should not disturb the
default setup.  My personal preference is for autoloadable modules
(see gcl_collectfn.o pulled in by (compiler::emit-fn t), but we will
need to do a little work to get the shared libs to come in at the
right time too in this case.

>   B.  I imagine that I should add to the configure script for GCL a flag
>       such as:   ./configure --enable-mpi
>        Should the default for --enable-mpi be "yes" or "no"?

I'd think 'no" for the time being, but I'm open to discussion if you

> I'm happy to discuss this by phone if you'd like the added bandwidth.

This might be nice when I get back if you still have time!

Take care,

>                                                               - Gene

Camm Maguire                                            address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]