help links subscribe changes refresh edit

	IssueTracker
#362 lower bound in a loop must be an integer ←	↑	→ #364 coerce is missing from domain Expression

#363 A slow summation

Edit detail for #363 A slow summation revision 1 of 1

	1
Editor: Time: 2007/11/17 22:33:21 GMT-8
Note: thank you Waldek

changed:
-
**On 6/13/07, Alasdair !McAndrew wrote:**

Wondering about nice little numeric exercises to help introduce Axiom to a
small group of students, I attempted to sum the first 20000 reciprocals:

\begin{axiom}
)set message time on
reduce(+,[1.0/i for i in 1..20000])
\end{axiom}
 
This works, but is (I think) unreasonably slow; it takes over 21 seconds
on my computer.  The equivalent command in Maxima takes less than 1 second.
Is there any way of encouraging Axiom to be faster here? 


**On 6/16/07, Waldek Hebisch wrote:**

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
 > >
 > 
 > 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.
 >
 
As I wrote, it turned out that GCL interpreter is quite fast.  After
using modified LIST2VEC function (patch below, applied to wh-sandbox),

I get the following timings::
 
  reduce(+,[1.0/i for i in 1..20000])    0.69
  [i for i in 1..20000];                 0.09
 
It seems that now significant part of execution time goes into
floating point arithmetic.

\begin{lisp}
(defun LIST2VEC (list)
    (if (consp list)
        (let* ((len (length list))
               (vec (make-array len)))
             (dotimes (i len)
                  (setf (aref vec i) (pop list)))
             vec)
        (coerce list 'vector)))

(define-function 'LIST2REFVEC #'LIST2VEC)
\end{lisp}

\begin{axiom}
reduce(+,[1.0/i for i in 1..20000])
\end{axiom}

\begin{axiom}
[i for i in 1..20000];
\end{axiom}


From billpage Sat Jun 16 14:25:41 -0500 2007
From: billpage
Date: Sat, 16 Jun 2007 14:25:41 -0500
Subject: thank you Waldek
Message-ID: <20070616142541-0500@wiki.axiom-developer.org>

Category: Aldor Library Compiler => Axiom Interpreter 
Status: open => fix proposed

On 6/13/07, Alasdair McAndrew wrote:

Wondering about nice little numeric exercises to help introduce Axiom to a small group of students, I attempted to sum the first 20000 reciprocals:

axiom

)set message time on

reduce(+,[1.0/i for i in 1..20000])

$\label{eq1}10.480728217229327571$

(1)

Type: Float

axiom

Time: 0.19 (IN) + 1.72 (EV) + 0.12 (OT) = 2.03 sec

This works, but is (I think) unreasonably slow; it takes over 21 seconds on my computer. The equivalent command in Maxima takes less than 1 second. Is there any way of encouraging Axiom to be faster here?

On 6/16/07, Waldek Hebisch wrote:

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

As I wrote, it turned out that GCL interpreter is quite fast. After using modified LIST2VEC function (patch below, applied to wh-sandbox),

I get the following timings:

  reduce(+,[1.0/i for i in 1..20000])    0.69
  [i for i in 1..20000];                 0.09

It seems that now significant part of execution time goes into floating point arithmetic.

lisp

(defun LIST2VEC (list)
    (if (consp list)
        (let* ((len (length list))
               (vec (make-array len)))
             (dotimes (i len)
                  (setf (aref vec i) (pop list)))
             vec)
        (coerce list 'vector)))

(define-function 'LIST2REFVEC #'LIST2VEC)

lisp

; compiling file "/var/zope2/var/LatexWiki/1444083084317242284-25px002.lisp" (written 06 JUL 2011 10:18:55 AM):

; /var/zope2/var/LatexWiki/1444083084317242284-25px002.fasl written
; compilation finished in 0:00:00.290
Value = T

axiom

reduce(+,[1.0/i for i in 1..20000])

$\label{eq2}10.480728217229327571$

(2)

Type: Float

axiom

Time: 2.90 (EV) + 0.01 (OT) = 2.91 sec

axiom

[i for i in 1..20000];

Type: List(PositiveInteger?)

axiom

Time: 1.08 (EV) = 1.08 sec

thank you Waldek --billpage, Sat, 16 Jun 2007 14:25:41 -0500 reply

Category: Aldor Library Compiler => Axiom Interpreter Status: open => fix proposed