gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] Re: Compiling floating point loops to blas calls


From: Camm Maguire
Subject: Re: [Gcl-devel] Re: Compiling floating point loops to blas calls
Date: 12 Jul 2002 18:18:59 -0400

Greetings, and thankd for your reply!

Just to pursue this a might further, a few questions:

1) What are the "top" five ways a lisp programmer would write a matrix
   multiply?
2) Are the other possibilities
        a) few in number 
        b) representable as a product of possibilities of several
           terms, each with relatively few alternatives,
           i.e. sloop/loop/dotimes, in/below/..., etc.?
3) How much lisp code is out there using numerical floating point?
   How much is "open source"?

Take care, 


Raymond Toy <address@hidden> writes:

> >>>>> "Camm" == Camm Maguire <address@hidden> writes:
> 
>     Camm> Greetings!  Given the often cited advantage of lisp in using macros 
> to
>     Camm> effectively rewrite code, I was wondering how difficult it might be 
> to
>     Camm> add a few routines to gcl's lisp compiler which would rewrite 
> floating
>     Camm> point loops to blas calls where possible.  Gcl could then link to
>     Camm> optimized blas libs if available at runtime in preference to a 
> reference
>     Camm> implementation which could be included in the distribution.
> 
> In general I think it would be very hard.  The compiler would have to
> recognize the various constructs and somehow determine that this is a
> BLAS function.
> 
> I think you would be much better off by supplying a gcl lisp binding
> to BLAS routines and give a Lisp reference implementation.  Then if
> you have BLAS you can link it into your code and win big.  Of course,
> if you do a gcl lisp binding, I'd prefer you lisp binding use the same
> names as Matlisp.  But I'm biased. :-)
> 
> Of course, if you do that, you might as well write the necessary
> macros to actually port Matlisp to gcl so you get BLAS and LAPACK and
> even ATLAS.  I don't think that is too hard if gcl has a reasonably
> complete FFI.
> 
> Ray
> 
> P.S.  The build problem with gcl on sparc is due to that fact that the
> standard /bin/sh in Solaris doesn't understand the -e option to test.
> The -f option will work, but I don't know if that is good enough.
> Unfortunately, gcl still doesn't build for me.  The mp or gmp
> libraries are built right or something because some routines are
> missing.  (Didn't report this since I'm not on the mailing list.)
> 
> _______________________________________________
> 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]