3 ms·

As someone new to Lisp. The following thing has always fascinated me. I've read some older posts on comp.lang.lisp and people insist on buying a 'high performan

by kamaal 8y ago

As someone new to Lisp. The following thing has always fascinated me. I've read some older posts on comp.lang.lisp and people insist on buying a 'high performant' Lisp. I think what they mean is Allegro CL or Franz Lisp. But why is it 'high performant' compared to other implementations? Like say CMU CL(now SBCL). For example, in this case why would one use Clozure CL instead of SBCL?

cbcoutinho 8y ago
SBCL [0] is a fork of CMU CL [1], and both are actively maintained projects. [0] https://gitlab.common-lisp.net/cmucl/cmucl https://gitlab.common-lisp.net/cmucl/cmucl [1] https://sourceforge.net/p/sbcl/sbcl/ci/master/tree/ https://sourceforge.net/p/sbcl/sbcl/ci/master/tree/
lisper 8y ago
> Allegro CL or Franz Lisp. Same thing. Franz is the company. Allegro Lisp is the product. Like "Apple Macintosh computer." > But why is it 'high performant' compared to other implementations? Like say CMU CL(now SBCL). Somewhat better compiler, but mainly lots of extra features (better debugging, graphics, better libraries). > why would one use Clozure CL instead of SBCL? I use CCL because 1) I like the IDE and 2) its compiler is fast so you can always compile everything essentially for free. In other CLs you have to choose between running in compiled or interpreted mode, and that can sometimes cause problems. CCL doesn't have an interpreter at all. It always compiles everything and that makes it easier to use.
- kamaal 8y ago
  What resources would you recommend one read to understand more about debugging facilities in Common Lisp?
  - lispm 8y ago
    See the LispWorks IDE user guide: http://www.lispworks.com/documentation/index.html http://www.lispworks.com/documentation/index.html
  - lmohseni 8y ago
    I have found this series of articles to be very helpful: http://malisper.me/debugging-lisp-part-1-recompilation/ http://malisper.me/debugging-lisp-part-1-recompilation/
  - lisper 8y ago
    Debugging facilities are not standardized so you'd need to consult the documentation for whatever implementation you are using. e.g.: https://franz.com/support/documentation/10.1/doc/debugging.htm https://franz.com/support/documentation/10.1/doc/debugging.h... http://www.sbcl.org/manual/#Debugger http://www.sbcl.org/manual/#Debugger
  - vindarel 8y ago
    In [Successful Lisp, how to understand and use CL](http://www.communitypicks.com/r/lisp/s/17592186045679-successful-lisp-how-to-understand-and-use-common http://www.communitypicks.com/r/lisp/s/17592186045679-succes...) there is a chapter on debugging. Book's site, free dl: https://successful-lisp.blogspot.com https://successful-lisp.blogspot.com Also, it may not be necessary to master the most complicated machinery: compiling function by function gives lots of hints, and the very nice [log4cl](https://github.com/sharplispers/log4cl/ https://github.com/sharplispers/log4cl/) is handy.
- xenophonf 8y ago
  I'm pretty sure SBCL compiles everything too. From "Compiler-only Implementation," section 2.3.3 (page 14) of the user manual (http://sbcl.org/manual/sbcl.pdf http://sbcl.org/manual/sbcl.pdf): SBCL is essentially a compiler-only implementation of Common Lisp. That is, for all but a few special cases, eval creates a lambda expression, calls compile on the lambda expression to create a compiled function, and then calls funcall on the resulting function object. A more traditional interpreter is also available on default builds; it is usually only called internally. This is explicitly allowed by the ANSI standard, but leads to some oddities; e.g. at default settings, functionp and compiled-function-p are equivalent, and they collapse into the same function when SBCL is built without the interpreter.
  - TeMPOraL 8y ago
    It does by default, though technically, it has an interpreter available if you need it - see http://www.sbcl.org/manual/#Interpreter http://www.sbcl.org/manual/#Interpreter.
- aidenn0 8y ago
  Actually Franz Lisp is a pre-common lisp used primarily with BSD on vaxen. http://www.softwarepreservation.org/projects/LISP/maclisp_family/#Franz_Lisp_ http://www.softwarepreservation.org/projects/LISP/maclisp_fa...
  - housel 8y ago
    ... and M68k Sun workstations, and the CCI Tahoe, which was a late-80s Vax clone with about 6x the speed. (I did the port to the Tahoe as an undergraduate.)
- flavio81 8y ago
  >I use CCL because 1) I like the IDE and 2) its compiler is fast so you can always compile everything essentially for free. Just to add to the above, I like CCL because it gives nice compiler messages --sometimes it warns me about things SBCL won't notice.
