[Top][All Lists]
[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