[Ecls-list] Using Femlisp with ECL / Bug reports

[Juan Jose Garcia Ripoll]

On Thu, 2005-08-04 at 18:06 +0200, Nicolas Neuss wrote: 
> I am just evaluating if it is possible to use ECL reasonably for my PDE
> toolbox Femlisp.  My requirements are fast floating point operations and
> quite some ANSI compatibility.

As far as ECL is concerned, floating point numbers are unboxed inside a
function, but not across functions (not yet, at least). Most operations
with these unboxed numbers happen to be inlined, and when not, this can
be reported as an error and we will try to figure out why not.

> 1. The CVS version of SLIME does not work.  *inferior-lisp* ends with the
> message:
> 
>   ;;; Loading "/home/neuss/CL-HOME/elisp/slime/nregex.lisp"
>   ;;; Loading "/home/neuss/CL-HOME/elisp/slime/swank-ecl.lisp"
>   Module error: Don't know how to REQUIRE SOCKETS.
>   Broken at REQUIRE.
>   SWANK-BACKEND>>

You need TCP sockets for slime to work. Configure ECL with the flag
--with-tcp and rebuild it.

> 2. I have problems with logical pathnames.  I am using:
> 
>   (defvar *femlisp-pathname*
>     (make-pathname :directory (pathname-directory *load-truename*)))
> 
>   (let ((directory (pathname-directory *femlisp-pathname*)))
>     (setf (logical-pathname-translations "FEMLISP")
>           `(("**;*.*.*"
>              ,(make-pathname :directory `(, at directory :wild-inferiors)
>                              :name :wild :type :wild :version :wild)))))
> 
>   (load "femlisp:femlisp-config.lisp")
> 
> and get an error[...] However, PROBE-FILE works:

Fixed in CVS. My latest commit to fix translation problems when :VERSION
= :WILD was a total disaster born out of the lack of sleep.

> 3. Loading my floating point performance test
> 
>   <http://sit.iwr.uni-heidelberg.de/~neuss/misc/mflop.lisp>

> with (load (compile-file "mflop.lisp")) yields
> 
> DDOT-long: 158.84 MFLOPS
> DDOT-short: 466.84 MFLOPS
> DAXPY-long: 7.84 MFLOPS
> DAXPY-short: 7.63 MFLOPS
> 
> The first two values are fine, but the other ones are much worse than GCL
> which gives:
> 
> DDOT-long: 189.04 MFLOPS
> DDOT-short: 511.31 MFLOPS
> DAXPY-long: 99.42 MFLOPS
> DAXPY-short: 447.39 MFLOPS
> 
> Why?

I am looking now into the output of the compiler. Most likely, the array
operations are not being inlined. However, I would never implement these
operations in lisp itself, but rather link against an optimized BLAS
library. I do that even when programming in C/C++.

Regards,

Juanjo