Re:Wolfram and Lisp Recollections
by Zak on Sunday May 17, 2009 @04:15PM
(#613906)
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.
Re:Wolfram and Lisp Recollections
by anamax on Sunday May 17, 2009 @09:05PM
(#614155)
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.
Re:Wolfram and Lisp Recollections
by bawr on Sunday May 17, 2009 @03:42PM
(#613849)
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.
Re:Wolfram and Lisp Recollections
by zandorg on Sunday May 17, 2009 @03:56PM
(#613868)
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...
Re:Wolfram and Lisp Recollections
by shiro on Sunday May 17, 2009 @04:21PM
(#613913)
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.)
Re:Wolfram and Lisp Recollections
by bawr on Sunday May 17, 2009 @04:04PM
(#613883)
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. ;)
Initially prototyped in Lisp, and the code ported over line-for-line to C.
But... The C code probably ran 100 times faster than Lisp before I optimised it.
Also great job on comparing what is essentially an interpreter to a compiler.
edit: http://www.cliki.net/Performance%20Benchmarks
Clisp is only byte-compiled :-) So no, no way in bloody hell you beat CMUCL/SBCL by 1000 times.
Here's such a comparison: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all...
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 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...
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.)