lispm 8y ago
Franz Lisp does not exist anymore. It was a dialect like Maclisp at that time. It has been replaced three decades ago with Allegro CL - by Franz, Inc.. The 'fast' Lisps are often the native Lisps (SBCL, Clozure CL, Allegro CL, LispWorks, Lucid CL, ...). For selected applications some implementations were more specialized (for example GCL with fast numerics for Maxima)... SBCL has the advantage of some more advanced type handling. But fast isn't just low-level benchmarks. It might mean fast for a certain application. For example on the Deep Space One spaceship the application was deployed with LispWorks (and not OpenMCL/Clozure CL) because LispWorks had the best GC (soft realtime) and could be running on a hardened PowerPC processor on a real-time OS. And 'fast' in Lisp is also important for mostly unoptimized, but compiled, code with full runtime checks and lots of flexibility. Stuff which would be 'full debug' mode in C++. For example the typical Lisp Machine OS could run in a full development mode without much runtime speed penalty - just lots of space penalty. It still had to deal with the window system (written in Lisp), disk access (written in Lisp), interrupt handler and scheduler (written in Lisp) ... Is that 'fast' enough for the interactive user? Benchmark-wise the system might be slow, but it might perform well for applications running multiple threads and lots of interrupts. Imagine your application is a CAD system written in Common Lisp with CLOS (there are and were a bunch of those). It might need a large address space and zillions of CLOS objects. Will it run fast enough for interactive 3d workloads? How fast is the GC? How fast is the CLOS implementation? How does it deal with FFI operations into OpenGL... Stuff like that had been developed with Lucid CL and Allegro CL. At a time when CMUCL still was printing GC messages to the terminal... Nowadays a lot of machines are "fast enough" and have lots of memory. But when one needed a 64bit SGI for a demanding application, Allegro CL was the thing to use. I think the IDE for Crash Bandicoot was Allegro CL on an SGI. Later similar graphics applications in Lisp ould also run on large Windows NT machines with faster graphics cards. Today Allegro CL is also the only CL one I know, which has a partly parallel GC - a demanding application like their database and knowledge-bases drives the need for faster runtimes. Lucid CL no longer exists (though LispWorks provided support for it), but it had a compilation mode for full-program compilation, which enabled good runtime performance. Many commercial applications had been deployed with it - until the company went away - after investing lots of money into an advanced C++ IDE which did not fly on the market. With something like LispWorks and Allegro CL one can develop normal-looking and fast applications for the desktop - stuff which feels much less sluggish than your typical Java desktop application and has useful interactive performance.
patrec 8y ago
Not just Allegro, from what I read, Lispworks is also noticeably faster then SBCL (you might be able to find some comparisons for a practical system by googling for elPrep, which is now written in Go but used to be Common Lisp and ran on both Lispworks and SBCL). Concerning the appeal of Clozure CL, I think people have traditionally used it for faster dev turnaround due to better compilation speed than SBCL (which in turn typically generated faster code).
- lispm 8y ago
  For some reason ITA (now at Google) had people who advocated moving from SBCL to CCL for their application(s).
  - wglb 8y ago
    I recall reading that the speed of compilation was a big issue for them with the size of their application.
    - patrec 8y ago
      Yes, I recall that they were using Clozure for dev and SBCL for production because of that at some point.
