[Ecls-list] Latest changes

[Juan Jose Garcia-Ripoll]

Available in CVS ((CVS 2008-05-29 20:53))

- The compiler now users compiler macros to optimize COERCE.

- The optimizers for TYPEP are also improved.

- GENTEMP/GENSYM use the printer to create the symbols. If the user
set *PRINT-CIRCLE* to T, that would cause a very inefficient way of
generating these symbols to be used. Instead we now use raw printing
routines without circular detection.

- MAKE-ARRAY/VECTOR now use the same internal routine and cons less.

- Specialized coercion routines for lists and sequences allow for open
coding those COERCE cases.

The overall result is a huge speed gain in some cases. It is funny
that, as I expected and repeated several times, the performance
bottlenecks are rather simple parts of the code.The GENTEMP/GENSYM
issue, for instance, was a major source of consing due to that stupid
"mistake".

I already have identified other candidates for improvement. For
instance, the routines that deal with the interpreter stack are now
functions with a lot of paranoid security checks. This can be relaxed
and open coded using either macros or GCC's inline functions. This is
sort of a must for improving the speed of interpreted code.

The only difficulty that I face is that profiling a program such as
ECL, with very deep stack traces, and functions that call a lot of
other functions is complicated. The platform that behaves best in that
respect is OS X, where the Shark profiler works extremely well and
points out very accurately the run times of many functions. Linux +
gprof has been rather disappointing, though. The only drawback of
Shark is that it is rather limited in the amount of time that it can
monitor a program. 60s produces a huge image, 100s is close to the
limits of my laptop.

Well, back to coding.

Juanjo

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