[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
Femlisp.
> 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,
Nicolas.
- [Gcl-devel] Floating-point performance of GCL? Bug?, Nicolas Neuss, 2004/07/16
- Re: [Gcl-devel] Floating-point performance of GCL? Bug?, Nicolas Neuss, 2004/07/19
- FW: [Gcl-devel] Floating-point performance of GCL? Bug?, Mike Thomas, 2004/07/19
- Re: FW: [Gcl-devel] Floating-point performance of GCL? Bug?, Nicolas Neuss, 2004/07/23
- Re: FW: [Gcl-devel] Floating-point performance of GCL? Bug?, Camm Maguire, 2004/07/23
- Re: FW: [Gcl-devel] Floating-point performance of GCL? Bug?, Nicolas Neuss, 2004/07/26
- Re: FW: [Gcl-devel] Floating-point performance of GCL? Bug?, Nicolas Neuss, 2004/07/26
- Re: FW: [Gcl-devel] Floating-point performance of GCL? Bug?, Dennis Decker Jensen, 2004/07/26
- RE: FW: [Gcl-devel] Floating-point performance of GCL? Bug?, Mike Thomas, 2004/07/26