abc_lisper 8y ago
Hi kamaal, it’s nice to see you interested in cl. I don’t know if you remember this but we sparred a couple of times on HN few years ago. I have been on this path before and happily settled on clojure for a few years now. I don’t know if it applies to all cls, but what nobody told me was how little I have to worry about when writing code in clojure. I stopped paying attention most of the Language and instead spend time on solving the actual problem. It is very liberating. See the talk “simple made easy” by rich hickey if you haven’t already. Also most psychological and process incl. debugging barriers come down when using clojure
- kamaal 8y ago
  >>I don’t know if you remember this but we sparred a couple of times on HN few years ago. Hey, I apologize if that was something that hurt you in anyway. I discovered Lisp a few months back, I had of course heard of it long back, but kind of discovered using it only months back. I don't code in Lisp at day job or full time. But many of my problems related to understand data structures and algorithms have vanished since I started thinking of them in Lisp. Mostly because I started to think in terms of recursion well, and other list manipulation stuff feels like it just comes to naturally. Not sure why this, or its unique to me. But for some reason I find it very easy to think and work with trees and graphs when I think of them as lists. Always looking forward to learn and do more.
  - abc_lisper 8y ago
    No it was cool :) Yeah, most of incidental complexity vanished away once I start using clojure. Lisp is pretty cool in that there is very little to learn in way of syntax and ceremony. If you are new to functional programming, I suggest understanding reduce well. Understanding it forms the basis of higher order functions. Also half of clojure core is implemented with reduce. Also, I highly suggest watching the talk “simple made easy”. One hour of time spent there pays off in many many months/years
blihp 8y ago
If by 'older posts' you mean early 2000's and prior, the open source Lisps weren't as many or as good as they are today. CCL is open source (back then it was closed source under the MCL banner), SBCL didn't exist in it's current form (that was announced in 1999) etc. In general, each decade back you go, think of whatever open source software that even existed as being significantly less powerful, performant and buggier. Many open source projects (esp. the GUI applications) started life as bad imitations of not much better commercial software vs. what you're used to seeing today. And to top it off, you were running it on radically less powerful hardware (in the early 90's you could still watch windows on the screen being redrawn on 'high end' hardware) so any software performance issues you had were magnified by the systems you were running on.

by kamaal 8y ago

cbcoutinho 8y ago

SBCL [0] is a fork of CMU CL [1], and both are actively maintained projects. [0] https://gitlab.common-lisp.net/cmucl/cmucl https://gitlab.common-lisp.net/cmucl/cmucl [1] https://sourceforge.net/p/sbcl/sbcl/ci/master/tree/ https://sourceforge.net/p/sbcl/sbcl/ci/master/tree/

lisper 8y ago

> Allegro CL or Franz Lisp. Same thing. Franz is the company. Allegro Lisp is the product. Like "Apple Macintosh computer." > But why is it 'high performant' compared to other implementations? Like say CMU CL(now SBCL). Somewhat better compiler, but mainly lots of extra features (better debugging, graphics, better libraries). > why would one use Clozure CL instead of SBCL? I use CCL because 1) I like the IDE and 2) its compiler is fast so you can always compile everything essentially for free. In other CLs you have to choose between running in compiled or interpreted mode, and that can sometimes cause problems. CCL doesn't have an interpreter at all. It always compiles everything and that makes it easier to use.

kamaal 8y ago
What resources would you recommend one read to understand more about debugging facilities in Common Lisp?
- lispm 8y ago
  See the LispWorks IDE user guide: http://www.lispworks.com/documentation/index.html http://www.lispworks.com/documentation/index.html
- lmohseni 8y ago
  I have found this series of articles to be very helpful: http://malisper.me/debugging-lisp-part-1-recompilation/ http://malisper.me/debugging-lisp-part-1-recompilation/
