[clpython-devel] CMUCL now also supported

[Willem Broekema]

On Sat, Jan 17, 2009 at 10:48 PM, Jason Nielsen <jdn at math.carleton.ca> wrote:
>> - Getting the shootout benchmark running
>> <http://shootout.alioth.debian.org/>. The result of the tests that can
>> be run is that CLPython performance is not bad, but CPython is on
>> average a bit faster.
>
> Interesting!  Do you think this is because most of the CPython code in the
> benchmark relies on library functions that are compiled C code?

Some of the shootout benchmarks say more about the Lisp implementation
than about CLPython: bintrees.py checks the speed of recursion and
consing; chameneos-redux.py check the speed of acquiring and releasing
process locks. But there are others that say more about Python
implementation speed.

Once the shootout files can be run on CLPython, I intend to add the
shootout files to the CLPython distribution, with a simple function to
run them and at the same time run them in CPython.

> Have you thought about adding optional types to CLPython (a.l.a. PEP 3107 in
> Python 3.0)?  If these expanded to type declarations in common lisp I think
> the performance could be improved significantly.... all speculation of
> course!

That PEP only introduces the concept of annotations, not the
semantics. And those semantics are not clear to me. For example, what
should it mean to say "x" is an "int"?

 - how many bits does it have?
 - does it overflow?
 - can it be an instance of a user-defined subclass of int?
 - can "x" is unbound at some point, causing a NameError?

This is also what I dislike about Cython: instead of basing numeric
declarations on C number types, it would be so much more portable and
smart to declare the range of the values: x is in (0 .. whatever).


If anyone feels the urge to aid in development, please take a look at
the Python standard library, take one implemented in C, and try to
convert that to Lisp. In clpython/lib/ is a start.

Cheers,
- Willem