Message from discussion
Very poor Lisp performance
Path: g2news1.google.com!news3.google.com!news.glorb.com!border1.nntp.dca.giganews.com!local01.nntp.dca.giganews.com!nntp.rcn.net!news.rcn.net.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 14 Aug 2005 10:57:55 -0500
Sender: j...@rigel.goldenthreadtech.com
Newsgroups: comp.lang.lisp
Subject: Re: Very poor Lisp performance
References: <42fdd7a8$0$97130$ed2619ec@ptn-nntp-reader03.plus.net> <2005081321013216807%raffaelcavallaro@pasdespamsilvousplaitmaccom> <42ff04a9$0$78285$157c6196@dreader1.cybercity.dk> <42ff1c6e$0$1279$ed2619ec@ptn-nntp-reader02.plus.net> <3m95opF15sleiU1@individual.net> <42ff662a$0$97128$ed2619ec@ptn-nntp-reader03.plus.net>
From: jayessay <nos...@foo.com>
Organization: Tangible
Date: 14 Aug 2005 12:04:18 -0400
Message-ID: <m3mznksdx9.fsf@rigel.goldenthreadtech.com>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Lines: 32
NNTP-Posting-Host: 209.6.25.79
X-Trace: sv3-mVsMqTgR3cfWo3HHLtnfUkQFJlx8QGG9GeNytBJ1AsNl6j1egpAx6Ee4RXnZNWAO3KB9z0uULnYVuGc!tTmH9+H9bksNdafHEJo9UEjXAjVBD49mUGvWEMPBooW5wrGCQRsESqLTDSTHzbtE9PBT+6VbCmrC
X-Complaints-To: abuse@rcn.net
X-DMCA-Complaints-To: ab...@rcn.net
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.32
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.
>
> Well, it's relative. Most of the other Lisp/Scheme implementations were two
> orders of magnitude slower. Stalin gets even closer than SBCL.
Which Lisps are you talking about? We've already seen where Allegro
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
> more...
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.
Most typical of all is that such benchmarks (including this ray
tracing thing) don't have much of anything interesting to say about
anything.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
|
