[Top][All Lists]

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

Re: [Gcl-devel] Floating-point performance of GCL? Bug?

From: Nicolas Neuss
Subject: Re: [Gcl-devel] Floating-point performance of GCL? Bug?
Date: 20 Jul 2004 09:13:08 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Camm Maguire <address@hidden> writes:

> Greetings!  Thanks for your work on your project.  I think gcl is a
> natural fit given your emphasis.

Yes, after your post I think GCL might become an important factor for

> This, as Mike has posted separately, has been fixed in 2.6.3, which
> should be in Debian sid by now.

I have fetched it and tried again.  Very nice.  The results are comparable
with CMUCL (when replacing INCF as you describe below).  I am impressed.
When I looked last time at GCL (maybe 2 years ago) things were much worse.
Thank you all for your work!

> The bottleneck here is your use of
> (incf (aref y i) (* s (aref x i)))
> which expands in cmucl, clisp and gcl (at least at present) to
> (macroexpand '(incf (aref y i) (* 3.0 (aref x i))))
> (LET* ((#:G1571 Y) (#:G1572 I)
>        (#:G1573 (+ (AREF #:G1571 #:G1572) (* 3.0 (AREF X I)))))
>   (SYSTEM:ASET #:G1571 #:G1572 #:G1573))
> The gensym binding destroys your type declaration information and your
> performance.  Compile with :c-file t and examine the output for
> confirmation if you wish.
> Using instead:
> (setf (aref y i) (+ (aref y i) (* s (aref x i))))
> gives you fully optimizable code.  incf has to rebind the y/i aref as
> it is only mentioned once in the form, but actually used twice.
> Paul, is there a way in which we could write the setf expanders to
> avoid rebinding symbols in cases like this where the 'store form' does
> not alter them?  Does this sound like a can of worms?

This would be fine.  I can certainly convert to SETF in bottlenecks, but it
somehow feels not to be the right fix.

> But if your really want performance in this area, and you have Debian at
> hand, use clines and defentry to define a lisp binding to the blas api,
> and link blas into a new image with compiler::link.  There is a thread on
> axiom-developer, perhaps cc'ed to gcl-devel, with more detail.

I think, I'll subscribe to the axiom list as well.  And I'll try to make
Femlisp run with GCL.

Thanks for all the info,


reply via email to

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