<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi, Andrew. Hi, Andrew. I think that I cannot answer your question, because I never understood how Lisp can be so fast. SBCL looks like Matlab or Python, but it is much faster. In fact, it beats C, if one uses a lot of data structures, pass functions around and build and eval expressions. In "When Lisp is fasten than C", Genetic and Evolutionary Computations, 2006, Svingen claims that Lisp is so fast because it compiles expressions on the fly. My question is: Why Python or Matlab cannot do the same? Soon after I started college two years ago, I learned to program in a language called Clean (it is the first language people learn in the small college where I study). Since I got good grades, I received a scholarship. My duties are to help people evaluate programs that solve certain engineering problems (climate change monitoring, medical signal processing, energy quality, etc.) In these fields, people use a lot of genetic programming, maximum entropy method, neural network, etc. I have seen problems that take days in Matlab and Python, hours in Ocaml and C, and are solved in minutes in SBCL or CMUCL. In one occasion, a problem took two days and a half in Matlab, and 9 minutes in SBCL+Maxima. In another example, a report generator took less than 10 seconds in CMUCL, and twenty minutes in Java. The boss couldn't believe in such a result, and examined the Java program line by line, looking for a flaw. The CMUCL version of the program should be a prototype; the idea is that the customer would receive a better and faster version in Java. Well, the customer decided to stick with the Lisp version, notwithstanding the difficulty of maintenance. As I told you, I really don't know why Lisp, having a feel of an interpreted language, can be so fast, almost as fast as batch compiled languages. I also don't understand why Python cannot have a compiler that generates code as fast as SBCL. Why Python compiler writers don't examine the SBCL code, and do something similar? In any case, I wrote a report on the speed of Lisp, and here are my hypothesis: 1 --- Lisp may attract better programmers. This means that Lisp code may be better than Python code, for instance. This include compilers. While people who work with Lisp can build very good incremental compilers that make one feel that he is working with an interpreter, and Python programmers don't? 2 --- It seems that Lisp is around a long time. Lisp compiler writers had time to write very good optimizers and incremental compilers. 3 --- Lisp may be very good for certain kinds of problems, like number crunching, computer algebra, and optimizing incremental compilers. By the way, I am not a Lisp programmer, and don't appreciate Lisp. In fact, I am trying to beat Lisp using languages like Clean and JHC. If you want to visit my page, here is the address where I describe my work: http://www.discenda.org/med/ My problem in beating Lisp is that most programs I am working with build expressions and eval them, and have a lot of occasion for parallelism. Clean and JHC don't have an eval function, i.e., I cannot build and function, compile it on the fly, and eval it; to be fair, Clean has dynamic link, which helps, but it is not as simple to use as SBCL eval. Besides this, parallel algorithms are much easier in Lisp than in Clean or JHC. Well, it is easy to program parallel algorithms in GHC, but GHC is much slower than JHC. You must understand that while Will Roger can distribute his Bigloo program in one hundred machines, all I have is a machine with two quadricore processors. Besides this, Bigloo is much faster than GHC. I believe that JHC is faster than Bigloo, but it does not have parallel processing. My theory is that Lisp compilers are so good (SBCL and CMUCL) because Lisp attracts fanatics :-) However, Clean, JHC and Haskell also attracts fanatics. Therefore, in a near future, these languages may have incremental compilers as fast as SBCL. Clean and Haskell (JHC) beats Lisp in one aspect. A genetic programming system that compiled into 52m of SBCL generated code, compiles in less than 2m of JHC generated code. Besides this, JHC code is only 4 times slower than the equivalent SBCL code. --- On Tue, 11/10/09, Andrew Reilly <areilly@bigpond.net.au> wrote: <blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> From: Andrew Reilly <areilly@bigpond.net.au> Subject: Re: [plt-scheme] Re: Poacher turned gamekeeper To: "Philippos Apolinarius" <phi500ac@yahoo.ca> Cc: plt-scheme@list.cs.brown.edu Received: Tuesday, November 10, 2009, 4:19 PM <div class="plainMail">On Tue, Nov 10, 2009 at 05:27:46AM -0800, Philippos Apolinarius wrote: > I often wonder why all Schemes don't have something like > Gambit-C SIX syntax. PLT has Honu (and Algol).  Check it out at the bottom of the help desk. > After all, the the traditional syntax > would still be available, if one needs or prefer it. One needs > the traditional syntax to do things like genetic programming, > neural networks or macros. I'm curious about why you would think this.  Scheme (like other lisps) is defined in terms of the parsed AST, not the source syntax.  It works just the same with whatever syntax you use. I'm doubly curious why you would regard genetic programming and neural networks as special classes of algorithm, and put them in the same category as macros?  I've used both, in C, many years ago.  What's changed in the last fifteen years to make s-expression syntax a critical factor now? Cheers, -- Andrew </div></blockquote></td></tr></table> <hr size=1>The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo! <a href="http://downloads.yahoo.com/ca/internetexplorer/">Get it Now for Free!</a>