From pmai@acm.org Sat Oct 28 17:53:26 2000 Path: news.mclink.it!news.caspur.it!serra.unipi.it!chico.franken.de!uni-erlangen.de!newsfeeds.belnet.be!news.belnet.be!newsfeed00.sul.t-online.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: Can I use Lisp? Date: 28 Oct 2000 17:53:26 +0100 Organization: Pretty Much Science Fiction --- www.pmsf.de Lines: 54 Sender: dent@orion.bln.pmsf.de Message-ID: <877l6saovt.fsf@orion.bln.pmsf.de> References: <16savskpras2on0vjcfmq2km962sbtcian@4ax.com> <8t44r6$3pc$1@nnrp1.deja.com> <3181391107929417@naggum.net> <3181477127456574@naggum.net> <8t7ecv$tir$1@nnrp1.deja.com> <3181518131621435@naggum.net> <8t9d55$f3k$1@nnrp1.deja.com> <8tctob$d4h$1@nnrp1.deja.com> Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII X-Trace: news.t-online.com 972754207 06 27460 Crc6EtGSJYeIU 001028 17:30:07 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:41539 Tim Bradshaw writes: [ excellent points omitted ] > If people want to contribute to free (in whatever sense we have to use > that word this week) Lisp systems I think it would be much better for > them to spend their time improving one of the existing systems. There > are obvious huge lacunae in most of them. Taking CMUCL as an example: > > * CLOS. The current PCL-based implementation has sufficiently low > performance that it discourages CLOS-based programming. An > integrated `native' CLOS is needed. While the low performance of CMU CL's PCL-based CLOS is often mentioned, I personally haven't felt _the performance_ of CMU CL's CLOS to have been a problem: Both in the micro-benchmarks I've conducted, as well as in real-world usage in non-trivial heavily CLOS-based simulation systems, I've found CMU CL's CLOS performance to be within a factor of 1.2-1.5 of the fastest commercial CLOS implementations. Indeed performance was good enough so that overall application performance was still best in CMU CL. I think that the impression of CMU CL's "slow" CLOS stems more from the fact that it seems slow compared to CMU CL's blindingly fast code in other areas, rather than from the fact that it is so much slower than other CLOS implementations. Which brings me to the problem I have with CMU CL's PCL-based CLOS: The lack of full integration with the base-system and especially with the compiler. The resulting rough edges (some spurious warnings during compilation, MOP-related issues, less optimization done by the compiler, no-CLOS based code in the base-system, ...) cause the programmer to get the impression that CLOS code is a second-class citizen in CMU CL, which is quite harmful. The good news is that there is progress being made on the CLOS front. > * Better GC. Indeed this is one of the areas where IMHO CMU CL has the most noticeable deficits when compared to commercial implementations, IMHO. Especially on x86 where the conservative GC sometimes reacts badly with code produced by the compiler, so that serious amounts of garbage can remain unreclaimed for longish durations. [ other problems and interesting problem description elided ] 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