On 3/18/12 9:34 AM, Michel Talon wrote:
> 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
I'm not at all familiar with these things, but perhaps this would be
interesting:
http://trac.common-lisp.net/cmucl/browser/src/contrib/embedded-c/embedded-c.catalog
It allows you to compile C code easily (even on the fly) and makes it
directly available to cmucl.
Ray
> 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.
>
>
>