> -----Original Message-----
> From: Juan Jose Garcia-Ripoll
> [mailto:juanjose.garciaripoll at googlemail.com]
> Sent: Monday, April 28, 2008 12:47 AM
> To: Michael.Abshoff
> Cc: fateman at EECS.Berkeley.EDU; fateman at EECS.Berkeley.EDU;
> sage-devel; Robert Dodier; maxima mailing list
> Subject: Re: [Maxima] [sage-devel] compiling Maxima by ECL
>
> Hi,
>
> let me first begin by saying that, as politely as I can, Fateman's
> email are as close to FUD as it can get. He doesn't seem to use ECL at
> all and just judges from some outdated webpages
If the web pages are out of date, why not remove them?
> and his own prejudices
> about different software libraries.
>
> Regarding the different points which have been raised:
>
> * GNU MP is only used for bignum computations. ECL itself is clever
> enough to handle fixnums cleverly and even to unbox fixnum
> computations in compiled code. Incidentally, GCL uses GMP as well, so
> I do not see the point all.
Thank you for this information. Unfortunately Michael said the sourceforge
page was mostly out of date and pointed me to
this: http://ecls.wiki.sourceforge.net/space/showimage/eclm2008.pdf
rather than some useful manual, which I just found via Google at
uh, sourceforge, the place I was told not to look. Thanks Michael.
http://ecls.sourceforge.net/new-manual/pr01s02.html
>
> * The simplistic garbage collector is an option and it is provided for
> platforms in which Boehm-Weiser does not run. Currently, this means
> _none_ of the supported platforms.
>
> * Boehm-Weiser is a strong garbage collector and a very powerful one
> in terms of tunability. You man make it as precise as you want, and
> the Java people indeed do. ECL uses it and it has seen only
> performance improvements as we have learnt more and more how to better
> use it. If the ANSI test suite shows something in that respect is
> that, under a lot of consing pressure, it does not perform that bad.
> It does not get so close to SBCL's but I doubt any other free
> implementation does.
It is my understanding that you are referring to an ANSI test suite which
is a conformance test, not an efficiency test. It is also not clear what
you mean by "strong" when it is pretty clear that GC has traditionally
been a problem with lisp until the deployment of better GCs.
>
> * ECL has a good compromise between all platforms.
This may be your view, but the benchmarks you offer show that it is
inferior to other lisps with the exception of one aspect, which is that
it is (alleged) to meet the SAGE criterion of easily compilable from
source. That is not to say that it cannot be made better, and perhaps
that will happen.
> It provides both C
> compiled code and a reasonably fast interpreter.
It seems to be the slowest of the two available (CLISP and ECL).
Perhaps that is reasonably fast. It is apparent from Maxima
tests that the interpreter and compiler are not entirely compatible
in some sense.
> Benchmark show that
> the ECL interpreter is not that far from interpreted CLISP. But on the
> other hadn CLISP has its own set of optimized bytecodes and when it
> compiles it optimizes for those bytecodes.
I don't understand this. Is it a criticism of CLISP? Why is it wrong for
CLISP
to have its own set of optimized bytecodes? Doesn't ECL have its own set of
bytecodes? If so, why are they not "optimized"? Whatever that means.
> AFAI remember, GCL used
> (and probably still uses) a list based interpreter which runs through
> forms represented as lists and macroexpanding every form that has to
> be done so, and every time it uses it. That is terribly inefficient.
That is traditionally how interpreters for Lisp work. It is however
different from the current practice in the building of large systems
in Lisp, in which almost everything is compiled. There are some Lisp
systems which compile each command line, which at a minimum, reduces
any discrepancy between interpreted and compiled code.
I suppose that coming from a background in compiling conventional
programming languages it seems odd to use a list based interpreter,
but that is not necessarily an advantage. Consider the debugging advantage
of actually interpreting the lisp lists as programs. Of course, after
the programs are debugged you might choose to speed them up by compiling.
>
> * In terms of maintainability it has shown through the years that it
> is easier for somebody to start coding and hacking ECL and adding new
> features than with most other platforms.
what other platforms are you are referring to. KCL?
> That is how we got ECL ported
> to the Microsoft compiler and platform and how different pieces of
> software (sockets, asdf, etc) have been adapted to run here. That by
> itself is an important value, at least for people who think long term.
>
> * Talking about diverting efforts from the GCL crowd, I am not the
> best person to speak about it. I am more than pissed of by the GCL
> community since, shortly after ECL reached most ANSI compliance and
> portability I was asked to port all that back to the GCL, because they
> wanted to achieve the same goal.
I do not have anything to do with that. I understand that GCL is not
ANSI compliant.
> That was back in '01 or '02, do not
> remember so well. What I remember is that those were not very polite
> emails and had a kind of "borg" spirit of assimilation, without even
> caring about the years spent on achieving that. So talk about
> diverting useful efforts.
Making GCL into an ANSI compliant Common Lisp would make it a better
host for Maxima, in some ways. It is speculative at best that improving
ECL will help Maxima. But you are of course free to spend your time
any way you wish.
> So, to the interested parties, if you so much care about Maxima
> running on just one computer, then stick to sbcl and cmucl which are
> pretty superior implementations, but please do not scare people from
> porting useful software to other platforms and environments.
My impression is that CMUCL and SBCL cannot run on Windows directly, which
makes GCL part of the Maxima world.