[Top][All Lists]

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

[Gcl-devel] gcl inlining policy

From: Camm Maguire
Subject: [Gcl-devel] gcl inlining policy
Date: Fri, 06 Jul 2007 12:58:02 -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!  If you would be so kind, I'd appreciate some direction on
the desired inlining policy fro gcl 2.7.0.

GCL has always inlined certain functions, e.g. mapcar, member, etc.
Without this, performance would be noticeably worse.

Traditionally, this has been accomplished though ad-hoc 'c1 functions
in the compiler, or C-snippet inline attributes in cmpopt.lsp.  Thus
one had not only to write the function, but its inline support in the
compiler as well.  Support for these remain, but thanks to Boyer's
suggestion to carry the original source around in the image, automatic
inlining is now possible.  Support for this is in place in 2.7 with
notable improvements in performance.

The question is, what functions should be inlined by default?
Currently, symbols external to the lisp package are automatically
considered. Explicitly declared or declaimed functions are also.
inlining may decline if the inline is too large, using a heuristic
function using the *space* setting as input, though in many cases,
inlined code is smaller.  The real cost of inlining is compiler speed,
and tracing support.

Boyer recently posted a benchmark which would benefit greatly from
automatic inlining of user functions.

Separately, should inlining be allowed at safety 3?

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]