more response to Juan.. > > * 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. .... --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
