[Top][All Lists]

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

[Gcl-devel] Version_2_7_0t4

From: Camm Maguire
Subject: [Gcl-devel] Version_2_7_0t4
Date: Mon, 08 Aug 2005 22:47:41 -0400
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigory ōmae) APEL/10.3 Emacs/21.2 (i386-debian-linux-gnu) MULE/5.0 (SAKAKI)

Greetings!  Happy to announce:

Stable version: 2.6.6
Testing version: (cvs tag) Version_2_7_0t4

I'm jumping the gun a little bit here as my tests are still running,
but I'm short on time.  It looks pretty solid.

Significant work has been done in the compiler to automate certain
optimizations using information deduced via type propagation.  Further
work has been done allowing the compiler to omit certain branches of
if statements when it can be determined that the result of the test is
always false or true, again via type propagation.  Using this facility
and compiler macros, many list loop functions are inlined, upgrading
equality tests at runtime to eq if appropriate, and at compile time if
possible from type information.  Some facility exists for inspecting
both the item and the list contents in the compiler to this end where
possible.  I.e. doing a member on a supplied constant list '(a b c)
will use eq, as well as '(a (foo) b) if (foo) is proclaimed to return
a type which is upgradable from eql to eq.  Explicitly supplied tests
and keys in lambda form are inlined, with type propagation proceeding
inside the 'closure'.  The interested user  might want to disassemble
various test functions with compiler::*suppress-compiler-notes* bound
to nil -- type propagation and branch elimination should be reported
explicitly.  member, assoc, et.al., dotimes et.al. are useful for this
purpose.  Many thanks to Paul Dietz' compiler tests.  More is still yet
to come with the sequence functions.  Preliminary scaffolding is in
gcl_cmpfun.lsp, do-vector....

Much of this type work has proceeded trying to work around the
deficiencies of our subtypep.  We've taken the approach thus far that
we'd try to pass Paul's tests by returning the second argument as nil
when the problem was too hard, etc.  I finally caved in and rewrote
the subtypep type system.  I'm sure there was a better way, but I
couldn't see it, and at least I understand now what to expect from our
code.  We always return t as the second argument, and pass all Paul's
current tests.  We implement this via analyzing the nil status of the
type (and t1 (not t2)) after orthoganalizing the types as largely
described in Baker's paper, ignoring for the moment the exponential
time considerations for cons types, which don't appear too onerous as
yet.  This automatically gives us the facility to type-and and
type-or in the compiler, functions that had been written separately
and incompletely heretofore.  The interested user is asked to look at
lsp/gcl_predlib.lsp, and to play with the output of
(si:;resolve-type).  The code is doing much more work than before, yet
the performance appears amazingly acceptable, with room left for
improvement.  In addition to compiling deftype expansions, which are
the rate limiting step at present, I'd like to hash the type functions
in the compiler if time permits, perhaps even with some sophisticated
hash consing.  In general I've taken the position that runtime
performance is always worth extra compile time.  feedback of course
most welcome.

We've also enabled local function optimization declarations, so one
can compile the file gcl_predlib.lsp with full optimization, and only
the  exported wrapper functions with safety 1 to ensure argument
checking.  We need to go through all our other files and do the same.

The type system is now sophisticated enough to distinguish boolean
from t -- hence boolean inlines in gcl_cmpopt.lsp now automatically
generate corresponding t inlines.

As a test case for these facilities, the compiler now optimizes pcl's
std-instance-p predicate when possible using a deftype form '(or
structure (and standard-object (not funcallable-standard-object))).
find-class, classp, class-name, and class-predicate list are
overwritten in the si package in the middle of the pcl build, first
with the 'early-definition' versions, then later with the complete
versions, in gcl_pcl_defs.lisp and gcl_pcl_defcombin.lisp
respectively.  Some work has also been done on optimizing the pcl
cache, as it is used somewhat heavily in the type system.

I may have to delay further work for a few days, and will be leaving
state from 8/12 to 8/17.  Hopefully this meets with everyone's needs.

Take care,
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]