Are you comparing the speed of optimized code to unoptimized code?

The algorithms were the same.

But... The C code probably ran 100 times faster than Lisp before I optimised it.

I take it you didn't bother with things such as optimization and type declaration in lisp.

Also great job on comparing what is essentially an interpreter to a compiler.

edit: http://www.cliki.net/Performance%20Benchmarks

Which Lisp?

(compiled) Clisp.

> (compiled) Clisp.

Clisp is only byte-compiled :-) So no, no way in bloody hell you beat CMUCL/SBCL by 1000 times.

No need to be hostile, I was just detailing my own experience, relevant to the article.

And it wasn't a totally unreasonable contribution, but it's important to keep in mind that if you compared CINT to SBCL, you'd probably conclude that Lisp is hundreds of times faster than C.

Here's such a comparison: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all...

I don't think it's hostile to point out that Clisp is only interpreted. It points out a flaw in your "C is faster" argument.

I wouldn't have been hostile if you attacked my family and loved ones. My development environment OTOH ..

What if your development environment is Emacs and GNU stuff is your family?? :S

I'm a lisp advocate and I don't have any problems with this.

You developed and optimized in lisp. I assume that you did so because that was the most productive way for you to do so. Then you decided to hand-compile to C because you needed more performance.

Maybe you could have gotten acceptable performance with a high-performance lisp implementation, maybe not. Regardless, the fact that you hand-compiled to C doesn't suggest that developing in C was a mistake.

I don't see why any lisp advocate would ever object to someone saying that developing in lisp was their best option.

I should know better, but I'll bite as well - were those Lisp programs, by chance, written as quick prototypes without any optimizations or by people who didn't really grok Lisp? Saying that "algorithms were the same" isn't terribly informative - after all, using the worn out factorial example, both the tail-optimized and stack-using versions of it would still use the same algorithm.

First off, 'by people who...' is me - I wrote this Lisp program. It was OCR software to turn images of text into ASCII.

I had read On Lisp and learned about macros, which I used heavily, and created a language to describe the elements of each character in macros - for instance, 'I' is typically a single vertical line.

So yes, I used some unique aspects of Lisp, and the port to C was done by basically transforming the untyped structures in the Lisp code, into C structs/datatypes. It wasn't a Greenspan law - it was just more declarations, and hand compiling I guess, which worked well in my C compiler, and better than the Lisp compilers I tried.

I hate replying so many times in a single thread, but you did ask! :-)

[Postscript] I used a good profiler which could tell me slow lines and functions. My speedups were entirely due to finding clever ways of optimising, thanks to the profiler. So that's the secret weapon...

Yes. Profiler is the secret weapon.

When I write optimized Lisp code, I heavily rely on the profiler of Allegro Common Lisp. Sometimes per-line or per-function isn't not fine enough and I go down to per-machine-instruction level profiling for the innermost loop, which is quite handy.

If you didn't use good profiler in your Lisp environment, well, you can't really compare performance of Lisp and C... (Unfortunately, there seems no such compiler that is clever enough to take quick-prototype Lisp code and emits fully-optimized code.)

I see. This is still anecdotal evidence, but now it's better than most, for what it's worth. While I think that a dedicated Lisp hacker could have done far better, without seeing the code in question this is all a moot point on both sides, really. Edit: Especially since it's not big news than non-optimized Lisp is slower than heavily-optimized C. ;)