[Top][All Lists]
[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