From: Stefan Svenberg
Subject: Inline expansions in Allegro 4.2
Date:
Message-ID: <D8vGs7.C3q@ida.liu.se>
At page 7-32 about compiler declarations and optimizations in the Allegro
User Guide, we read:
"Only predefined functions can be inlined. User defined functions are never
compiled inline."
Does anyone know why the Allegro compiler never inlines user functions? Is
it because it does not provide any advantages in speed, or what?
I have a large number of small primitive functions that do nothing else but
calling other built-ins, such as car, cdr, aref, etc.
/Stefan Svenberg, ···@ida.liu.se
--
Stefan Svenberg email: ···@ida.liu.se
Department of Computer Science Phone: +46 13 28 26 90
University of Linkoping
581 83 Linkoping, SWEDEN
In article <··········@ida.liu.se> ·····@ida.liu.se (Stefan Svenberg) writes:
At page 7-32 about compiler declarations and optimizations in the Allegro
User Guide, we read:
"Only predefined functions can be inlined. User defined functions are never
compiled inline."
Does anyone know why the Allegro compiler never inlines user functions? Is
it because it does not provide any advantages in speed, or what?
I have a large number of small primitive functions that do nothing else but
calling other built-ins, such as car, cdr, aref, etc.
I consider Allegro's decision to ignore inline declarations as a gross sin.
For now, you can write a DEFINE-INLINE macro that will let you write
inlined functions easily.
--
Ken Anderson
Internet: ·········@bbn.com
BBN ST Work Phone: 617-873-3160
10 Moulton St. Home Phone: 617-643-0157
Mail Stop 6/4a FAX: 617-873-2794
Cambridge MA 02138
USA
From: ······@sbox.tu-graz.ac.at (Reinhard Urban)
> Does anyone know why the Allegro compiler never inlines user functions? Is
> it because it does not provide any advantages in speed, or what?
> I consider Allegro's decision to ignore inline declarations as a gross sin.
Could it be, that small inline functions have a overhead in calling time, so
that only larger functions gain the compilation effort?
Just the opposite. By inlining a function you eliminate the overhead
of doing a full function call. This matters much more in calling very
small functions in a tight loop than when you are calling larger
functions, in which the cost of the call is amortized over a larger
amount of computation.
-- Scott
P.S. The ISBN for CLTL2 is 1-55558-041-6. Used copies are
occasionally available around here as people who bought these for
courses head off to jobs where they wil;l be forced to program in C++
for the rest of their lives. :-( I want to keep my copy. If you're
really buying this to read in bed, you should seek IMMEDIATE counseling.
===========================================================================
Scott E. Fahlman Internet: ····@cs.cmu.edu
Principal Research Scientist Phone: 412 268-2575
School of Computer Science Fax: 412 268-5576
Carnegie Mellon University Latitude: 40:26:46 N
5000 Forbes Avenue Longitude: 79:56:55 W
Pittsburgh, PA 15213 Mood: :-)
===========================================================================
[Scott Fahlman]
| P.S. The ISBN for CLTL2 is 1-55558-041-6. Used copies are occasionally
| available around here as people who bought these for courses head off
| to jobs where they wil;l be forced to program in C++ for the rest of
| their lives. :-( I want to keep my copy.
Digital Press is reportedly still not out of stock.
| If you're really buying this to read in bed, you should seek IMMEDIATE
| counseling.
this is harsh. he should be allowed to wait until the weekend is over.
I'm not sure counseling works, though. I read ISO draft standards for
programming languages in bed, and all they can promise is that if I don't
ever try to imply that this is within "normal", they won't lock me up.
#<Erik 3011281492>
--
NETSCAPISM /net-'sca-,pi-z*m/ n (1995): habitual diversion of the mind to
purely imaginative activity or entertainment as an escape from the
realization that the Internet was built by and for someone else.
Ken Anderson (········@bitburg.bbn.com) wrote:
> In article <··········@ida.liu.se> ·····@ida.liu.se (Stefan Svenberg) writes:
> Does anyone know why the Allegro compiler never inlines user functions? Is
> it because it does not provide any advantages in speed, or what?
> I consider Allegro's decision to ignore inline declarations as a gross sin.
> For now, you can write a DEFINE-INLINE macro that will let you write
> inlined functions easily.
> Ken Anderson
Could it be, that small inline functions have a overhead in calling time, so
that only larger functions gain the compilation effort?
--
| Reini Urban alias ······@sbox.tu-graz.ac.at |
| AutoCAD Courses at the TU-Graz, Austria, |
| Architects Domenig-Eisenkoeck, Graz |
| http://ars.uni-linz.ac.at/biografie/urban.eng.html
From: Stefan Svenberg
Subject: Re: Inline expansions in Allegro 4.2
Date:
Message-ID: <D9uyus.66L@ida.liu.se>
······@sbox.tu-graz.ac.at (Reinhard Urban) writes:
>Ken Anderson (········@bitburg.bbn.com) wrote:
>> In article <··········@ida.liu.se> ·····@ida.liu.se (Stefan Svenberg) writes:
>> Does anyone know why the Allegro compiler never inlines user functions? Is
>> it because it does not provide any advantages in speed, or what?
>> I consider Allegro's decision to ignore inline declarations as a gross sin.
>> For now, you can write a DEFINE-INLINE macro that will let you write
>> inlined functions easily.
>> Ken Anderson
>Could it be, that small inline functions have a overhead in calling time, so
>that only larger functions gain the compilation effort?
Quite the contrary.
The people at Franz picked up my original posting and mailed me a reply.
That's quite impressive. They said that they believe there are other
improvements that can be made that provide more advantages. They also proposed
to use compiler macros, which I already had tried, as I wrote a macro
definline that generated a compiler macro along with the function definition.
My problem was not really acute, but
what really bothered me is that the benefits of inlining built-in functions
are lost if you have small primitive functions working on accessing parts
of dataobjects. Suppose we have a database that happened to be implemented
as a list, where there is an accessor function:
(defun first-of-db (db)
(car db))
If car is compiled inline, that's fine. But it is annoying that first-of-db
can't be. This is ridiculous.
Inlining sounds conceptually simple; just substitute the function call for
the body along with the arguments. But maybe it is not that simple, I do not
know.
I have experiences working with Xerox Lisp, where inlining was very useful.
The compiler did many clever optimizations on the code.
/Stefan
--
Stefan Svenberg email: ···@ida.liu.se
Department of Computer Science Phone: +46 13 28 26 90
University of Linkoping
581 83 Linkoping, SWEDEN
From: Barry Margolin
Subject: Re: Inline expansions in Allegro 4.2
Date:
Message-ID: <3ra78i$pb4@tools.near.net>
In article <··········@ida.liu.se> ·····@ida.liu.se (Stefan Svenberg) writes:
>Inlining sounds conceptually simple; just substitute the function call for
>the body along with the arguments. But maybe it is not that simple, I do not
>know.
It's not quite that simple, as it requires a code walk to determine which
symbols in the body are literal, functional, or lexically shadowed and
should not be substituted. E.g. consider the following nonsense:
(declaim (inline rotate-tires))
(defun rotate-tires (car)
(cond (CAR
(print (cons 'car CAR))
(rotatef (car CAR) (cdr CAR))
(apply #'car CAR))
(t (let ((car *default-car*))
(print (cons 'car car))
(rotatef (car car) (cdr car))
(apply #'car car)))))
When doing the inline expansion, only the references to CAR that I've
written in uppercase should be substituted.
--
Barry Margolin
BBN Planet Corporation, Cambridge, MA
······@{bbnplanet.com,near.net,nic.near.net}
Phone (617) 873-3126 - Fax (617) 873-5124
Barry Margolin <······@nic.near.net> wrote:
> It's not quite that simple, as it requires a code walk to determine which
> symbols in the body are literal, functional, or lexically shadowed and
> should not be substituted. E.g. consider the following nonsense:
>
> (declaim (inline rotate-tires))
> (defun rotate-tires (car)
> (cond (CAR
> (print (cons 'car CAR))
> (rotatef (car CAR) (cdr CAR))
> (apply #'car CAR))
> (t (let ((car *default-car*))
> (print (cons 'car car))
> (rotatef (car car) (cdr car))
> (apply #'car car)))))
>
> When doing the inline expansion, only the references to CAR that I've
> written in uppercase should be substituted.
You must have a special kind of compiler architecture in mind. If you
consider a compiler which is built as a textual substitution processor,
then, yes, inline compilation is difficult. But I would call this a
"superficial" compiler. (Yes, I know that the first Lucid compiler was
like this.)
Another approach is to have an explicit data structure for the lexical
environment within the compiler. Distinguishing the "CAR"s from the "car"s
is part of the normal compiler business. When doing the inline expansion,
the symbol is just replaced by a lambda expression:
(rotate-tires (foo)) --> ((lambda (car) (cond ...)) (foo))
except that the lexical environment is bound to another one in the middle.
Roughly like this:
(defmethod compile-function-call (form environment)
(if (inlinable (first form))
(compile-inline-function-call (fetch-inline-definition (first form))
(rest form) environment)
)
...
) )
(defmethod compile-inline-function-call (inline-definition args environment)
(dolist (arg args)
(compile-form-and-push-to-stack arg environment)
)
(compile-lambda-expression (slot-value inline-definition 'lambda-expression)
(slot-value inline-definition 'environment)
: here's the change of lexical environment
) )
> When doing the inline expansion, only the references to CAR that I've
> written in uppercase should be substituted.
Btw, replacing all the upper-case "CAR"s in your example by the argument
form (e.g. (FOO)) is wrong, unless you know that the argument form is a
constant or that the "CAR" is only used once and there is no problem with
side effects. In the normal case, you have a normal lambda variable.
Bruno Haible
······@ma2s2.mathematik.uni-karlsruhe.de