- lisper 8y ago
  Debugging facilities are not standardized so you'd need to consult the documentation for whatever implementation you are using. e.g.: https://franz.com/support/documentation/10.1/doc/debugging.htm https://franz.com/support/documentation/10.1/doc/debugging.h... http://www.sbcl.org/manual/#Debugger http://www.sbcl.org/manual/#Debugger
- vindarel 8y ago
  In [Successful Lisp, how to understand and use CL](http://www.communitypicks.com/r/lisp/s/17592186045679-successful-lisp-how-to-understand-and-use-common http://www.communitypicks.com/r/lisp/s/17592186045679-succes...) there is a chapter on debugging. Book's site, free dl: https://successful-lisp.blogspot.com https://successful-lisp.blogspot.com Also, it may not be necessary to master the most complicated machinery: compiling function by function gives lots of hints, and the very nice [log4cl](https://github.com/sharplispers/log4cl/ https://github.com/sharplispers/log4cl/) is handy.
xenophonf 8y ago
I'm pretty sure SBCL compiles everything too. From "Compiler-only Implementation," section 2.3.3 (page 14) of the user manual (http://sbcl.org/manual/sbcl.pdf http://sbcl.org/manual/sbcl.pdf): SBCL is essentially a compiler-only implementation of Common Lisp. That is, for all but a few special cases, eval creates a lambda expression, calls compile on the lambda expression to create a compiled function, and then calls funcall on the resulting function object. A more traditional interpreter is also available on default builds; it is usually only called internally. This is explicitly allowed by the ANSI standard, but leads to some oddities; e.g. at default settings, functionp and compiled-function-p are equivalent, and they collapse into the same function when SBCL is built without the interpreter.
- TeMPOraL 8y ago
  It does by default, though technically, it has an interpreter available if you need it - see http://www.sbcl.org/manual/#Interpreter http://www.sbcl.org/manual/#Interpreter.
aidenn0 8y ago
Actually Franz Lisp is a pre-common lisp used primarily with BSD on vaxen. http://www.softwarepreservation.org/projects/LISP/maclisp_family/#Franz_Lisp_ http://www.softwarepreservation.org/projects/LISP/maclisp_fa...
- housel 8y ago
  ... and M68k Sun workstations, and the CCI Tahoe, which was a late-80s Vax clone with about 6x the speed. (I did the port to the Tahoe as an undergraduate.)
flavio81 8y ago
>I use CCL because 1) I like the IDE and 2) its compiler is fast so you can always compile everything essentially for free. Just to add to the above, I like CCL because it gives nice compiler messages --sometimes it warns me about things SBCL won't notice.

lispm 8y ago

Franz Lisp does not exist anymore. It was a dialect like Maclisp at that time. It has been replaced three decades ago with Allegro CL - by Franz, Inc.. The 'fast' Lisps are often the native Lisps (SBCL, Clozure CL, Allegro CL, LispWorks, Lucid CL, ...). For selected applications some implementations were more specialized (for example GCL with fast numerics for Maxima)... SBCL has the advantage of some more advanced type handling. But fast isn't just low-level benchmarks. It might mean fast for a certain application. For example on the Deep Space One spaceship the application was deployed with LispWorks (and not OpenMCL/Clozure CL) because LispWorks had the best GC (soft realtime) and could be running on a hardened PowerPC processor on a real-time OS. And 'fast' in Lisp is also important for mostly unoptimized, but compiled, code with full runtime checks and lots of flexibility. Stuff which would be 'full debug' mode in C++. For example the typical Lisp Machine OS could run in a full development mode without much runtime speed penalty - just lots of space penalty. It still had to deal with the window system (written in Lisp), disk access (written in Lisp), interrupt handler and scheduler (written in Lisp) ... Is that 'fast' enough for the interactive user? Benchmark-wise the system might be slow, but it might perform well for applications running multiple threads and lots of interrupts. Imagine your application is a CAD system written in Common Lisp with CLOS (there are and were a bunch of those). It might need a large address space and zillions of CLOS objects. Will it run fast enough for interactive 3d workloads? How fast is the GC? How fast is the CLOS implementation? How does it deal with FFI operations into OpenGL... Stuff like that had been developed with Lucid CL and Allegro CL. At a time when CMUCL still was printing GC messages to the terminal... Nowadays a lot of machines are "fast enough" and have lots of memory. But when one needed a 64bit SGI for a demanding application, Allegro CL was the thing to use. I think the IDE for Crash Bandicoot was Allegro CL on an SGI. Later similar graphics applications in Lisp ould also run on large Windows NT machines with faster graphics cards. Today Allegro CL is also the only CL one I know, which has a partly parallel GC - a demanding application like their database and knowledge-bases drives the need for faster runtimes. Lucid CL no longer exists (though LispWorks provided support for it), but it had a compilation mode for full-program compilation, which enabled good runtime performance. Many commercial applications had been deployed with it - until the company went away - after investing lots of money into an advanced C++ IDE which did not fly on the market. With something like LispWorks and Allegro CL one can develop normal-looking and fast applications for the desktop - stuff which feels much less sluggish than your typical Java desktop application and has useful interactive performance.

