11–18 of 18 posts
Earlier quoted context omitted.
> (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.
I also have written C programs which (with some basic optimisations) are 1000 (yes) times faster than the Lisp equivalent. Initially prototyped in Lisp, and the code ported over line-for-line to C.
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.
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...
Earlier quoted context omitted.
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…
Earlier quoted context omitted.
> (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.
Earlier quoted context omitted.
> (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.
Here's such a comparison: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all...
Earlier quoted context omitted.
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…
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.)
Earlier quoted context omitted.
No need to be hostile, I was just detailing my own experience, relevant to the article.
I wouldn't have been hostile if you attacked my family and loved ones. My development environment OTOH ..
I also have written C programs which (with some basic optimisations) are 1000 (yes) times faster than the Lisp equivalent. Initially prototyped in Lisp, and the code ported over line-for-line to C.
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.