[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: speed up for array ops
In article <199212032049.AA08624@tigger.cs.colorado.edu> Repenning
Alexander, ralex@tigger.cs.colorado.edu writes:
>On my MacII this reduced the time from about 11 secs to 4.2 secs. The no
ABS
>versions took only 2.5 secs, i.e., ABS is expensive (about 13 us).
>(declare (optimize (speed 3) (safety 0))) had almost no influence, it
would
>have with svref.
>
>I've tried a version using vector-pop which was disapointingly slow. What
>good are fill pointers (besided keeping track of the pointer) when
VECTOR-POP
>is not any faster than AREF?
>
>I'm sure there are better solutions to this using some low-level MCL
stuff,
>oh well..
I discovered that converting the whole array to a list was worth the
extra expense:
(defun a-to-list (a)
"makes a list out of any array"
(coerce
(make-array (array-total-size a)
:displaced-to a
:element-type (array-element-type a))
'list))
(defun listlim (numlist)
"Returns the maximum and minimum values of a list of complex numbers."
(let* ((amax (abs (first numlist)))
(amin amax))
(mapc #'(lambda (z)
(setq z (abs z))
(cond ((> z amax) (setq amax z))
((< z amin) (setq amin z))))
numlist)
`((min ,amin)(max ,amax))))
The result then was:
? (progn (setq al (time (a-to-list a))) nil)
(A-TO-LIST A) took 189 milliseconds (0.189 seconds) to run.
500032 bytes of memory allocated.
NIL
? (time (listlim al))
(LISTLIM AL) took 1599 milliseconds (1.599 seconds) to run.
Of that, 66 milliseconds (0.066 seconds) were spent in The Cooperative
Multitasking Experience.
500056 bytes of memory allocated.
((MIN 0.025495097567963924) (MAX 14.099709500553548))
As a comparasion, a function similar to the one suggested by Alexander
above ran in 2.0 seconds under the same circumstances (Quadra 700,
randomly generated 250x250 (complex float) array) (and allocated half a
megabyte of memory)
So even with the overhead of generating half a megabyte unnecessary
conses included, the runtime of the list version was 10% lower.
Does this mean that MCLs AREF is slower than it ought to be?
--------------------------------------------------------------
Espen J. Vestre, espen@coli.uni-sb.de
Universitaet des Saarlandes,
Computerlinguistik, Gebaeude 17.2
Im Stadtwald, tel. +49 (681) 302 4501
D-6600 SAARBRUECKEN, Germany fax. +49 (681) 302 4351
--------------------------------------------------------------