I am posting a reply of Juan here at his request: On Mon, Apr 28, 2008 at 4:25 PM, Richard Fateman <[EMAIL PROTECTED]> wrote: > > 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
What is the problem with that PDF? It contains accurate information. The web pages have some out of date regions, in particular around the manual introduction and details about the C compiler, because this manual organically evolved from EcoLisp's one. > > 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 What is the problem with this description? It is correct. The rest of the frontpage is as well: http://ecls.sourceforge.net/ ECL has a bytecodes interpreter, provides two different garbage collectors, implements a foreign function interface, etc, etc. > > > * 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. I refer to both. This test suite does all of the things that the Maxima compilation does, in terms of using COMPILE a lot and consing and destroying a lot of data as well. My experience is that this is also a stress test of the garbage collector, as the ANSI test suite may end up using close to a hundred Mb depending on the platform. And to this respect, the more we learn about the Boehm-Weiser GC the better these numbers (speed and consing) get. > > 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. Excuse my poor use of English, which is not my mother tongue, but by "strong" I meant both robust and well performing. Your statements also do not contradict mine: the fact that GC has been traditionally a weak point in implementations does not preclude the existence of a good GC library. > > 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. Which benchmarks? I have only seen the previous email about how ECL run 10x slower with the current build of Maxima. But to blame ECL alone is just as innocent as to say Maxima is the perfect software that should run anywhere unchanged. Different implementations may have different behavior and features. A port is rarely just load and run. And which sense of inferiority do you use. As mentioned before: "I understand that GCL is not ANSI compliant." Is this not an inferiority? I will stop discussing performance here, but anyone will understand the three following facts: - GCL has been traditionally the host of Maxima. As such, performance has been tuned in both programs so as to get it run well and fast. - Maxima expects a certain behavior of the common lisp. Namely, COMPILE has to be cheap. It should be possible to dump memory images. Running interpreted code is slow... - ECL has not exhausted its potential for speed up as it has not been a concern so far. But rather getting a better in the sense of maintainable, portable and standard implementation. I do not care whether Maxima is ported or not to ECL. I definitely would like to use it to see what performance bottlenecks there are and to see to what extent this is a problem of Maximas assumption on the lisp backend or to ECL's own limitations. But it seems you are having more fun making this a war of lisps. > > > 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. Why are you so picky? I just stated something everybody working with CLISP knows, which is that it has a lot of special purpose bytecodes to make bytecompiled code run fast. In ECL I chose to keep the set of bytecodes small so as to make the interpreter more easily maintainable and to to enforce people write certain kind of code for efficiency. > > 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. First, list interpreting is not such a weird experience for me. You should understand I have been working with Common lisp for over 10 years, most of it developing ECL, from the very first sources which did look a lot like GCL looks nowadays So my experience with list-based interpreters is not that of a C guy who is scared by all the lispy things. List based interpreters have serious speed issues, and also semantic issues, related to how changes in macros affect code. Besides list based debugging is not really that powerful. I have implemented stepper and debuggers using the ECL bytecodes and in my experience it has not been that painful. OTOH, having forms being bytecompiled provides a well defined semantics, which is not far away from that of ordinary compiled code. > > 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. Doesn't sound very encouraging. Really, it seems all this email exchange is just playing the scarecrow game: scare all possible innovation away. > > > 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. Ok, I must admit this is kind of mind twisting for me. First it was enough to have one computer and one compiler to run your software, now Windows is a requirement. This is my last email regarding this topic. If people are interested on seeing what ECL can do, feel free to contact me in the ECL mailing list. Juanjo -- Facultad de Fisicas, Universidad Complutense, Ciudad Universitaria s/n Madrid 28040 (Spain) http://juanjose.garciaripoll.googlepages.com --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
