|
|
comp.lang.lisp |
> Most typical of all is that such benchmarks (including this ray So what have we learned? We confirmed what we pretty much I am sure Jon can pick up some nice tricks in the thread. <http://groups.google.com/group/comp.lang.lisp/msg/ae59ca28867ced78?hl...> -- jayessay wrote: The comp.lang.lisp thread on Almabench comes into mind.
> Jon Harrop <use...@jdh30.plus.com> writes:
>>Well, it's relative. Most of the other Lisp/Scheme implementations were two
>>orders of magnitude slower. Stalin gets even closer than SBCL.
> So do many CL implementations on many benchmarks when "properly"
> written. Several have been shown here in the past. Typically this
> starts with the original posting "showing" how bad CL is supposed to
> be when comparing optimized C/C++ with naively written CL. It also
> often ends with the CL version beating the optimized C/C++ version.
> tracing thing) don't have much of anything interesting to say about
> anything.
Rif summed it up pretty nicely:
knew: you can write a C program in CL, at which point the
relative speed of your C and CL versions will depend on the
relative quality of the code generation.
Jens Axel Søgaard