This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Ballparks (was Re: Making Guile slower (3.4 and 6.7%))

Jim Blandy <jimb@red-bean.com> writes:

> If Guile's performance were within 10% of the top Scheme interpreters,
> then I would worry about changes like this.  But we're not even in the
> ballpark.

I've made several mistakes in this debate about how to make changes to
the infrastructure of Guile.  One is that, in the defense of what I
think are good principles (not in conflict with other good principles
such as maintainability and readability), Greg Badros, who is a very
bright person and a very skilled programmer, and who has indeed made a
very important software engineering face-lift of Guile, has become the
target of criticism unnecessarily amplified through all repetition of
arguments in this discussion.  He has made a great effort with the
goal of improving Guile---and has received mostly blame for it.

Now I'm about to make yet a mistake, but I can't resist doing it.
Strange as it may seem, I also share the values of maintainability and
readability, and have no problems with sometimes paying in performance
in order to preserve or achieve these other values.  (I _am_
responsible for some really terrible code in Guile, but want to blame
that on limited capacity, or, limited experience at the time it was
made.)  I've been trying to argue about principles, and have been
trying to point out that we are now unnecessarily paying because we
are not following those principles.

I really don't want to be perceived as a speed maniac (maniac alone is
fine---can hardly refute that after this mess).  So, it is bad tactics
now to talk about speed.

I would argue that we _are_ in the ballpark of the top Scheme
interpreters.  Look at the benchmark below.  Guile is fundamentally
efficient but has problems showing it due to some easily fixed
problems such as mallocating every single float and evaluating a
chain of Scheme procedure for every symbol lookup.

I'm no mind reader but it is my guess that you have the feeling that
the increasing gap between Guile and SCM performance is mostly due to
slowing down of Guile.  I don't think that's the case.  Guile has,
e.g., been slightly faster than RScheme ever since RScheme was
released.  The increased gap is because the SCM evaluator has evolved
while the Guile evaluator has been frozen---because we have had and
have more important things to work upon right now than performance.
(But this is no excuse not trying to _preserve_ Guile's good
performance.)  The nice thing is that there's no fundamental
architectural problems which prevents us from following SCM if we
should wish that.

But it might be better to put that kind of efforts into constructing
an entirely new interpreter.

With great respect,
/mdj



Nicolas Neuss <Nicolas.Neuss@IWR.Uni-Heidelberg.De> writes:

> Elk's performance seemed to me better than Guile's.  The reason was
> probably a personal decision of Tom Lord, who knew Aubrey Jaffer and
> collaborated with him at the time of Guile's foundation.  (This is
> also from Laumann's email, maybe others know better.)

Elk's performance has always been lower than SCM's.  (Guile is based
upon SCM.)  But performance was not the only argument for basing Guile
on SCM.  Portability was another argument, e.g.

I made a simple experiment.  The procedure `prime' below computes the
Nth prime number.  The algorithm is inefficient but I think the code
has a pretty natural blend of common Scheme program operations.
The procedure `test' counts the number of times the 100th prime has
been calculated.

I tested how many times different Scheme interpreters on my machine
(Dell Inspiron 7000 with 333MHz Pentium II) could find the 100th prime
in one minute.  Notice the good performance of SCM.  It is interesting
to note that most improvements which have made SCM this fast can
reasonably easily be transferred to Guile since SCM and Guile have
very similar acrhitectures.

Interpreter		Turns/minute (high number good)
-----------		-------------------------------
SCM 5d0			678
Guile 1.3.4		442
RScheme 0.7.2		334
Elk 3.0			170

;;; Code:

;; Uncomment this for Guile
;; (debug-disable 'debug)

;; Uncomment this for Elk
;; (set! garbage-collect-notify? #f)

(define (prime n)
  (letrec ((prime? (lambda (n primes)
		     (or (null? primes)
			 (and (not (zero? (remainder n (car primes))))
			      (prime? n (cdr primes)))))))
    (let loop ((i 2) (candidate 2) (primes '()))
      (cond ((not (prime? candidate primes))
	     (loop i (+ 1 candidate) primes))
	    ((= i n) candidate)
	    (else
	     (loop (+ 1 i) (+ 1 candidate) (cons candidate primes)))))))

(define (test)
  (let loop ((count 1))
    (prime 100)
    (display count)
    (newline)
    (loop (+ 1 count))))

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]