[Ecls-list] cl-bench problem/oddity with latest ecls-cvs

[Juan Jose Garcia-Ripoll]

Dear Michael,

your project sounds very interesting. Indeed ECL seems very suited for
it. As for difficulties and limitations, I do not think there is
anything truly unsurmountable. You will find, however, that
performance can be improved.

- The interpreter does not yet have tail calls. They would make
recursive code much faster and more memory efficient

- There are multiple stacks: lisp stack, binding stack, frame
stacks,... They can probably be unified. This would also allow for a
larger level of recursion.

- The interpreter bytecodes are not yet optimally designed. There are
things to learn from Clisp here.

- The C compiler is still the least mature piece of code. We have to
precise and improve the behavior on different optimization levels and
do a more intesive testing using Paul Dietz's random function
generator.

- Fine tuning of the garbage collector. I believe there is a lot to be
gained here, if only by using the inlined allocation calls provided by
the Boehm-Weiser GC.

- Improvements in the CLOS code and structures code. They can be
probably unified and along the way implement structures with unboxed
data types. Dispatch can be improved severely, not really in terms of
correctness, but regarding efficiency.

- Files and streams. Long time ago someone offered help for
implementing a more efficient input/output mechanism, which supports
translations between different character codes.

...

Juanjo

-- 
Facultad de Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 28040 (Spain)
http://juanjose.garciaripoll.googlepages.com