gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Re: sequences / in-lining


From: Camm Maguire
Subject: Re: [Gcl-devel] Re: sequences / in-lining
Date: 07 Oct 2005 11:17:04 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

"Paul F. Dietz" <address@hidden> writes:

> Camm Maguire wrote:
> 
> > Just my thoughts, Feeback most welcome.
> 
> subtypep doesn't appear to be particularly slow, as judged by
> the speed of the random subtypep tester (it appears to be
> faster than sbcl, actually).  Incidently, that tester has just
> found a bug, which I turned into a test case in subtypep-cons.lsp
> (see test subtypep.cons.40).  This bug appeared four times
> when calling (cl-test::test-types 1000000 5).
> 

Good to hear on subtypep performance wise -- I was worrying, as the
prior quite limited version was just one enormous switch and was much
faster.   Will take a look at the bug you found, thanks!

> I like compiles to be fast -- I often recompile when developing
> in lisp -- and gcl has always had slow compiles relative
> to the other free lisps, and even more so relative to the commercial
> lisps.  Compiler speed is one of the better reasons for going
> with commercial lisps, IMO.  If you think gcl is better focused
> at a different market niche (optimized delivery of speed-critical
> applications, like ACL2) rather than development then I will understand.
> In this case, portability and standards compliance becomes even
> more important, since applications may be developed elsewhere
> and delivered with gcl.

Totally agree about portability and standards regardless of the target
audience, and of course your tester is invaluable in this regard.  It
certainly does seem that there is a division amoung lisp users --
'developers' working interactively with the language, perhaps for
their own private projects, writing libraries for clocc, using SLIME,
and posting to comp.lang.lisp, and 'academicians/industrialists' who
wnat critical results out of existing large applications for which the
authors felt lisp is/was an important but not indispensable choice of
language.  It would be nice to be able to provide service to both sets
of users.  That said, until we get gcl established as a front end for
the gcc compiler suite, I don't know if we can ever get our compile
speed competitive with other implementations, though we can
doubtlessly do much better.  I'm cc'ing this to a few other users to
solicit their opinion if any on gcl's compile speed.

> 
> You're right on the money with the speed issues of lisp's
> built-ins.  It should be  to get good speed with
> a 'natural' lisp programming style.
> 

OK, then lets see what we can do....

Take care,

>       Paul
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

[Prev in Thread] Current Thread [Next in Thread]