|
|
comp.lang.lisp |
> Well, it's relative. Most of the other Lisp/Scheme implementations were two Most typical of all is that such benchmarks (including this ray /Jon -- Jon Harrop <use...@jdh30.plus.com> writes: Which Lisps are you talking about? We've already seen where Allegro
> Ulrich Hobelmann wrote:
> > I wouldn't consider 5 times as slow as a *functional* language very
> > competitive, but it might be fast enough for many problems.
> orders of magnitude slower. Stalin gets even closer than SBCL.
is faster than this SBCL timing and it hadn't even been optimized yet.
I would be surprised if Lispworks were much different in this regard
as well.
> Also, MLton often beats g++, so functional languages aren't slow coaches any So do many CL implementations on many benchmarks when "properly"
> more...
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.
'j' - a n t h o n y at romeo/charley/november com