From pmai@acm.org Fri Dec 08 19:51:49 2000 Path: news.mclink.it!i2unix!nntp.infostrada.it!fu-berlin.de!newsfeed01.sul.t-online.de!newsmm00.sul.t-online.com!t-online.de!news.t-online.com!not-for-mail From: "Pierre R. Mai" Newsgroups: comp.lang.lisp Subject: Re: Are there "constructors" in CLOS? Date: 08 Dec 2000 19:51:49 +0100 Organization: Pretty Much Science Fiction --- www.pmsf.de Lines: 93 Sender: dent@orion.bln.pmsf.de Message-ID: <87r93i3fwa.fsf@orion.bln.pmsf.de> References: <3A2E75AD.AD48E13A@ilt.fhg.de> <3A2F5E66.F763F610@ilt.fhg.de> <90of0j$pat$1@c3po.schlund.de> <861yvjgqee.fsf@piro.quadium.net> <86y9xrch3p.fsf@raw.grenland.fast.no> Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: news.t-online.com 976303808 05 29516 0u+A61XSnA1w+ 001208 19:30:09 X-Complaints-To: abuse@t-online.com X-Sender: 320001904523-0001@t-dialin.net X-Newsreader: Gnus v5.6.45/XEmacs 21.1 - "Capitol Reef" Xref: news.mclink.it comp.lang.lisp:43699 Raymond Wiker writes: > vsync writes: > = > > > >forewarned, cmucl's CLOS implementation is slow and crufty. > > = > > How slow and crufty? Like, if I'm used to CLISP, will I be satisfied= > > with the performance of CMUCL's CLOS? > = > It has been said here, a good few times, that CMUCLs CLOS is > slow and not fully conformant. It has also been said that CMUCLs CLOS > performance is *not* a problem, and the non-conformance is restricted > to one or two minor areas. I'm one of those that have been countering the claim that CMU CL's CLOS is slow and crufty for a couple of years now. It seems to me that this claim in its generality has long outlived its usefulness. While it is true that CMU CL's CLOS is not quite as polished as the rest of CMU CL, or some of the commercial CLOS implementations out there, and that it probably doesn't take as much advantage of CMU CL's excellent compiler as it probably could, we have found the current state of CMU CL's CLOS to be quite good enough. Also there are currently some moves underway to integrate CMU CL's CLOS more tightly with the rest of CMU CL, so that some of the edges will be going away. To give a perspective on this view: One of our major applications is a manufacturing/logistics simulation toolkit, where simulations often use more than 70 MB of in-core data (sans code and runtime data structures) in over 80.000 CLOS instances, and have run-times in the area of 1-2 hours per 30 days of simulation time. Discrete-event simulations of this sort don't profit hugely from CMU CL's numerical optimisations, since most numerical operations are simple and few and far between. OTOH CLOS operations like method dispatch and slot-accesses are very frequent. Still we have found that on this particular application CMU CL slightly outperforms all the alternative implementations we tried (the nearest implementation did run about 15% slower the last time we tested). For this application we didn't even consider CLISP, since at the time it was far to quirky in its ANSI compliance to make a port feasible. This has changed somewhat in the mean-time, especially with CLISP's ANSI mode, but CLISP is to the best of my knowledge still missing a couple of important things (like change-class or method combinations other than standard method-combination), which makes it difficult to port to CLISP. For those reasons I can't give you comparative figures on CLISP's performance on this application. At the time we also conducted some micro-benchmarks on the different CLOS implementations and found that CMU CL's performance to be within a small factor of the commercial CLOS' versions we tested for many operations, a bit faster for a few, and significantly slower only for one or two areas (mostly instance creation time for constant classes, though CMU CL's CLOS offers a specific optimisation here, for the cases where this really matters). On the benchmarks that were runnable on CLISP, CMU CL more or less consistently performed better by a factor of between 2 to 20, with the following exceptions: - Calls to methods specialised on a large (5-10) number of arguments: CLISP wins by nearly a factor of 3. - Calls to SLOT-VALUE outside of method: CLISP wins by a factor of 1.5. - Calls to SLOT-VALUE for a class-allocated slot outside of method: CLISP wins by a factor of 3. - MAKE-INSTANCE on variable classes (by name or class object): CLISP wins by a factor between 2.5 - 4 - SLOT-UNBOUND trapping (all scenarios): CLISP wins by a factor of > 20, because SLOT-UNBOUND traps are very expensive on CMU CL (up to 75 =B5sec on an AMD K6-2/550). Now these numbers should all be taken with a large grain of salt, since it is entirely likely that with some implementation-specific tuning, newer versions or some other set of operations, other implementations will significantly out-perform CMU CL. Also note that commercial implementations are generally much more polished across the board than free implementations like CMU CL or CLISP. So you'll probably like to do your own benchmarking (if you really have to care about small constant performance-factors) and evaluation, and decide on your own which implementation will fulfil your needs. Don't just trust me or anyone else telling you CMU CL's CLOS is fast or slow, nice-enough or crufty, etc. Regs, Pierre. -- = Pierre R. Mai http://www.pmsf.de/pmai/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein