[comp.lang.lisp] Followup to The BEST way to sum

rogers@orion.SRC.Honeywell.COM (Brynn Rogers) (10/26/88)

 Thanks to everyone who responded. I posted this problem not
 because of any great need for speed, but to learn the best way
 to program.

(setq nn '(1 2 3 4 5 6 7 8 9 10 11 12 13 14 15))
(everything was wrapped in (dotimes (x 20000) (testalgorithm)) and compiled.
results with TIME function:
algorithm          time
---------          ----
(apply #'+ nn)     4.18 
(dolist ...)       4.22
recursive sum      8.35
(eval (cons '+ nn) 8.40
(reduce #'+ nn)   16.75

The dolist and the apply came in first with virtually the same time
The recursive sum function surprised me (but not some who responded)
 by being so fast.
I don't know why reduce was slow.

I am going to use the apply function because it is the most elegant.
I realize that how good the compiler is the major determineing factor here.

Thanks for responding!
                      Brynn Rogers rogers@src.honeywell.com
P.S. we have clocked GC COMMON LISP on our 386/20 to be about
1/4 the speed of a Symbolics 3640 machine (at 1/40 the price approx.)
(this was a Very rough comparison. Someday I'll clock it against the SUNs)

welty@steinmetz.ge.com (richard welty) (10/28/88)

In article <10848@srcsip.UUCP> rogers@orion.UUCP (Brynn Rogers) writes:

>P.S. we have clocked GC COMMON LISP on our 386/20 to be about
>1/4 the speed of a Symbolics 3640 machine (at 1/40 the price approx.)
>(this was a Very rough comparison. Someday I'll clock it against the SUNs)

Ummmm ... I feel obligated to list some `standard' comments about overly
simplistic benchmarking -- your ``very rough comparison'' remark is
perhaps too kind.

Did you push the machine into paging or garbage collection?  have you
run any truly large applications?  Did you have debugging disabled?
How does having debugging on affect the speed of the 386 machine?
How good is the debugging when it is on (does it have an inspector
or a display debugger?  Can you link in new definitions in compiled
code in a current environment and continue, or change data structures
in a current environment?)  Can you handle truly large data sets on
it? (I work in a vision shop, and commonly encounter 4k x 4k 8 bit
images -- I don't know many machines besides the symbolics that
won't barf when you try to handle such data items in lisp.)

Also, remember that the 3640 is no longer on the symbolics price lists,
and comparing to an obsolescent machine instead of the current models
is a might unfair.

I understand that for your applications, the comparison may be useful;
it's just that this exactly the sort of stuff that ge managers shovel
at us every time we ask for more symbolics machines (``but the sun 4
is faster -- wouldn't you rather have one of those?'')

richard w
-- 
richard welty      518-387-6346, GE R&D, K1-5C39, Niskayuna, New York
                   welty@ge-crd.ARPA            uunet!steinmetz!welty
``The fun never sets on the British Empire''