[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Number crunching in CLISP.
>>>>> "Harvey" == Harvey J Stein <hjstein@MATH.HUJI.AC.IL> writes:
Harvey> Bruno once told me that CLISP does
Harvey> all floating point operations by itself (i.e. - doesn't use
Harvey> the FPU). Is this correct? If so, I won't be able to use it.
Harvey> If it does do floating point in software, how hard is it to
Harvey> change this? Are floating point numbers stored in system
Harvey> format (as a C float)?
Platforms like hppa, m88000, rs6000, and sparc can use floating point
hardware. Look aridecl.d, arilev0.d, dfloat.d, intlog.d, and sfloat.d
for the dependencies. Declare support in lispbibl.d. FAST_DOUBLE and
FAST_FLOAT is what you are looking for.
Harvey> If it doesn't use the FPU & changing it would be difficult,
Harvey> then what about some other common lisps - does anyone know
Harvey> about GCL & XLISP?
Harvey> From the following quick & simpleminded
Harvey> test, it seems that neither CLISP nor XLISP will be suitable:
Harvey> ------------------ File test.lsp --------------------
Harvey> (defvar i 1)
Harvey> (time (dotimes (j 100000) (setq i (* i 1.00001))))
Harvey> ------------------End file test.lsp -----------------------
The floating point isn't the bottleneck, CLISP's floating point
code is exceptional. The difference between CLISP and C is function
call (byte-code-interpreter) overhead. For loops like this, there it
is always going to be noticeable difference. Using integer arithmetic
such as (setq i (* i 1)) or (incf i) won't make it more than about
twice as fast. With, GCL you will get results similar
to C [for(j=0;j<100000;j++) i*=1.0001;]. On the other hand, you will
be waiting and waiting and waiting for compiles. XLISPSTAT (and its
new experimental compiler) will likely be tuned for the type of
vector-reducing operations that are common in the XLISPSTAT code.
Harvey> Since the C code is doing the loop 10x as many times as the
Harvey> lisp code (I had to crank it up to measure it with the time
Harvey> command), it seems that this C code is over 20 times faster
Harvey> than the compiled CLISP code. If the CLISP was only twice as
Harvey> slow, or even only 5 times slower, I could probably live with
Harvey> it for prototyping purposes (I have things which run for hours
Harvey> on end). So, how can I speed it up?
For this excruciatingly unrealistic code, I think it is the short answer is
"You can't". Write portions of it in C. Use the approach described
in foreign.txt (or ask me to point you to the alpha CLISP with FFI).