It seems to me that in-lining a function of any significant length is very
likely to be a mistake, though I suppose it depends on the memory cache
management.  If the in-lining is done to remove consing, then perhaps the
solution is to address the consing itself.  I don't know the exact
circumstances of the needed optimization, but if it is arithmetic-related,
perhaps this can be done by stack allocation of temporary numbers.  I
haven't tried timing of ACL2 in Allegro Common Lisp, but it might be
revealing to do so.  It is my understanding that Allegro mostly, if not
entirely, ignores inline declarations of user-defined functions.
I have been told that this was a deliberate decision after a careful
consideration of the semantic consequences of inlining to the CL standard
versus the expected gain in performance.

RJF


> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Raymond Toy
> Sent: Friday, July 06, 2007 1:55 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; Camm Maguire; Robert Dodier; Matt 
> Kaufmann; [EMAIL PROTECTED]; axiom-developer@nongnu.org
> Subject: Re: [Maxima] gcl inlining policy
> 
> [EMAIL PROTECTED] wrote:
> >> As for space optimization I'm not sure it matters. I can't 
> think of a
> > case where inlining will happen so many times that space is 
> an issue.
> > Who writes a function with 50 mapcars? For space 
> optimization it might
> > be better to throw away the cached sources.
> 
> Here is an example where there is LOTS of inlining.  CMUCL supports 
> double-double floats and has support for unboxed 
> double-double floats. 
> However, to make things fast, the code that implements the basic 
> arithmetic operations is inlined.  So the routine that 
> calculates log(x) 
> via rational approximation has inlined lots of routines, 
> perhaps 50 or 
> more arithmetic operations.  A double-double add takes about 
> 200 bytes. 
>   The space used is a lot.
> 
> I also have a quad-double implementation.  That is even 
> larger because a 
> quad-double operation is some 1K bytes long.  But if you don't inline 
> the basic arithmetic function and all the internal functions that are 
> needed to implement it, the consing slows down the operation by a 
> significant fraction (half or more?).  To make these inline, I had to 
> increase CMUCL's inlining threshold to 1600 (the  upper limit on the 
> number of inline function calls that will be expanded in any 
> given code 
> object).
> 
> Anyway, this is really way off topic for maxima, so I will 
> refrain from 
> saying more on this list.
> 
> Ray
> _______________________________________________
> Maxima mailing list
> [EMAIL PROTECTED]
> http://www.math.utexas.edu/mailman/listinfo/maxima
> 



_______________________________________________
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer

Reply via email to