|
|
comp.lang.lisp |
>> Well, it's relative. Most of the other Lisp/Scheme implementations were > Which Lisps are you talking about? > So do many CL implementations on many benchmarks when "properly" I'd like to do another benchmark with an example from scientific computing -- jayessay wrote: Primarily CMUCL and SBCL.
> Jon Harrop <use...@jdh30.plus.com> writes:
>> 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.
>> two orders of magnitude slower. Stalin gets even closer than SBCL.
> We've already seen where Allegro Is Lispworks free?
> 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 What kinds of tasks is Lisp best at, in terms of performance? I Googled for
>> any more...
> written. Several have been shown here in the past.
information on this but most of the sites I found were no longer up.
> Typically this Can you point me to some examples of this? I heard of a benchmark written
> 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.
long ago where some Lisp gurus managed to code an equivalently-efficient
implementation in Lisp. However, it is important to know how easily an
efficient version can be written. LOC is a very rudimentary measure of
development time.
> Most typical of all is that such benchmarks (including this ray I think my conclusions were interesting. In particular, I was surprised to
> tracing thing) don't have much of anything interesting to say about
> anything.
see modern functional language implementations doing so well at what is
arguably their weakest point.
next...
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com