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

[Camm Maguire]

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

Nicolas Neuss <address@hidden> writes:

> Hello,
> 
> I am checking if it is a reasonable alternative to use my PDE-solver
> Femlisp (www.femlisp.org) with GCL.  Femlisp relies heavily on having good
> floating point performance.  Therefore I tried first the test program
> 
> http://www.iwr.uni-heidelberg.de/~Nicolas.Neuss/misc/mflop.lisp
> 
> which gives an error with GCL from Debian:
> 
> ----------------------------------------------------------------
> address@hidden:~$ gcl
> GCL (GNU Common Lisp)  2.6.2 CLtL1   Jun 29 2004 18:53:13
> Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
> Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
> Modifications of this banner must retain notice of a compatible license
> Dedicated to the memory of W. Schelter
> 
> Use (help) to get some basic information on how to use GCL.
> 
> >(compile-file "mflop.lisp")
> 
> Compiling mflop.lisp.
> Warning: The OPTIMIZE quality DEBUG is unknown.
> Warning: The OPTIMIZE quality DEBUG is unknown.
> End of Pass 1.  
> End of Pass 2.  
> OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
> Finished compiling mflop.lisp.
> #p"mflop.o"
> 
> >(load *)
> 
> Loading mflop.o
> DDOT-long: 241.02 MFLOPS
> 
> Error: Value stack overflow.
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by LOAD.
> Broken at MFLOP-TEST.  Type :H for Help.
> >>

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

> ----------------------------------------------------------------
> 
> while the result for CMUCL is:
> 
> -----------------------------------------------------------------
> * (load *)
> 
> ; Loading #p"/home/neuss/mflop.x86f".
> DDOT-long: 271.83 MFLOPS
> DDOT-short: 712.27 MFLOPS
> DAXPY-long: 152.74 MFLOPS
> DAXPY-short: 484.76 MFLOPS
> T
> *
> ----------------------------------------------------------------
> 
> Now, the 241 MFLOPS looks promising.  But why the error?  Furthermore, also
> DAXPY-LONG works, but yields a disappointing performance.
> 

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?

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. 

Take care,

> Yours, Nicolas.
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah