Google Mail Calendar Documents Reader Web more »
Recently Visited Groups | Help | Sign in
Google Groups Home
Message from discussion Very poor Lisp performance

View Parsed - Show only message text

Path: g2news1.google.com!news4.google.com!news.glorb.com!newsfeeder.wxs.nl!nntp-peering.plus.net!ptn-nntp-feeder01.plus.net!ptn-nntp-spool01.plus.net!ptn-nntp-reader03.plus.net!not-for-mail
Message-Id: <42fe56e8$0$97109$ed2619ec@ptn-nntp-reader03.plus.net>
From: Jon Harrop <use...@jdh30.plus.com>
Subject: Re: Very poor Lisp performance
Newsgroups: comp.lang.lisp
Date: Sat, 13 Aug 2005 21:21:35 +0100
References: <42fd4459$0$97104$ed2619ec@ptn-nntp-reader03.plus.net> <HvSdnayKD_1M8mDfRVn-ow@speakeasy.net> <42fdd7a8$0$97130$ed2619ec@ptn-nntp-reader03.plus.net> <slrndfsf3v.p65.jsnell@sbz-31.cs.Helsinki.FI>
Organization: Flying Frog Consultancy Ltd.
User-Agent: KNode/0.8.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Lines: 38
NNTP-Posting-Host: 80.229.56.224
X-Trace: 1123964649 ptn-nntp-reader03.plus.net 97109 80.229.56.224:58977

Juho Snellman wrote:
> <use...@jdh30.plus.com> wrote:
>>>> My system is an unladen 900MHz Athlon T-bird with 768Mb RAM running
>>>> Debian testing with SBCL 0.8.16 and CMUCL "19b-release-20050628-3 +
>>>> minimal debian patches".
> 
> That's a rather ancient version of SBCL, you might want to upgrade.

Debian unstable has 0.9.3. It's upgrading now... :-)

> For example:
> 
>> (defstruct (vec (:conc-name nil) (:constructor vec (x y z)))
>>   (x 0.0 :type single-float)
>>   (y 0.0 :type single-float)
>>   (z 0.0 :type single-float))
> 
> This is using about 2x the memory of what you'd expect for each
> instance, and doing an extra memory indirection for each slot access.
> Proper support for storing the floats "raw" in the struct was added in
> 0.9.2 by David Lichteblau.

I see.

> Another possible pitfall on older SBCLs (<0.8.21) is that they don't
> honor the compiler policy for code entered on the repl, but compile it
> with low speed, high debug/safety. If you've been pasting the code
> into the repl instead of LOADing it, performance would indeed be
> horrible.

Aha! Yes indeed. I just tried (load (compile-file "...")) and it runs in
only 20secs compared to ~250secs from the top-level and 2.5secs for C++.

Thanks for the help. I'll repost when I get results with the new compiler.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2009 Google