This is typical for papers like this: take a toy algorithm, show it's kinda as fast as C/Fortran if you do something really odd, then declare victory. This works better if your C compiler lacks important optimizations, like a loop nest optimizer.
If you really want to impress people, take a significant algorithm, preferably one of the SPECcpu benchmarks, write the whole thing in Lisp, and then see what happens.
>It's not just Lisp. Language advocates are the snake oil salesmen among computer scientists.
It's true. (-: I submitted the paper mostly because it's a condensed "how-to" for optimizing Common Lisp code. I think the name of the paper itself is really, really sketchy.
I admit to not having read the paper all the way through, but Figure 2 only shows Common Lisp as being noticeably faster than C in one instance, and I suspect that's due to an anomaly of some kind (it's totally out of line with the other C speeds).
The paper says that to get the speed they had to turn off run time type checking, but they say "here's how to do it globally" does that mean you can turn of type checking in just one module or function?
So you can basically wrap it around any S-expression you want.
When I was at ITA we did that a lot. For example, there was a macro i+ that would expand to basically "the two arguments are fixnums, as is the result. Now, please give me the sum."
In debug builds, the type declarations would be come assertions. In release builds, they'd become assumptions, i.e. the whole thing would compile to a single x64 ADD instruction.
Why is the scribd version 1) ugly and 2) in Flash? I thought they were all HTML 5 these days, and I'd clicked the scribd link to give them another chance.
If you really want to impress people, take a significant algorithm, preferably one of the SPECcpu benchmarks, write the whole thing in Lisp, and then see what happens.