axiom-developer
[Top][All Lists]
Advanced

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

[Axiom-developer] Re: [Axiom-mail] A slow summation


From: Camm Maguire
Subject: [Axiom-developer] Re: [Axiom-mail] A slow summation
Date: 15 Jun 2007 21:22:25 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!  Very interesting -- needless to say, I'm very interested
in GCL performance.

Can you possible provide the raw lisp code in use here?  I'd be happy
to take a look.  

2.7.0 has immediate fixnums which doutless will make a huge difference
    here. 

Take care,

Waldek Hebisch <address@hidden> writes:

> Bill Page wrote:
> > On 6/15/07, Waldek Hebisch wrote:
> > > On my machine, I get the following (on the second run, to
> > > exclude time for loading):
> > >
> > >                                       gcl      sbcl          sbcl
> > >                                              interpreted  compiled
> > >  reduce(+,[1.0/i for i in 1..20000])   8.70      1.76        0.17
> > >  [i for i in 1..20000];                6.23      0.78        0.01
> > >  expand(1..20000);                     0         0.004       0.01
> > >
> > > Comment: sbcl evaluator has two modes of operation: interpreted
> > > and compiled.  In compiled mode the code is first compiled and
> > > then the resulting machine code is run.  One can switch mode
> > > setting variable sb-ext:*evaluator-mode*:
> > >
> > > )lisp (setf sb-ext:*evaluator-mode* :compile)
> > >
> > > or
> > >
> > > )lisp (setf sb-ext:*evaluator-mode* :interpret)
> > >
> > > sbcl profiler showed that 98% of time were spent in Lisp evaluator,
> > > and that agrees very well with getting much higher speed using
> > > compiled mode.
> > >
> > 
> > Waldek, thank you very much for running this comparison!
> > 
> > So, the conclusion might be that I was wrong: the slowness *is*
> > because of the way that Axiom interpreter runs this code in
> > interpreted mode in GCL, right? It could still be that this interpreted
> > Lisp code is not written in an optimal manner.
> >
> 
> It seems that the code is suboptimal and probably wrong.  IIUC
> in:
> 
>  [1.0/i for i in 1..20000]
> 
> i should be local.  But Lisp code generated by Axiom accesses global
> Lisp variable i.  Making variables local may speed up this code.
> But OTOH compiled code is reasonably fast, and both sbcl and
> clisp show that the code can be interpreted few times faster.
>  
> > Maybe it is possible in GCL with some additional coding to also
> > convince GCL to compile the code first before executing it?
> > I know that Axiom includes the command:
> > 
> >   )set function compile on/off
> > 
> > that affects compilation of user defined functions in the interpreter.
> > Perhaps this can be extended to the [... for ... ] case?
> > 
> 
> Well, I think it is not hard to compile _everything_.  But compilation
> not always wins, one has to add compile time to execution time
> and especially with GCL compilation may take substantial time.
> For one-shot code (executed just once, without loops) compilation
> will almost certainly loose.  Axiom generate a lot of such
> one-shot pieces of code and evaluates them.  So it is not clear
> if compilation is better.  In fact, I switched sbcl to use
> interpreted mode, because this gives significant savings during
> bootstrap...
> 
> BTW: one can see effect of compilation in GCL using alternate
> formulation of the problem.  Namely, Axiom compiles recurence
> relations.  So one can define the following reccurence relations:
> 
> f(1, a) == 1.0 + a
> f(n, a) == f(n - 1, a + 1.0/n)
> 
> and then call:
> 
> f(20000, 0.0)
> 
> -- 
>                               Waldek Hebisch
> address@hidden 
> 
> 
> 

-- 
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]