From pmai@acm.org Thu Mar 23 15:43:04 2000 Received: from knight.cons.org (knight.cons.org [194.233.237.86]) by mailhub.mclink.it (8.9.1/8.9.0) with ESMTP id PAA08447 for ; Thu, 23 Mar 2000 15:59:16 +0100 (CET) Received: from dent.isdn.cs.tu-berlin.de (root@dent.home.cs.tu-berlin.de [130.149.147.106]) by knight.cons.org (8.9.3/8.9.3) with ESMTP id PAA00711 for ; Thu, 23 Mar 2000 15:43:12 +0100 (CET) Received: from orion.dent.isdn.cs.tu-berlin.de (root@orion.dent.isdn.cs.tu-berlin.de [192.168.42.10]) by dent.isdn.cs.tu-berlin.de (8.9.3/8.9.3/Debian/GNU) with ESMTP id PAA11792; Thu, 23 Mar 2000 15:43:05 +0100 Received: by dent.isdn.cs.tu-berlin.de via sendmail from stdin id (Debian Smail3.2.0.102) for cmucl-imp@cons.org; Thu, 23 Mar 2000 15:43:04 +0100 (CET) Sender: dent@orion.dent.isdn.cs.tu-berlin.de To: "Fernando D. Mato Mira" Cc: cmucl-imp@cons.org Subject: Re: Spurious range warnings References: <38D61E55.4A21B495@iname.com> <38D64524.FA521925@jeack.com.au> <38D780EA.8A258B6@iname.com> <14552.1675.163253.422952@rtp.ericsson.se> <38D89BB5.D010E7B4@iname.com> <14553.3034.933367.98564@rtp.ericsson.se> <38D9E6FF.D2A4D8A3@iname.com> X-PGP-Fingerprint: 17 2D 00 93 8B C8 57 57 A7 D7 CD E9 3A EA 6E 4C Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII From: pmai@acm.org (Pierre R. Mai) Date: 23 Mar 2000 15:43:04 +0100 In-Reply-To: "Fernando D. Mato Mira"'s message of "Thu, 23 Mar 2000 10:42:23 +0100" Message-ID: <87og854uiv.fsf@orion.dent.isdn.cs.tu-berlin.de> Lines: 45 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Arches" "Fernando D. Mato Mira" writes: > Whoever wants to make CMUCL a most excellent implementation virtual TODO list > [the obvious first three items are fast CLOS, fast GC, and dynamic-extent > honoring] Sorry for the rant below, but CMUCL's CLOS implemenation seems to have a far worse reputation than it really deserves, and I'm trying my best to work against this meme... This is the standard reply I give to anyone demanding a faster CLOS in CMUCL: I'd like to see the figures that show that CMUCL performance is so much below par that it matters. I've spent a fair amount of time benchmarking CMUCL/PCL against other CLOS implementations, both using micro-benchmark and real-live large applications. I've yet to come across an area where CMUCL lost with any amount of significance, with the exception of instance creation. When instance creation is a hot-spot in an application, given that you'll have bounded memory resources, you are rapidly creating and destroying instances. In this situation you'll want to introduce a resourcing scheme to recycle the instances anyway, in most implementations. In real life, the simulations we run are quite heavy users of CLOS, with a fair amount of instance creation thrown in. They don't profit that much from CMUCL's strong areas (e.g. only a small amount of arithmetic operations, most of them integer ops, not many declarations around). The overall performance of CMUCL on these beasts is usually as good as other implementations, quite often better (factors ~ 1.2-1.5 to next best implementation). And the area where CMUCL usually takes it's performance hit is GC performance, not CLOS performance. So for me personally, CLOS performance is by far the least important item on my virtual todo list. I'd rank GC preciseness and GC performance, integration of CLOS/PCL into CMUCL (e.g. proper compile-time handling of CLOS top-level constructs, fixing print-object behaviour for structure-instances, proper integration of fast gray stream classes, etc.), and an implementation of a standardized MOP far above it. Regs, Pierre. -- Pierre Mai PGP and GPG keys at your nearest Keyserver "One smaller motivation which, in part, stems from altruism is Microsoft- bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]