Long ago, in a galaxy far far away, I was a C++ programmer who thought he
knew how to use inline judiciously. Imagine my chagrin when, innocently
perusing an article on graphics programming, I came across a sidebar which
stated that the alpha geeks never used inline except in code that could
conceivably be ported to an embedded device. The reason was that said alpha
geeks knew their compilers well enough that they realized that the compiler,
or the combination or the compiler and the front end of the microprocessor,
was going to do everything possible to eliminate the creation of very
expensive stack frames. Any hints from the programmer were summarily
ignored.
Figuring that I might as well reveal my ignorance of Lisp compilers rather
than forcing you all to infer it from my use or non-use of inline, I decided
to just ask. Does the current generation of Lisp compilers pay attention to
inline at all? Do you proclaim functions inline or just trust your
compilers?
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Chris Gehlker <·······@fastq.com> writes:
> Long ago, in a galaxy far far away, I was a C++ programmer who thought he
> knew how to use inline judiciously. Imagine my chagrin when, innocently
> perusing an article on graphics programming, I came across a sidebar which
> stated that the alpha geeks never used inline except in code that could
> conceivably be ported to an embedded device. The reason was that said alpha
> geeks knew their compilers well enough that they realized that the compiler,
> or the combination or the compiler and the front end of the microprocessor,
> was going to do everything possible to eliminate the creation of very
> expensive stack frames. Any hints from the programmer were summarily
> ignored.
>
> Figuring that I might as well reveal my ignorance of Lisp compilers rather
> than forcing you all to infer it from my use or non-use of inline, I decided
> to just ask. Does the current generation of Lisp compilers pay attention to
> inline at all? Do you proclaim functions inline or just trust your
> compilers?
(Some) lisp compilers still look at inline declarations. Part of the
reason is that the semantics of Lisp are very different than C++,
namely, you can redefine functions. So the compiler can't just inline
a function because it's tiny, unless you explicitly give it license to
do so, either through inline declarations, or a mechanism like CMUCL's
compilation blocks.
While the compiler can't go open coding function calls willy nilly,
the runtime certainly could, as Pascal pointed out by reference to the
HotSpot and StrongTalk VM. There's no reason this couldn't be done
for Lisp. Unfortunately, it would be a major R&D effort, and I don't
think there's the resources for such an effort for CL right now.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
CMUCL makes very effective use of inline declarations. Here's what
the manual says (Python is the name of the CMUCL compiler):
Python can expand almost any function inline, including functions
with keyword arguments. The only restrictions are that keyword
argument keywords in the call must be constant, and that global
function definitions (`defun') must be done in a null lexical
environment (not nested in a `let' or other binding form.) Local
functions (`flet') can be inline expanded in any environment.
Combined with Python's source-level optimization, inline
expansion can be used for things that formerly required macros
for efficient implementation. In Python, macros don't have any
efficiency advantage, so they need only be used where a macro's
syntactic flexibility is required.
There's also a `maybe-inline' declaration extension that allows inline
expansion to be conditional on compilation policy (i.e. (space 0)).
It also allows inline expansion to be done on a case-by-case basis ---
you can declare a function inline locally and get its inline expansion
there, but you don't need to have it expanded everywhere.
--
Fred Gilham ······@csl.sri.com
Do remember you're there to fuddle him. From the way some of you
young fiends talk, anyone would suppose it was our job to teach!
-- The Screwtape Letters, C. S. Lewis
* Chris Gehlker wrote:
> Figuring that I might as well reveal my ignorance of Lisp compilers rather
> than forcing you all to infer it from my use or non-use of inline, I decided
> to just ask. Does the current generation of Lisp compilers pay attention to
> inline at all? Do you proclaim functions inline or just trust your
> compilers?
Some do. I do occasionally declare stuff inline, mostly when I am
defining things which are accessor functions and which are essentially
syntactic sugar to disguise an implementation:
(declaim (inline tg-value tg-children (setf tg-value) (setf tg-children)))
(defun tg-value (node)
(car node))
(defun tg-children (node)
(cdr node))
...
--tim
On 11/18/02 7:35 AM, in article ···············@cley.com, "Tim Bradshaw"
<···@cley.com> wrote:
> * Chris Gehlker wrote:
>> Figuring that I might as well reveal my ignorance of Lisp compilers rather
>> than forcing you all to infer it from my use or non-use of inline, I decided
>> to just ask. Does the current generation of Lisp compilers pay attention to
>> inline at all? Do you proclaim functions inline or just trust your
>> compilers?
>
> Some do. I do occasionally declare stuff inline, mostly when I am
> defining things which are accessor functions and which are essentially
> syntactic sugar to disguise an implementation
[snip code]
This is good to know. I think it's just silly that all the C++ books, and
presumably the C++ instructors, teach inline and then the compilers just
ignore it. I've been informed by a guy who writes compilers for a living
that all the popular C++ compilers do ignore inline except for a few cases
when cross compiling.
If some of the Lisp compilers acknowledge inline, that justifies using it in
portable code.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
On 11/18/02 9:37 AM, in article ·············@isg.cs.uni-magdeburg.de,
"Jochen Schneider" <·····@isg.cs.uni-magdeburg.de> wrote:
> Allegro Common Lisp only inlines system functions:
>
> <http://www.franz.com/support/documentation/6.2/doc/compiling.htm#inline-ignor
> ed-2>
>
> Jochen
Well, props to Allegro for documenting what they do now and what they intend
to do. This seems like something that compiler users would want to know.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Chris Gehlker wrote:
> Figuring that I might as well reveal my ignorance of Lisp compilers rather
> than forcing you all to infer it from my use or non-use of inline, I decided
> to just ask. Does the current generation of Lisp compilers pay attention to
> inline at all? Do you proclaim functions inline or just trust your
> compilers?
I don't have enough information to answer this, but here is a little
sidenote. In my opinion, this is one of the things they have gotten
right in Java or, to be more specific, in the HotSpot Virtual Machine.
Function/procedure/method inlining should not happen at compile time,
but rather at run time. This has several advantages.
* You won't have any errors because of version mismatches. (They can
occur when you provide a new version of a function but don't recompile
the clients. When inlining is carried out by the runtime system, you can
be sure that the most current version is always used.)
* You can actually inline functions that cannot be inlined at compile
time. This is especially the case for methods or generic functions. At
compile time you have to anticipate that a method may be overridden in a
subclass, so you cannot inline it in the general case (unless it's final
or non-virtual, etc.). However, at run time you can determine whether a
method is actually overridden or not and inline methods even if they are
"virtual". Furthermore, HotSpot can de-optimize code, so it can even
inline methods that get overridden later on - it just reverts the method
to a not-inlined state.
For this reason, Java outperforms C++ for some benchmarks! (The main
reason why Java is still generally perceived to be slow is because of
the bloated Swing GUI library - but apart from that Java is quite fast.)
It would be nice if Common Lisp vendors would also forget about
compile-time inlining and adapt this technique. (BTW, this technology
was first invented for a Smalltalk implementation called Strongtalk -
see http://www.cs.ucsb.edu/projects/strongtalk/pages/index.html for
further information.)
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
On Mon, 18 Nov 2002, Pascal Costanza wrote:
[snip]
> It would be nice if Common Lisp vendors would also forget about
> compile-time inlining and adapt this technique. (BTW, this technology
> was first invented for a Smalltalk implementation called Strongtalk -
> see http://www.cs.ucsb.edu/projects/strongtalk/pages/index.html for
> further information.)
Actually, many of the ideas, and the spirit of the whole, came from the
Self project, though there were similar efforts for Oberon.
On tricky thing about such technology is that it seems *really* easy to
trade space for speed -- Self was a notorious memory hog. This probably
isn't the same issue today as it was then, of course.
Cheers,
Bijan Parsia.
* Pascal Costanza wrote:
> For this reason, Java outperforms C++ for some benchmarks! (The main
> reason why Java is still generally perceived to be slow is because of
> the bloated Swing GUI library - but apart from that Java is quite
> fast.)
I think that the main reason that Java `is slow' is that some
amazingly slow programs are written in it. This is actually the same
reason that CL `is slow'.
I recently had cause to look at Sun's `SMC' system - the Solaris
Management Console. Although it's rumoured to be better in versions
of the OS no-one has, somehow, quite seen, in the most recent Solaris
8 (02/02) it is so slow it's hard to imagine what it's doing. It
takes many minutes to start the first time you run it (on a ~400MHz
machine with 256MB, so not a fast machine, but fast enough to run
anything else (emacs, gnome, kde, whatever) fast enough for me), and
many seconds subsequent times. In its stable state it seems to take
about 70MB of memory (and seems to consume ~6% of the machine's
cycles, while idle) , during the initial startup it uses hundreds of
MB. The user interface is ... well, painfully slow but usable I
guess.
Somehow Java seems to have avoided being blamed for monsters like
this. Which is good, because I'm sure it isn't Java's fault: SMC is
just terribly, terribly badly written. Lisp, somehow, managed to get
blamed for some really terrible programs written in it. I think the
reason is that if you look at Java code, it's obviously `just like'
C++ so any real horrors must be bad programming, whereas if you look
at Lisp it isn't `just like' anything, so horrors might be due to
Lisp. Even some Lisp people occasionally seem to think this.
--tim
On Mon, Nov 18, 2002 at 05:59:02PM +0100, Pascal Costanza wrote:
> * You can actually inline functions that cannot be inlined at compile
> time. This is especially the case for methods or generic functions. At
> compile time you have to anticipate that a method may be overridden in a
> subclass, so you cannot inline it in the general case (unless it's final
> or non-virtual, etc.). However, at run time you can determine whether a
> method is actually overridden or not and inline methods even if they are
> "virtual". Furthermore, HotSpot can de-optimize code, so it can even
> inline methods that get overridden later on - it just reverts the method
> to a not-inlined state.
This is not true for Common Lisp, because even at runtime you can
compile new code, such as that for a new subclass and methods.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish <·······@andrew.cmu.edu> writes:
> On Mon, Nov 18, 2002 at 05:59:02PM +0100, Pascal Costanza wrote:
> > * You can actually inline functions that cannot be inlined at compile
> > time. This is especially the case for methods or generic functions. At
> > compile time you have to anticipate that a method may be overridden in a
> > subclass, so you cannot inline it in the general case (unless it's final
> > or non-virtual, etc.). However, at run time you can determine whether a
> > method is actually overridden or not and inline methods even if they are
> > "virtual". Furthermore, HotSpot can de-optimize code, so it can even
> > inline methods that get overridden later on - it just reverts the method
> > to a not-inlined state.
>
> This is not true for Common Lisp, because even at runtime you can
> compile new code, such as that for a new subclass and methods.
Re-read the last sentance of what you quoted from Pascal. Smalltalk
has pretty much the same features this way as Lisp does. It does
inlining as desired and de-inlining as needed. Really cool.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
On Mon, Nov 18, 2002 at 06:05:11PM -0800, Thomas F. Burdick wrote:
> Matthew Danish <·······@andrew.cmu.edu> writes:
>
> > On Mon, Nov 18, 2002 at 05:59:02PM +0100, Pascal Costanza wrote:
> > > * You can actually inline functions that cannot be inlined at compile
> > > time. This is especially the case for methods or generic functions. At
> > > compile time you have to anticipate that a method may be overridden in a
> > > subclass, so you cannot inline it in the general case (unless it's final
> > > or non-virtual, etc.). However, at run time you can determine whether a
> > > method is actually overridden or not and inline methods even if they are
> > > "virtual". Furthermore, HotSpot can de-optimize code, so it can even
> > > inline methods that get overridden later on - it just reverts the method
> > > to a not-inlined state.
> >
> > This is not true for Common Lisp, because even at runtime you can
> > compile new code, such as that for a new subclass and methods.
>
> Re-read the last sentance of what you quoted from Pascal. Smalltalk
> has pretty much the same features this way as Lisp does. It does
> inlining as desired and de-inlining as needed. Really cool.
My mistake, I was in a hurry and blew right past the sentence. I'm not
aware of a CL implementation that does this, do you know of one?
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish <·······@andrew.cmu.edu> writes:
> On Mon, Nov 18, 2002 at 06:05:11PM -0800, Thomas F. Burdick wrote:
> > Matthew Danish <·······@andrew.cmu.edu> writes:
> >
> > > On Mon, Nov 18, 2002 at 05:59:02PM +0100, Pascal Costanza wrote:
> > > > * You can actually inline functions that cannot be inlined at compile
> > > > time. This is especially the case for methods or generic functions. At
> > > > compile time you have to anticipate that a method may be overridden in a
> > > > subclass, so you cannot inline it in the general case (unless it's final
> > > > or non-virtual, etc.). However, at run time you can determine whether a
> > > > method is actually overridden or not and inline methods even if they are
> > > > "virtual". Furthermore, HotSpot can de-optimize code, so it can even
> > > > inline methods that get overridden later on - it just reverts the method
> > > > to a not-inlined state.
> > >
> > > This is not true for Common Lisp, because even at runtime you can
> > > compile new code, such as that for a new subclass and methods.
> >
> > Re-read the last sentance of what you quoted from Pascal. Smalltalk
> > has pretty much the same features this way as Lisp does. It does
> > inlining as desired and de-inlining as needed. Really cool.
>
> My mistake, I was in a hurry and blew right past the sentence. I'm not
> aware of a CL implementation that does this, do you know of one?
I wish :-( It's too bad Java's semantics are soooo restricted, or it
might be possible for a Lisp vendor to license HotSpot from Sun.
Alas, that would only get them part of the way there.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> I wish :-( It's too bad Java's semantics are soooo restricted, or it
> might be possible for a Lisp vendor to license HotSpot from Sun.
> Alas, that would only get them part of the way there.
I think one need look no further than the work on SELF to get
started. Say, Urs Hoelzle's thesis and/or various papers over the
years. (Also, PLDI'92 has a SELF paper on dynamic deoptimization,
which provided food for thought when I was studying the 'code
replacement' problem myself.)
Best,
Thomas
--
Thomas Lindgren
"Again, men in general desire the good, and not merely what their
fathers had." -- Aristotle (Politics)
Matthew Danish wrote:
> On Mon, Nov 18, 2002 at 05:59:02PM +0100, Pascal Costanza wrote:
>
>>* You can actually inline functions that cannot be inlined at compile
>>time. This is especially the case for methods or generic functions. At
>>compile time you have to anticipate that a method may be overridden in a
>>subclass, so you cannot inline it in the general case (unless it's final
>>or non-virtual, etc.). However, at run time you can determine whether a
>>method is actually overridden or not and inline methods even if they are
>>"virtual". Furthermore, HotSpot can de-optimize code, so it can even
>>inline methods that get overridden later on - it just reverts the method
>>to a not-inlined state.
>
>
> This is not true for Common Lisp, because even at runtime you can
> compile new code, such as that for a new subclass and methods.
You can do that as well in Java. (It's a bit more complicated than in
Common Lisp but it's possible.)
Assume you have classes c and d, with d being a subclass of c. When you
have a generic function m with two methods that specialize on c and d
respectively, you can still inline m for example as long as there are no
instances of d in the running system (or because of other dynamic
properties). It doesn't matter whether d exists upfront or is created
after the program has started.
Pascal
--
Given any rule, however �fundamental� or �necessary� for science, there
are always circumstances when it is advisable not only to ignore the
rule, but to adopt its opposite. - Paul Feyerabend
Chris Gehlker <·······@fastq.com> wrote in message news:<······················@fastq.com>...
>
> Figuring that I might as well reveal my ignorance of Lisp compilers rather
> inline at all? Do you proclaim functions inline or just trust your
> compilers?
I use CMUCL, and I inline all the time to avoid float boxing.
Otherwise, I couldn't really do numerical code in Lisp.
for example:
;; fast erf that doesn't box - put in a file and compile
#+cmu (def-alien-routine ("erf" erf) double (x-dbl double))
#+cmu (def-alien-routine ("erfc" erfc) double (x-dbl double))
#+cmu (declaim (inline erf erfc))
;;;;;;;;;;;;
(describe #'erf)
.... It is currently declared inline; expansion is available. ...
(time (dotimes (i 1000000) (erf 2d0))
...
Evaluation took:
1.64 seconds of real time
1.47 seconds of user run time
0.0 seconds of system run time
0 page faults and
48 bytes consed.
^^^ no consing!! ;)
········@yahoo.com (John Klein) wrote in message news:<····························@posting.google.com>...
>
> ;; fast erf that doesn't box - put in a file and compile
> #+cmu (def-alien-routine ("erf" erf) double (x-dbl double))
> #+cmu (def-alien-routine ("erfc" erfc) double (x-dbl double))
> #+cmu (declaim (inline erf erfc))
> ;;;;;;;;;;;;
A reader of this group kindly pointed out a correction to this;
(declaim (inline erf erfc)) must go first, of course.
········@yahoo.com (John Klein) writes:
> Chris Gehlker <·······@fastq.com> wrote in message news:<······················@fastq.com>...
> >
> > Figuring that I might as well reveal my ignorance of Lisp compilers rather
> > inline at all? Do you proclaim functions inline or just trust your
> > compilers?
>
> I use CMUCL, and I inline all the time to avoid float boxing.
> Otherwise, I couldn't really do numerical code in Lisp.
Inlining is not necessary to do foreign code efficiently in Lisp.
> for example:
>
> ;; fast erf that doesn't box - put in a file and compile
> #+cmu (def-alien-routine ("erf" erf) double (x-dbl double))
> #+cmu (def-alien-routine ("erfc" erfc) double (x-dbl double))
> #+cmu (declaim (inline erf erfc))
> ;;;;;;;;;;;;
At Franz, we took a different philosophy about what constitutes
inlining of foreign/alien code. I haven't looked at this example
in CMUCL, but I doubt that the actual contents of the "erf" function
(which was probably written in C) was actually duplicated inline
in the Lisp code. Rather, the erf lisp wrapper probably called
the erf (C) function directly instead of going through some
general-purpose foreign-calling interface (we call this ff-funcall
in Allegro CL). What is being inlined, then, is not the erf
function itself, but rather the _call_ to the erf function.
> (describe #'erf)
> .... It is currently declared inline; expansion is available. ...
>
> (time (dotimes (i 1000000) (erf 2d0))
> ...
> Evaluation took:
> 1.64 seconds of real time
> 1.47 seconds of user run time
> 0.0 seconds of system run time
> 0 page faults and
> 48 bytes consed.
> ^^^ no consing!! ;)
Allegro CL does the same, but we don't call it inlining, we call
it what we consider a more descriptive name "call-direct"
CL-USER(1): (ff:def-foreign-call erf ((x :double)) :returning :double
:call-direct t :arg-checking nil)
ERF
CL-USER(2): (compile (defun testit ()
(dotimes (i 1000000) (erf 2d0))))
TESTIT
NIL
NIL
CL-USER(3): (time (testit))
; cpu time (non-gc) 350 msec user, 0 msec system
; cpu time (gc) 0 msec user, 0 msec system
; cpu time (total) 350 msec user, 0 msec system
; real time 354 msec
; space allocation:
; 0 cons cells, 0 other bytes, 0 static bytes
NIL
CL-USER(5):
[ If you have responses for me, I may not answer for a couple of
weeks, since I am on vacation starting today for the next two weeks.
Talk to you then.]
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> ········@yahoo.com (John Klein) writes:
>
> > Chris Gehlker <·······@fastq.com> wrote in message news:<······················@fastq.com>...
> > >
> > > Figuring that I might as well reveal my ignorance of Lisp compilers rather
> > > inline at all? Do you proclaim functions inline or just trust your
> > > compilers?
> >
> > I use CMUCL, and I inline all the time to avoid float boxing.
> > Otherwise, I couldn't really do numerical code in Lisp.
>
> Inlining is not necessary to do foreign code efficiently in Lisp.
>
> > for example:
> >
> > ;; fast erf that doesn't box - put in a file and compile
> > #+cmu (def-alien-routine ("erf" erf) double (x-dbl double))
> > #+cmu (def-alien-routine ("erfc" erfc) double (x-dbl double))
> > #+cmu (declaim (inline erf erfc))
> > ;;;;;;;;;;;;
>
... snipped ...
>
> > (describe #'erf)
> > .... It is currently declared inline; expansion is available. ...
> >
> > (time (dotimes (i 1000000) (erf 2d0))
> > ...
> > Evaluation took:
> > 1.64 seconds of real time
> > 1.47 seconds of user run time
> > 0.0 seconds of system run time
> > 0 page faults and
> > 48 bytes consed.
> > ^^^ no consing!! ;)
>
> Allegro CL does the same, but we don't call it inlining, we call
> it what we consider a more descriptive name "call-direct"
>
> CL-USER(1): (ff:def-foreign-call erf ((x :double)) :returning :double
> :call-direct t :arg-checking nil)
> ERF
> CL-USER(2): (compile (defun testit ()
> (dotimes (i 1000000) (erf 2d0))))
> TESTIT
> NIL
> NIL
> CL-USER(3): (time (testit))
> ; cpu time (non-gc) 350 msec user, 0 msec system
> ; cpu time (gc) 0 msec user, 0 msec system
> ; cpu time (total) 350 msec user, 0 msec system
> ; real time 354 msec
> ; space allocation:
> ; 0 cons cells, 0 other bytes, 0 static bytes
> NIL
> CL-USER(5):
As
1. Google keeps things for a long time,
2. There is no infomation on machines on which these 2 timing runs
were done,
3. The DECLAIM for the CMUCL timing code should come first, which
has already been pointed out, and
4. Results of these 2 timing runs do not match my experience with
ACL and CMUCL,
I did the timing runs on CMUCL (18d) and ACL (6.2 Trial) on the same
machine (a 750MHz Linux notebook) just for the record:
;;---------------------- CMUCL ----------------------
;; CMUCL: save the following in a file, compile, and load it.
(use-package :c-call :alien)
(declaim (inline erf erfc))
(def-alien-routine ("erf" erf) double (x-dbl double))
(def-alien-routine ("erfc" erfc) double (x-dbl double))
USER> (time (dotimes (i 1000000) (erf 2d0)))
Compiling LAMBDA NIL:
Compiling Top-Level Form:
Evaluation took:
0.91 seconds of real time
0.91 seconds of user run time
0.0 seconds of system run time
0 page faults and
0 bytes consed.
NIL
(time (dotimes (i 1000000) (erf 2d0)))
Compiling LAMBDA NIL:
Compiling Top-Level Form:
Evaluation took:
0.91 seconds of real time
0.9 seconds of user run time
0.01 seconds of system run time
0 page faults and
0 bytes consed.
NIL
;;---------------------- ACL ----------------------
CL-USER(1): (ff:def-foreign-call erf ((x :double)) :returning :double
:call-direct t :arg-checking nil)
ERF
CL-USER(2): (compile (defun testit ()
(dotimes (i 1000000) (erf 2d0))))
TESTIT
NIL
NIL
CL-USER(3): (time (testit))
; cpu time (non-gc) 840 msec user, 0 msec system
; cpu time (gc) 0 msec user, 0 msec system
; cpu time (total) 840 msec user, 0 msec system
; real time 846 msec
; space allocation:
; 0 cons cells, 0 other bytes, 0 static bytes
NIL
CL-USER(4): (time (testit))
; cpu time (non-gc) 850 msec user, 0 msec system
; cpu time (gc) 0 msec user, 0 msec system
; cpu time (total) 850 msec user, 0 msec system
; real time 850 msec
; space allocation:
; 0 cons cells, 0 other bytes, 0 static bytes
NIL
CL-USER(5):
Chisheng Huang <···@chi-square-works.com> writes:
> As
> 1. Google keeps things for a long time,
> 2. There is no infomation on machines on which these 2 timing runs
> were done,
Therefore, you should not be concerned about the timings, as they
had nothing to do with the point.
> 3. The DECLAIM for the CMUCL timing code should come first, which
> has already been pointed out, and
> 4. Results of these 2 timing runs do not match my experience with
> ACL and CMUCL,
> I did the timing runs on CMUCL (18d) and ACL (6.2 Trial) on the same
> machine (a 750MHz Linux notebook) just for the record:
[ ... ]
and it looks like you got vitrually the same times, right? But in
looking so carefully at timings, you missed my point, which I believe
I said succinctly here:
> > Allegro CL does the same, but we don't call it inlining, we call
> > it what we consider a more descriptive name "call-direct"
and which has nothing to do with the timings.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> wrote in message news:<·············@beta.franz.com>...
> ········@yahoo.com (John Klein) writes:
> >
> > I use CMUCL, and I inline all the time to avoid float boxing.
> > Otherwise, I couldn't really do numerical code in Lisp.
>
> Inlining is not necessary to do foreign code efficiently in Lisp.
>
[snip example of efficient FFI calling in ACL]
Hello,
Perhaps using a FFI call was a red herring on my part. I meant
to illustrate not the issue FFI efficiency in CMUCL, but rather the utility
of using inline declarations in writing numerical code
that doesn't cons, something that is critical for the code I write.
I used the erf example because it showed in two lines
how one could incorporate a function from the math library,
and have it work just as efficiently as built-ins like sin and
cos. I could have also used erf written in lisp but the example
would have been more tedious. Sorry for the confusion.