From pmai@acm.org Fri Nov 12 14:20:17 1999 Received: from Sunset.AI.SRI.COM (Sunset.AI.SRI.COM [130.107.64.76]) by mailhub.mclink.it (8.9.1/8.9.0) with ESMTP id RAA15426 for ; Fri, 12 Nov 1999 17:34:18 +0100 (CET) Received: by Sunset.AI.SRI.COM (8.9.3/SMI-4.1) id HAA13804 for x3j13-internal; Fri, 12 Nov 1999 07:25:03 -0800 (PST) Received: from dent.isdn.cs.tu-berlin.de by Sunset.AI.SRI.COM (8.9.3/SMI-4.1) id HAA13800 for ; Fri, 12 Nov 1999 07:24:58 -0800 (PST) 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 OAA31191; Fri, 12 Nov 1999 14:20:17 +0100 Received: by dent.isdn.cs.tu-berlin.de via sendmail from stdin id (Debian Smail3.2.0.102) for X3J13@ai.sri.com; Fri, 12 Nov 1999 14:20:17 +0100 (CET) Sender: dent@orion.dent.isdn.cs.tu-berlin.de To: Jon L White Cc: jeff@aiai.ed.ac.uk, tfb@tfeb.org, X3J13@ai.sri.com Subject: Re: Core Lisp References: <199911120054.AAA00695@todday.aiai.ed.ac.uk> <199911120451.UAA19135@kuwait.arc.nasa.gov> 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 7.108) Content-Type: text/plain; charset=US-ASCII From: pmai@acm.org (Pierre R. Mai) Date: 12 Nov 1999 14:20:17 +0100 In-Reply-To: Jon L White's message of "Thu, 11 Nov 1999 20:51:11 -0800 (PST)" Message-ID: <87ln83q226.fsf@orion.dent.isdn.cs.tu-berlin.de> Lines: 98 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Arches" Jon L White writes: > re: And when I last used CMU CL, at least, its CLOS was PCL, that CLOS > still felt like an add-on, and it was fairly painful to use it. > > At the Lisp Users Group Meeting in San Francisco last month, some fellow > (from a company in Germany, I think?) presented a paper on a large project > implemented in CMU CL. He pointed to one specific slow performance problem, > and in response to questioning from the audience he finally indicted the > poor perforamce of the CLOS therein. Not surprising, given how much more > optimization the commercial vendors did to teir CLOS modules after PCL > stopped evolving (circa 1989 or 1990.) In my experience the one area where CMUCL's PCL is really quite a bit slower than commercial CLOS implementations is in instance creation via make-instance of constant classes, where you can be slower by a factor up to 8-10. If you are creating instances very quickly, then this can be a problem. Though you can often work around it by using PCL's defconstructor (which can be made transparent by the use of a compiler macro), I've been meaning to develop a general fix for this. The other area where CMUCL is a bit slower (factor of ~1.5-2) is in calling generic-functions with plain-vanilla methods only. OTOH PCL is often faster in cases where more advanced features are involved, like eql-specializers, :before-:after-:around-methods, non-standard method combinations, etc. After studying some papers on PCL and the code, it seems to me that CMUCL's PCL could benefit from implementing a specialized version of the LAP code (which is used to generate discriminating functions, etc. at run time). This might speed up some of the standard cases, reduce the latency for first calls, and it might also remove the need to keep the compiler around at runtime. I might give this a try when/if time permits and my need for a faster CLOS gets more pronounced. All in all the situation for CLOS on CMUCL now doesn't seem quite as bleak as it has been painted here. I've also never found CMUCL's CLOS painful to use. The only visible artefacts of PCL's own identity I've run across until now are: * Non-complete integration with structures, i.e. the behaviour of structure printing is not ANSI conforming, and this is non-trivial to fix because of build-time dependencies * When using the MOP, you sometimes have to coerce meta-classes to MOP metaclass objects, before using them. You also have to be aware that CL:STANDARD-CLASS and PCL:STANDARD-CLASS are different. All in all this isn't to painful (when you write cross-platform MOP code there are many more issues you have to look out for anyway, since all implementations differ in superficial ways. I hope that this round of standardization could iron out those kinks). * The compiler doesn't make use of the information present in CLOS macros quite as much as it does make use of other information, causing some duplication of information. There might be many others, I've just not come across any of them after developing applications with CMUCL that make non-trivial uses of CLOS and the MOP. The above estimate on CMUCL's performance is based on micro-benchmarks and the run-times of a non-trivial simulation package that we have developed in-house. This software package makes heavy use of CLOS, and doesn't contain much numerical code (factory-floor and logistics simulation), yet CMUCL is still the fastest implementation of all implementations tested (and no CMUCL-specific optimizations have been made), by a small margin (next-best implementation is of by a factor of ~1.2-1.5 depending on subsystems used). Since this project is in continually evolving as we meet customer needs, CLOS usage patterns might change, and we might yet encounter problems with CMUCL's CLOS speed, but until now we haven't. In my estimate the main speed problem we are encountering today is CMUCL's generational conservative garbage collector, rather than it's CLOS performance. It is in the area of GC that we see major quality jumps when going to commercial implementations (as well as the more consistent quality of implementation one sees with commercial implementations, whereas CMUCL's is unsurprisingly not as consistent across the board). So while PCL seems slow compared to CMUCL's numeric code, for example, in my experience it still is not that terribly slow compared to other CLOS implementations, so that depending on the mix of code used, whole applications can still give pretty good performance figures, even if using CLOS heavily. To summarize: I'm not making a claim as to general performance and quality levels, I'm just trying to offer a couple of data-points that seem to indicate that PCL's performance is not that bad for at least one user. 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]