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

[Nicolas Neuss]

"Mike Thomas" <address@hidden> writes:

> Hi Nicholas.
> 
> Thanks for your enquiry about the suitability of GCL for Femlisp and also
> for your bug report.
> 
> I think a speedy reply to your message has been the victim of ISP problems
> for our chief programmer and optimizer, Camm Maguire.
> 
> Looking at your problem on the weekend under Windows XP I reproduced the
> crash with the old stable release GCL 2.6.2 but not with CVS HEAD GCL or
> with the recently released stable GCL 2.6.3.

That's nice to know.  I hope that Debian updates soon.  Then I'll try
again.

> There's two consecutive runs on a 2.4 GHz, 512 Mb P4 Windows XP box using
> GCL 2.6.3, below.  My DAXPY results are woeful compared with your own.
> Windows GCL has substantially different memory management to the Unix
> platforms however.
> 
> I feel safe in saying that we would like to ensure that GCL meets your needs
> with Femlisp as there is a tendency for GCL to be used in mathematical
> applications and Camm, Vadim, Dave, myself and probably many others on this
> list are also interested in those uses.

It would also be important for Femlisp, because of portability to Windows
and non-standard (or 64-bit) hardware.

> Possibly the greatest obstacle for you at this point will be ANSI
> compatibility.  We are rapidly moving towards that goal for the next major
> version stable release (2.7.0) and I believe that Femlisp will be an
> excellent test case to that end.

Probably.  I have no idea how much I would have to change now.

> In particular, Michael Koehne has been recently been developing the low
> level functionality required to support ASDF - a prerequisite for
> Femlisp.

OK.  But also defsystem would be fine.  In fact, I changed to ASDF only
recently, and I am not really convinced that this was a good step.  It
would be easy to provide also the defsystem file which differs only little
from the ASDF one.

> Both he and Camm have been also been considering ways to improve the
> performance of our CLOS implementation, PCL, which I understand is also
> important to the operation of Femlisp.

Yes.  I guess that (after floating point performance) this is the most
crucial part.  Gerd Moellmann's recent changes to CMUCL's PCL were very
helpful.

> DDOT-long: 205.83 MFLOPS
> DDOT-short: 577.80 MFLOPS

These look acceptable, although the C version gives better results:

gcc -O3 mflop.c; a.out
ddot-long 272.34 MFLOPS
ddot-short 917.73 MFLOPS
daxpy-long 163.06 MFLOPS
daxpy-short 1136.23 MFLOPS

[Aside: Interestingly, those numbers can be surpassed (for short vectors,
i.e. no cache issues).  Performance of a matrix-matrix-multiply of the
ATLAS library gives a peak performance of about 3 GFLOPS on my machine!  I
guess this requires Intel's compiler, though.  Can GCL use other compilers
than GCC?]

> DAXPY-long: 10.40 MFLOPS
> DAXPY-short: 11.98 MFLOPS

These do not.  Basic question: can GCL handle unboxed floating point
numbers and uniform arrays of those?  I didn't find anything in the
documentation when I looked last time, and this would probably be the
decisive step.

Thanks, Nicolas.