gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] Re: gcc-3.2 problems in compiling GCL


From: Camm Maguire
Subject: Re: [Gcl-devel] Re: gcc-3.2 problems in compiling GCL
Date: 24 Feb 2003 11:26:39 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

Richard Zidlicky <address@hidden> writes:

> On Tue, Feb 18, 2003 at 04:46:46PM -0500, Camm Maguire wrote:
> > Greetings, and thanks for the insight.  GCL does a subbuild of part of
> > GMP.  With the default configure script canonical host of
> > m68k-unknown-linux-gnu, gmp3 adds -m68000 to the command line.
> 
> this is slightly broken - there has never been 68000 support
> in Linux.
> 
> > Perhaps the autobuilders should use m68020-unknown-linux-gnu as the
> > lowest common denominator?
> 
> this would work but not very well on 68060 models though.. here
> are the options:
>   a) use m68k-*linux WITHOUT -m68000 flag. Will loose some
>      performance on 68020-40 models, nearly optimal for 68060
>   b) m68020-linux will loose *lots* of performance on 68060 models.
>   c) compile 2 versions of the library/program for 20-40 or 60
>      models.
> 
> (a) is pretty acceptable, (b) would be probably the worst alternative. 
> (c) would be nice and I think it is time to use multilibs for m68k-linux.
> 

OK, this won't get done before the next release, but what I'd like to
do is 1) benchmark the bignum code and see if these issues make a big
difference, and 2) assuming yes to 1), implement a dynamic library
alternative system as is done in atlas/lapack/blas on Debian
GNU/Linux, say by building a libgcl_gmp.so.  I don't know if you are
familiar with how this works, but I'd like your feedback if you are
interested.  Basically, one can install several binary-compatible
versions of the same library, and have the running cpu select the best
one for its capabilities at run time via ld.so.conf.  I've made a
policy proposal, but thus far it has not received much interest:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=120418

In any case, this works great right now for blas and lapack API's on
Debian, and quite a few packages rely on it.  I feel this is the way
to go for performance critical pieces of code in a generic
distribution like Debian.

Take care,

> Richard
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
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]