[Ecls-list] more about Maxima + ECL

Juan Jose Garcia-Ripoll jjgarcia at users.sourceforge.net
Tue Apr 29 07:32:23 UTC 2008


On Mon, Apr 28, 2008 at 7:12 PM, Robert Dodier <robert.dodier at gmail.com> wrote:
> On Mon, Apr 28, 2008 at 7:14 AM, Juan Jose Garcia-Ripoll
>  <jjgarcia at users.sourceforge.net>
>  >  An implementation might be slow at running Maxima, and not so slow at
>  >  other things.
>
>  That's speculation, isn't it? Or do you know of existing programs
>  for which ECL is faster than other implementations?

It has been so in the past with several test suites. I am no longer
sure, as development has moved on and I have not cared so much about
performance, for the list of things to implement was already vast
enough. In my experience, when something went terribly slow, it was
usually just  a small bottleneck -- like method dispatch, which pretty
printer relies so much on --. I am more than willing to solve such
bottlenecks.

>  > AFAIK, GCL has been tuned for years to run this program,
>
>  That is not so. Also, other implementations (SBCL, CMUCL) run Maxima
>  at speeds comparable to GCL. These are the results of general speed
>  improvements, which benefit all programs.

Indeed, but my argument is that GCL was the host of the Maxima
implementation, since its maintainer (William Schelter) was also the
maintainer of Maxima. I was for a long time a subscriber of the GCL
mailing list and they received feedback from both Maxima and Axiom
regarding performance and correctness of their code. Don't you think
this makes a difference?

But please, let's not go down this route. I have had enough of Richard
Fateman's hate mail these two days, in which he talks in a nazi like
way about inferior and superior implementations and that some should
be eliminated so as not to preclude the development of others. Makes
me sick. And it is something I definitely do not need.

Juanjo

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




More information about the ecl-devel mailing list