4 ms·

The question should be: if you want speed, is it really worth using lisp? Maybe your time would be better spent writing a c module and then interfacing with the

The question should be: if you want speed, is it really worth using lisp? Maybe your time would be better spent writing a c module and then interfacing with the lisp interpreter. I'm no lisp hater, it's a great language that offers some neat abstractions. But to really optimize code, you have to be intimately familiar with how data structures are implemented within the interpreter. You can avoid this problem by using C.

herdrick 19y ago
Actually you're likely to write slower code if you start with C, instead of starting with a high level language and then after finding out what is too slow, writing those parts in C. Except it won't be too slow. Especially if you use one of the popular implementations of Common Lisp or Scheme. They're pretty fast. More to the point, you're killing yourself on productivity if you are approaching things from a performance-central perspective. My advice to you is to forget C.
- marketer 19y ago
  It's sometimes difficult to fix performance issues in your app unless you know what's causing the slow-down in the interpreter, but that's usually a pain. Lisp is a constructive language, so a lot of time is spent doing memory allocation. Interpreters often optimize that by pre-allocation and such, but to diagnose that you need to know exactly when memory is allocated, etc.. AN example: I was using the python heap module to implement a priority queue with several hundred thousand values. The memory allocation caused by the dynamic growth of the list was crippling the performance. I re-implemented it as a binary heap in C, and it was asymptotically faster.
  - ecuzzillo 19y ago
    Lisp is compiled, not interpreted, most of the time. No one uses interpreted Lisp in production; it's all compiled. And it's compiled to very fast code, much of the time, particularly when you add type declarations.
  - shiro 19y ago
    You're half right. Tuned Lisp code can be as fast as C, but you have to know the compiler so intimately that you can tell what kind of machine insturctions it is generating; you'll use "disassemble" a lot ("disassemble" is a part of CommonLisp standard---you may get a sense how Lispers are performance freak). Usually the bottleneck part is tuned to the point that it won't do any allocation and run-time type dispatch at all. There's one big advantage of using Lisp over C for performance: Macros. During optimization it is typical that you have to write several versions of code, changing bits and pieces, and run benchmarks to see what is optimal. Macros allow you to generate different versions of code from simple changes of parameters, without incurring overhead of function call/variable reference etc. (You can do similar thing in C++ templates, but Lisp macros allows much more). If you can easily parameterize your code, you can try more ideas and run more benchmarks, so it is more likely that you'll find better optimization. AN example: Allegro CL version 7 and later has Perl-compatible regular expression library, purely written in Lisp, that runs faster than Perl (at least at the moment I wrote it, using benchmark suite came with PCRE).

herdrick 19y ago

Actually you're likely to write slower code if you start with C, instead of starting with a high level language and then after finding out what is too slow, writing those parts in C. Except it won't be too slow. Especially if you use one of the popular implementations of Common Lisp or Scheme. They're pretty fast. More to the point, you're killing yourself on productivity if you are approaching things from a performance-central perspective. My advice to you is to forget C.

marketer 19y ago
It's sometimes difficult to fix performance issues in your app unless you know what's causing the slow-down in the interpreter, but that's usually a pain. Lisp is a constructive language, so a lot of time is spent doing memory allocation. Interpreters often optimize that by pre-allocation and such, but to diagnose that you need to know exactly when memory is allocated, etc.. AN example: I was using the python heap module to implement a priority queue with several hundred thousand values. The memory allocation caused by the dynamic growth of the list was crippling the performance. I re-implemented it as a binary heap in C, and it was asymptotically faster.
- ecuzzillo 19y ago
  Lisp is compiled, not interpreted, most of the time. No one uses interpreted Lisp in production; it's all compiled. And it's compiled to very fast code, much of the time, particularly when you add type declarations.
- shiro 19y ago
  You're half right. Tuned Lisp code can be as fast as C, but you have to know the compiler so intimately that you can tell what kind of machine insturctions it is generating; you'll use "disassemble" a lot ("disassemble" is a part of CommonLisp standard---you may get a sense how Lispers are performance freak). Usually the bottleneck part is tuned to the point that it won't do any allocation and run-time type dispatch at all. There's one big advantage of using Lisp over C for performance: Macros. During optimization it is typical that you have to write several versions of code, changing bits and pieces, and run benchmarks to see what is optimal. Macros allow you to generate different versions of code from simple changes of parameters, without incurring overhead of function call/variable reference etc. (You can do similar thing in C++ templates, but Lisp macros allows much more). If you can easily parameterize your code, you can try more ideas and run more benchmarks, so it is more likely that you'll find better optimization. AN example: Allegro CL version 7 and later has Perl-compatible regular expression library, purely written in Lisp, that runs faster than Perl (at least at the moment I wrote it, using benchmark suite came with PCRE).