Name: Anonymous 2009-06-21 15:30
How about a flamewar on this topic in honor of Erik?
* chu...@best.com (Chuck Fry)
| Modern Common Lisp compilers allow me to tune the critical parts of my
| code to within a few percent of C code, but without the pain of using a
| fragile, brittle quasi-portable assembly language.
just for the heck of it: I have tuned a _very_ CPU-heavy function I wrote
in Common Lisp over a year ago so it went from the unsatisfactory 623 µs
per call to the very pleasant 4.7 µs per call.
the strictly equivalent C function that people are entirely _satisfied_
with, performance-wise, takes 92 µs per call. very frequently, I find
that Common Lisp allows me to experiment with algorithms so much faster
than I can in C and the like, so I can change methodology and approach as
fast as they can do another optimization attempt. this means that a good
Common Lisp programmer can find the optimal algorithm _and_ the optimal
implementation in less time than the C programmer can find the optimal
implementation.
the C mind-set is that C is fast. this is even less true than their idea
that CL is slow. writing really fast C code is _incredibly_ hard, and
you might as well write it in assembly after you have seen what the
compiler is doing to the overall code. I have squeezed the last drop of
blood out of many a CPU in my time, but never has it been easier to do it
than with Allegro CL with its instruction-level profiler, hackable LAP
code (thanks, Duane!), and code transformation with compiler macros (a
standard CL facility). this stuff just isn't available to C programmers.
if you can't outperform C in CL, you're too good at C.
#:Erik
* chu...@best.com (Chuck Fry)
| Modern Common Lisp compilers allow me to tune the critical parts of my
| code to within a few percent of C code, but without the pain of using a
| fragile, brittle quasi-portable assembly language.
just for the heck of it: I have tuned a _very_ CPU-heavy function I wrote
in Common Lisp over a year ago so it went from the unsatisfactory 623 µs
per call to the very pleasant 4.7 µs per call.
the strictly equivalent C function that people are entirely _satisfied_
with, performance-wise, takes 92 µs per call. very frequently, I find
that Common Lisp allows me to experiment with algorithms so much faster
than I can in C and the like, so I can change methodology and approach as
fast as they can do another optimization attempt. this means that a good
Common Lisp programmer can find the optimal algorithm _and_ the optimal
implementation in less time than the C programmer can find the optimal
implementation.
the C mind-set is that C is fast. this is even less true than their idea
that CL is slow. writing really fast C code is _incredibly_ hard, and
you might as well write it in assembly after you have seen what the
compiler is doing to the overall code. I have squeezed the last drop of
blood out of many a CPU in my time, but never has it been easier to do it
than with Allegro CL with its instruction-level profiler, hackable LAP
code (thanks, Duane!), and code transformation with compiler macros (a
standard CL facility). this stuff just isn't available to C programmers.
if you can't outperform C in CL, you're too good at C.
#:Erik