patrec 8y ago

Not just Allegro, from what I read, Lispworks is also noticeably faster then SBCL (you might be able to find some comparisons for a practical system by googling for elPrep, which is now written in Go but used to be Common Lisp and ran on both Lispworks and SBCL). Concerning the appeal of Clozure CL, I think people have traditionally used it for faster dev turnaround due to better compilation speed than SBCL (which in turn typically generated faster code).

lispm 8y ago
For some reason ITA (now at Google) had people who advocated moving from SBCL to CCL for their application(s).
- wglb 8y ago
  I recall reading that the speed of compilation was a big issue for them with the size of their application.
  - patrec 8y ago
    Yes, I recall that they were using Clozure for dev and SBCL for production because of that at some point.

abc_lisper 8y ago

Hi kamaal, it’s nice to see you interested in cl. I don’t know if you remember this but we sparred a couple of times on HN few years ago. I have been on this path before and happily settled on clojure for a few years now. I don’t know if it applies to all cls, but what nobody told me was how little I have to worry about when writing code in clojure. I stopped paying attention most of the Language and instead spend time on solving the actual problem. It is very liberating. See the talk “simple made easy” by rich hickey if you haven’t already. Also most psychological and process incl. debugging barriers come down when using clojure

kamaal 8y ago
>>I don’t know if you remember this but we sparred a couple of times on HN few years ago. Hey, I apologize if that was something that hurt you in anyway. I discovered Lisp a few months back, I had of course heard of it long back, but kind of discovered using it only months back. I don't code in Lisp at day job or full time. But many of my problems related to understand data structures and algorithms have vanished since I started thinking of them in Lisp. Mostly because I started to think in terms of recursion well, and other list manipulation stuff feels like it just comes to naturally. Not sure why this, or its unique to me. But for some reason I find it very easy to think and work with trees and graphs when I think of them as lists. Always looking forward to learn and do more.
- abc_lisper 8y ago
  No it was cool :) Yeah, most of incidental complexity vanished away once I start using clojure. Lisp is pretty cool in that there is very little to learn in way of syntax and ceremony. If you are new to functional programming, I suggest understanding reduce well. Understanding it forms the basis of higher order functions. Also half of clojure core is implemented with reduce. Also, I highly suggest watching the talk “simple made easy”. One hour of time spent there pays off in many many months/years

blihp 8y ago

If by 'older posts' you mean early 2000's and prior, the open source Lisps weren't as many or as good as they are today. CCL is open source (back then it was closed source under the MCL banner), SBCL didn't exist in it's current form (that was announced in 1999) etc. In general, each decade back you go, think of whatever open source software that even existed as being significantly less powerful, performant and buggier. Many open source projects (esp. the GUI applications) started life as bad imitations of not much better commercial software vs. what you're used to seeing today. And to top it off, you were running it on radically less powerful hardware (in the early 90's you could still watch windows on the screen being redrawn on 'high end' hardware) so any software performance issues you had were magnified by the systems you were running on.