Lisp is slow (NOT!) #2
Wednesday, March 10, 2004
The other day, I recounted a story about how some lispers on c.l.l. took up a troll on his challenge to show that Lisp code could run as quickly as C++ code on a given benchmark. Toward the end of the thread, a comment was made that the resulting CL program (although it did meet the challenge) didn't really show off any of the real benefits of using CL. Will Hartung disagreed and explained why both the code and the process that was followed by the lispers did show off some of the benefits of using Common Lisp:
"I think it did show some of the benefits of CL. You'll note that this started with what was a trivial hand conversion of the C++ program.Pascal Bourguignon pointed out a CL approach that could have been used to create (potentially) code that was far faster than the simple C++ -> CL conversion that was done:
Once that was done, a lot of the overall program remained the same, with many of the speed ups happening not within the code itself directly, but abstractly through macros defined on the outside.
While at some point a bug was introduced (it may well have been there from the beginning, I don't recall), it went on to show that something like this could have easily been isolated in a larger program, placed into its own sandbox for safety and and hammered on to get the desired affect.
You'll note that early on there was little presumption over redefining basic pieces like +, -, /, and * in order to facilitate optimizing the system. We changed from 2-D arrays to 1-D arrays with little changes to either the array defiinitions or the array access!
It also showed how we can specify type ranges, and how the compilers can act upon them to make any potential improvements. These are semantics that can't even be communicated in other environments (some yes, but certainly not all).
It also showed that CL using certain implementations can get down pretty close to the metal. The beauty of course is that typically in most programs, you do not have to optimize that far. Yet, after all of that, the actual code used to get down to the metal is at face value no different from other general, safer code (the macros shrouded those details).
Finally, with a minor change of the declaim statement, all of the safety that comes with CL comes back in the blink of a re-compile, so if the algorithm is not completely thought out or starts misbehaving, that can all be turned back on and the algorithm debugged (assuming, of course, that the bug is in the algorithm and not the compiler).
So, I think this is a stellar example of the capabilities of CL."
"An obvious 'optimization' would be to denote the program in a way leading to parallel execution. In a true lisp re-implementation, there would be no loops in planetpv. All processing would be expressed globally with macros that would generate code either for a single processor, or for a threaded multiprocessor, or for a parallel machine, or perhaps using vector instructions. Of course, the "naive" implementation mapping directly these macros to loops would not be faster than the C++ version, but by just implementing these macros with vectorial instructions, we could easily get a Lisp program ten times faster than any C++ implementation."Will Hartung made a very nice comment in one of his posts - this is a good one to conclude this with:
"Well, of course, that's the other benefit of CL. In CL we can write C programs, but you can't write CL programs in C :-)."
