Richard Fateman wrote:
> On 3/18/2012 3:54 AM, Michel Talon wrote:
>>> I think the trouble is, as it is now, I don't think I can rely on
>>> Maxima for doing efficient numerical calculations, and there really
>>> isn't a very usable lisp alternative for something like NumPy,
>>> although Matlisp comes close.
> Are you saying that NumPy is efficient? Or that you like its user
> interface? Or its scope?
NumPy and things going with it are very efficient. For example with weave
you can code the inner parts of a loop in C which is intermingled in the
python code. The system will compile and load the small code snippet and
the execution will run at full compiled speed.
http://docs.scipy.org/doc/scipy/reference/tutorial/weave.html
For more extensive mixing of C and python there are things like pyrex and
cython. There is a nice document comparing these techniques here:
http://www.scipy.org/PerformancePython
This document ends with a benchmark which shows that using pyrex or cython
really allows to have the same performance as pure C.
> With GCL? Also, there is a certain loss inherent in the f2cl, if that
> was used. For example,
> the result of a fortran call by reference is mimicked by a
> multiple-value return, and there may
> be other issues too.
There are other issues far worse than inefficient calls and inefficient matrix
elements access. Looking at the assembly code corresponding to lisp generated
by f2cl from the lapack library will show them more than obviously.
> Actually, C was traditionally
> less favored compared to FORTRAN because the optimization of FORTRAN was
> more
> sophisticated (e.g. loop unrolling, code motion, common subexpression
> optimization....).
> Either C has got this kind of stuff too, or no one cares.
Of course modern C compilers (notably modern gcc) do loop unrolling, common
subexpression elimination, etc. I have an example of a computation on which
using a strong optimisation flag on gcc allows the code to run more than 3
times faster than without optimisation. This is a testimony to the work done
by the optimiser. By the way this is a domain where the closed source compiler
by Intel was traditionally very good. At present i don't see big difference
with the most recent gcc.
Consider the
> possibility that, if you
> are not wedded to portability, you can generate assembler (from lisp
> directly)!
Maybe the lisp compiler (that is python in the case of cmucl) lacks a lot of
sophistication compared to the extensive work which has been done in C
compilers, so that it is more beneficial to go from lisp to C (or
fortran) and delegate the job of producing assembler to an external tool
when high performance is required. I have read that one of the lisp like
able to outperform hand written C, i mean the scheme "compiler" Stalin,
produces in fact C code, but heavily tuned for great performance.
> There is some attempt, CFFI, which I have not used myself, to
> standardize foreign function interfaces.
> My understanding is the GCL doesn't allow this. If SBCL truly runs on
> Windows, (for which there
> seems to be some issues), that would help. I personally solve these
> issues by not
> using "several Common Lisp variants" but only one.
>
which is perhaps outstanding for commercial use, but we are not speaking
commercial use here.
--
Michel Talon