Re: Floating-point performance

The consing you see is from the uncompiled loop in the test function.  I 
guess 7.0 is smarter about this.

In general, the ACL compiler is fast and does a decent god, but I don't 
believe it spends a lot of time deducing types, etc., which the CMU 
compiler does.  You can sometimes improve ACL performance by slipping in 
a declaration of something the compiler should know.  E.g., it seems to 
me that declaring the index of the dotimes loop in daxpy to be a fixnum 
improves performance about 25% or more.  You might be able to speed it 
up a bit more with things like this, which may or may not be worth your 
time.

Yours,
RW

Ernst van Waning wrote:

> Hello Nicolas,
> 
> Not that this answers your question, but someone else's results may be
> informative.
> 
> Just ran your code exectly as you sent it in ACLv7 (International Allegro CL
> Professional Edition 7.0 [Windows] (May 11, 2005 17:38)).  The results were:
> 
> ; cpu time (non-gc) 1,783 msec user, 10 msec system
> ; cpu time (gc)     0 msec user, 0 msec system
> ; cpu time (total)  1,783 msec user, 10 msec system
> ; real time  2,113 msec
> ; space allocation:
> ;  12 cons cells, 240,000 other bytes, 0 static bytes
> ; cpu time (non-gc) 2,303 msec user, 10 msec system
> ; cpu time (gc)     0 msec user, 0 msec system
> ; cpu time (total)  2,303 msec user, 10 msec system
> ; real time  2,794 msec
> ; space allocation:
> ;  12 cons cells, 0 other bytes, 0 static bytes
> 
> The results above show much less consing than what you reported.  I don't
> know why this is, but it may have to do with the version of Allegro you have
> used.
> 
> My machine is a HP omnibook xe 4500, with a 1.6Mhz processor and 256Mb of
> RAM (of which 286Mb was in use) running Windows XP Professional.  Test with
> an "empty" machine (253 Mb in use) gave very similar results.
> 
> To have some way to compare runtime results, it may be good if you include
> your FLOP-counter in your code.
> 
> For the rest, I don't see any glaring omissions that could speed up your
> code :-)
> 
> Kind regards,
> 
> Ernst van Waning
> 
> 
>>-----Original Message-----
>>From: Nicolas Neuss [mailto:[email protected]]
>>Sent: 09 May 2005 23:07
>>To: [email protected]
>>Subject: Floating-point performance
>>
>>
>>Hello, Allegro experts,
>>
>>I am just testing if Allegro CL would be a suitable host for
>>my PDE simulation tool Femlisp.  One necessity would be that 
>>floating point arithmetic is fast.  I assume that Allegro is 
>>able to satisfy this need, because I remember an earlier 
>>article of Richard Fateman reporting fast fp arithmetic with 
>>Allegro.  However, at the moment I observe a factor 5 of 
>>speed between Allegro and CMUCL.  Which declaration do I 
>>miss?  I have played around a bit with (declare (:explain 
>>:calls :types)) but unfortunately with little insight.
>>
>>Thank you for any information,
>>
>>Nicolas.
>>
>>--------------------------------------------------------------
>>-------------
>>The test code and the timing results:
>>--------------------------------------------------------------
>>-------------
>>(let ((ddot
>>       (compile nil
>>                (lambda (x y n)
>>                  (declare (type fixnum n)
>>                           (type (simple-array double-float (*)) x y))
>>                  (declare (optimize (safety 0) (space 0)
>>(debug 0) (speed
>>       3)))
>>                  (loop for i of-type fixnum from 0 below n
>>                     summing (* (aref x i) (aref y i)) of-type
>>       double-float))))
>>      (daxpy
>>       (compile nil
>>                (lambda (x y n)
>>                  (declare (type fixnum n)
>>                           (type (simple-array double-float (*)) x y))
>>                  (declare (optimize (safety 0) (space 0) 
>>(debug 0) (speed
>>       3)))
>>                  (dotimes (i n)
>>                    (incf (aref y i) (* 3.0d0 (aref x i))))))))
>>  (let* ((size 10000) (repetitions (/ 100000000 size))
>>         (a (make-array size :element-type 'double-float 
>>:initial-element
>>       0.0d0))
>>         (b (make-array size :element-type 'double-float 
>>:initial-element
>>       0.0d0)))
>>    (flet ((test (f)
>>             (time (loop repeat repetitions do (funcall f a b 
>>size)))))
>>      (test ddot)
>>      (test daxpy))))
>>
>>;;;; CMUCL results
>>
>>; Evaluation took:
>>;   1.07 seconds of real time
>>;   0.99 seconds of user run time
>>;   0.0 seconds of system run time
>>;   640,581,017 CPU cycles
>>;   0 page faults and
>>;   1,120,104 bytes consed.
>>
>>; Evaluation took:
>>;   1.4 seconds of real time
>>;   1.34 seconds of user run time
>>;   0.0 seconds of system run time
>>;   840,576,216 CPU cycles
>>;   0 page faults and
>>;   960,104 bytes consed.
>>;
>>
>>;;;; Allegro results
>>
>>; cpu time (non-gc) 5,620 msec user, 0 msec system
>>; cpu time (gc)     40 msec user, 0 msec system
>>; cpu time (total)  5,660 msec user, 0 msec system
>>; real time  5,831 msec
>>; space allocation:
>>;  160,123 cons cells, 240,256 other bytes, 7,832 static
>>bytes ; cpu time (non-gc) 8,220 msec user, 0 msec system
>>; cpu time (gc)     10 msec user, 0 msec system
>>; cpu time (total)  8,230 msec user, 0 msec system
>>; real time  8,454 msec
>>; space allocation:
>>;  160,123 cons cells, 232 other bytes, 0 static bytes
>>
>>
> 
> 

-- 
Robert Wilensky
Professor
Computer Science Division
721 Soda Hall
University of California, Berkeley
Berkeley, CA 94720
http://http.cs.berkeley.edu/~wilensky