unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* Enormous benchmark speedup
@ 2009-07-01 14:48 Juhani Viheräkoski
  2009-07-01 22:47 ` Ludovic Courtès
  2009-07-02 15:49 ` Juhani Viheräkoski
  0 siblings, 2 replies; 6+ messages in thread
From: Juhani Viheräkoski @ 2009-07-01 14:48 UTC (permalink / raw)
  To: guile-devel

[-- Attachment #1: Type: TEXT/PLAIN, Size: 987 bytes --]

Hi,

With recent changes in guile vm there are lots on improvements on 
the Gambit benchmarks. In the worst case some test run 10% slower but there
are huge wins in testcases involving vectors offsetting this. Here are 
*some* of the highlights:

triangl:
-15.57user 0.04system 0:15.72elapsed 99%CPU
+6.69user 0.02system 0:06.73elapsed 99%CPU

fft:
-59.16user 0.14system 0:59.89elapsed 99%CPU
+36.50user 0.07system 0:36.68elapsed 99%CPU

nucleic:
-38.99user 0.31system 0:39.30elapsed 99%CPU 
+24.54user 0.27system 0:24.85elapsed 99%CPU

pnpoly:
-85.52user 0.11system 1:25.69elapsed 99%CPU
+38.64user 0.05system 0:38.82elapsed 99%CPU

array1:
-65.91user 0.31system 1:06.51elapsed 99%CPU
+13.66user 0.25system 0:13.95elapsed 99%CPU

However the following testcase does not run when compiled, all the others 
work fine atm (source code attached):

ack:
guile: uncaught throw to vm-error: (vm-run "VM: Stack overflow" ())

Best Regards,
Juhani Viheräkosi

[-- Attachment #2: Type: TEXT/PLAIN, Size: 142 bytes --]

(define (ack m n)
  (cond ((= m 0) (+ n 1))
        ((= n 0) (ack (- m 1) 1))
        (else (ack (- m 1) (ack m (- n 1))))))

(ack 3 9)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Enormous benchmark speedup
  2009-07-01 14:48 Enormous benchmark speedup Juhani Viheräkoski
@ 2009-07-01 22:47 ` Ludovic Courtès
  2009-07-02 15:49 ` Juhani Viheräkoski
  1 sibling, 0 replies; 6+ messages in thread
From: Ludovic Courtès @ 2009-07-01 22:47 UTC (permalink / raw)
  To: guile-devel

Hi!

Juhani Viheräkoski <moonshine@kapsi.fi> writes:

> With recent changes in guile vm there are lots on improvements on the
> Gambit benchmarks.

Improvements compared to what?

> In the worst case some test run 10% slower

Slower than what?

> but there are huge wins in testcases involving vectors offsetting
> this.

Oh, that's cool, but it feels like we're slightly cheating on these.
;-)

> (define (ack m n)
>   (cond ((= m 0) (+ n 1))
>         ((= n 0) (ack (- m 1) 1))
>         (else (ack (- m 1) (ack m (- n 1))))))
>
> (ack 3 9)

This is not tail-recursive (because of the nested `ack' call in the
`else' clause), which is why it can lead to a stack overflow.

I'm too stupid to compute the maximum "depth" of the call graph, but it
looks like this:

  (ack 3 9)
    (ack 3 8) <--- X
      (ack 3 7)
        ...
          (ack 3 0)
            (ack 2 0)
              ...
                (ack 0 0)
    (ack 2 X)
      (ack 2 (- X 1))  <--- Y
        ...
      (ack 1 Y)
        (ack 1 (- Y 1))
          ...

Thanks,
Ludo'.





^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Enormous benchmark speedup
  2009-07-01 14:48 Enormous benchmark speedup Juhani Viheräkoski
  2009-07-01 22:47 ` Ludovic Courtès
@ 2009-07-02 15:49 ` Juhani Viheräkoski
  2009-07-23 21:26   ` Andy Wingo
  1 sibling, 1 reply; 6+ messages in thread
From: Juhani Viheräkoski @ 2009-07-02 15:49 UTC (permalink / raw)
  To: guile-devel

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1291 bytes --]

> > With recent changes in guile vm there are lots on improvements on the
> > Gambit benchmarks.
>
> Improvements compared to what?

I should have been more concise.. I have run these benchmarks against 
guile HEAD for some time (after I reported a few bugs, performance 
regressions included,  affecting the benchmark suite I have done this 
every once in a while to get some additional test coverage) and now I had 
something to report. Guile I compared to is a git version before vector 
instructions were added to VM. Guile is now a little bit slower 
generally, but significantly faster in many real-world benchmarks using 
vectors.

> > but there are huge wins in testcases involving vectors offsetting
> > this.
> 
> Oh, that's cool, but it feels like we're slightly cheating on these.
> ;-)

Well it seems to be a good cheat then :)

> This is not tail-recursive (because of the nested `ack' call in the
> `else' clause), which is why it can lead to a stack overflow.

I understand that, but I reported this because interpreter (both 1.8.6 and 
1.9.0) run this test successfully but VM does not. Probably real-world 
programs don't have so deep a recursion, although they might when run with 
complex data..

Thanks for your reply,

Juhani Viheräoski

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Enormous benchmark speedup
  2009-07-02 15:49 ` Juhani Viheräkoski
@ 2009-07-23 21:26   ` Andy Wingo
  2009-07-26  1:09     ` Juhani Viheräkoski
  0 siblings, 1 reply; 6+ messages in thread
From: Andy Wingo @ 2009-07-23 21:26 UTC (permalink / raw)
  To: Juhani Viheräkoski; +Cc: guile-devel

Hi Juhani,

On Thu 02 Jul 2009 17:49, Juhani Viheräkoski <moonshine@kapsi.fi> writes:

>> > With recent changes in guile vm there are lots on improvements on the
>> > Gambit benchmarks.
>>
>> Improvements compared to what?
>
> I should have been more concise..

You were concise, but not precise ;-)

So here's a project, should you choose to be interested ;-) Sometimes we
do things that we don't know exactly how they affect performance. We're
working on getting decent measurement into Guile's build itself... I
mean, we want to work on it :) But we're not measuring.

I would really, really love a graph of performance over time on the
various Gambit benchmarks.

So for every git revision, a number (and standard deviation?) for every
Gambit benchmark. Ideally displayed in tables and graphs.

I just mention all of this to you because you said at one point that you
liked systematically testing things ;-)

>> This is not tail-recursive (because of the nested `ack' call in the
>> `else' clause), which is why it can lead to a stack overflow.
>
> I understand that, but I reported this because interpreter (both 1.8.6
> and 1.9.0) run this test successfully but VM does not. Probably
> real-world programs don't have so deep a recursion, although they might
> when run with complex data..

This is a bug in the VM. The default stack is low, and we have no
capacity to enlarge it on demand. We should keep it low and enlarge it
on demand via overflow handlers.

Peace,

Andy
-- 
http://wingolog.org/




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Enormous benchmark speedup
  2009-07-23 21:26   ` Andy Wingo
@ 2009-07-26  1:09     ` Juhani Viheräkoski
  2009-07-26 12:26       ` tfib.scm Juhani Viheräkoski
  0 siblings, 1 reply; 6+ messages in thread
From: Juhani Viheräkoski @ 2009-07-26  1:09 UTC (permalink / raw)
  To: Andy Wingo; +Cc: guile-devel

On Thu, 23 Jul 2009, Andy Wingo wrote:

> So here's a project, should you choose to be interested ;-) Sometimes we
> do things that we don't know exactly how they affect performance. We're
> working on getting decent measurement into Guile's build itself... I
> mean, we want to work on it :) But we're not measuring.
>
> I would really, really love a graph of performance over time on the
> various Gambit benchmarks.
>
> So for every git revision, a number (and standard deviation?) for every
> Gambit benchmark. Ideally displayed in tables and graphs.
>
> I just mention all of this to you because you said at one point that you
> liked systematically testing things ;-)

At least I could easily put raw logs available to my webpage, I run the 
benchmarks by hand anyway. Then I could try to polish my hacked benchmark 
suite and send it upstream. There were some bugs introduced by my porting 
efforts, I *think* I've fixed them all now :) If someone wants to try it 
it's now available at
http://moonshine.kapsi.fi/bench-guile.tar.bz2

I am currently running the benchmarks and I will put the results for 
master (compiled and interpreted) and 1.8.6 in text format to 
http://moonshine.kapsi.fi/guile-results when finished. I'll try to hack 
something neater during the next week or so. BTW, does anyone know if 
there are guile bindings for any graphic library as I couldn't find any? 
If there aren't, I'll do it in perl then, although I don't especially like 
perl.

-- 
Juhani




^ permalink raw reply	[flat|nested] 6+ messages in thread

* tfib.scm
  2009-07-26  1:09     ` Juhani Viheräkoski
@ 2009-07-26 12:26       ` Juhani Viheräkoski
  0 siblings, 0 replies; 6+ messages in thread
From: Juhani Viheräkoski @ 2009-07-26 12:26 UTC (permalink / raw)
  To: Andy Wingo; +Cc: guile-devel

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1271 bytes --]

> At least I could easily put raw logs available to my webpage, I run the 
> benchmarks by hand anyway. Then I could try to polish my hacked benchmark 
> suite and send it upstream. There were some bugs introduced by my porting 
> efforts, I *think* I've fixed them all now :) If someone wants to try it it's 
> now available at
> http://moonshine.kapsi.fi/bench-guile.tar.bz2
>
> I am currently running the benchmarks and I will put the results for master 
> (compiled and interpreted) and 1.8.6 in text format to 
> http://moonshine.kapsi.fi/guile-results when finished. I'll try to hack 
> something neater during the next week or so. BTW, does anyone know if there 
> are guile bindings for any graphic library as I couldn't find any? If there 
> aren't, I'll do it in perl then, although I don't especially like perl.

Hi,

Results for guile-head are there, however not for 1.8.6 because I think 
there is a problem with threads (at least the same testcase works with git 
version). This program creates lots of threads but should only take some 
milliseconds to run on Linux. It goes into an infinite loop, or at least
takes a very long time to execute as it run for several hours in the 
background while I was doing something else. Testcase attached.

-- 
Juhani

[-- Attachment #2: Type: TEXT/PLAIN, Size: 6762 bytes --]



;------------------------------------------------------------------------------

(define (run-bench name count ok? run)
  (let loop ((i count) (result '(undefined)))
    (if (< 0 i)
      (loop (- i 1) (run))
      result)))

(define (run-benchmark name count ok? run-maker . args)
  (newline)
  (let* ((run (apply run-maker args))
         (result (run-bench name count ok? run)))
    (if (not (ok? result))
      (begin
        (display "*** wrong result ***")
        (newline)
        (display "*** got: ")
        (write result)
        (newline)))))

(define (fatal-error . args)
  (for-each display args)
  (newline)
  (exit 1))

 (define (call-with-output-file/truncate filename proc)
   (call-with-output-file filename proc))

;------------------------------------------------------------------------------

; Macros...

; Specialize fixnum and flonum arithmetic.

;; This code should be used when f64vectors are available.
;(def-macro (FLOATvector-const . lst)   `',(list->f64vector lst))
;(def-macro (FLOATvector? x)            `(f64vector? ,x))
;(def-macro (FLOATvector . lst)         `(f64vector ,@lst))
;(def-macro (FLOATmake-vector n . init) `(make-f64vector ,n ,@init))
;(def-macro (FLOATvector-ref v i)       `(f64vector-ref ,v ,i))
;(def-macro (FLOATvector-set! v i x)    `(f64vector-set! ,v ,i ,x))
;(def-macro (FLOATvector-length v)      `(f64vector-length ,v))
;
;(def-macro (nuc-const . lst)
;  `',(list->vector
;       (map (lambda (x)
;              (if (vector? x)
;                (list->f64vector (vector->list x))
;                x))
;            lst)))

(define make-thread call-with-new-thread)
(define thread-join! join-thread)
(define (thread-start! x) #f)
(define-macro (bitwise-or . lst) `(logior ,@lst))
(define-macro (bitwise-and . lst) `(logand ,@lst))
(define-macro (bitwise-not . lst) `(lognot ,@lst))


; Don't specialize fixnum and flonum arithmetic.

(define-macro (FLOATvector-const . lst)   `',(list->vector lst))
(define-macro (FLOATvector? x)            `(vector? ,x))
(define-macro (FLOATvector . lst)         `(vector ,@lst))
(define-macro (FLOATmake-vector n . init) `(make-vector ,n ,@init))
(define-macro (FLOATvector-ref v i)       `(vector-ref ,v ,i))
(define-macro (FLOATvector-set! v i x)    `(vector-set! ,v ,i ,x))
(define-macro (FLOATvector-length v)      `(vector-length ,v))

(define-macro (nuc-const . lst)
  `',(list->vector lst))

(define-macro (FLOAT+ . lst) `(+ ,@lst))
(define-macro (FLOAT- . lst) `(- ,@lst))
(define-macro (FLOAT* . lst) `(* ,@lst))
(define-macro (FLOAT/ . lst) `(/ ,@lst))
(define-macro (FLOAT= . lst)  `(= ,@lst))
(define-macro (FLOAT< . lst)  `(< ,@lst))
(define-macro (FLOAT<= . lst) `(<= ,@lst))
(define-macro (FLOAT> . lst)  `(> ,@lst))
(define-macro (FLOAT>= . lst) `(>= ,@lst))
(define-macro (FLOATnegative? . lst) `(negative? ,@lst))
(define-macro (FLOATpositive? . lst) `(positive? ,@lst))
(define-macro (FLOATzero? . lst)     `(zero? ,@lst))
(define-macro (FLOATabs . lst) `(abs ,@lst))
(define-macro (FLOATsin . lst) `(sin ,@lst))
(define-macro (FLOATcos . lst) `(cos ,@lst))
(define-macro (FLOATatan . lst) `(atan ,@lst))
(define-macro (FLOATsqrt . lst) `(sqrt ,@lst))
(define-macro (FLOATmin . lst) `(min ,@lst))
(define-macro (FLOATmax . lst) `(max ,@lst))
(define-macro (FLOATround . lst) `(round ,@lst))
(define-macro (FLOATinexact->exact . lst) `(inexact->exact ,@lst))

(define-macro (GENERIC+ . lst) `(+ ,@lst))
(define-macro (GENERIC- . lst) `(- ,@lst))
(define-macro (GENERIC* . lst) `(* ,@lst))
(define-macro (GENERIC/ . lst) `(/ ,@lst))
(define-macro (GENERICquotient . lst)  `(quotient ,@lst))
(define-macro (GENERICremainder . lst) `(remainder ,@lst))
(define-macro (GENERICmodulo . lst)    `(modulo ,@lst))
(define-macro (GENERIC= . lst)  `(= ,@lst))
(define-macro (GENERIC< . lst)  `(< ,@lst))
(define-macro (GENERIC<= . lst) `(<= ,@lst))
(define-macro (GENERIC> . lst)  `(> ,@lst))
(define-macro (GENERIC>= . lst) `(>= ,@lst))
(define-macro (GENERICexpt . lst) `(expt ,@lst))


;------------------------------------------------------------------------------
; Gabriel benchmarks
(define boyer-iters         2)
(define browse-iters       60)
(define cpstak-iters      100)
(define ctak-iters         1)
(define dderiv-iters   200000)
(define deriv-iters    200000)
(define destruc-iters      50)
(define diviter-iters  100000)
(define divrec-iters   100000)
(define puzzle-iters       10)
(define tak-iters         200)
(define takl-iters         30)
(define trav1-iters        10)
(define trav2-iters         2)
(define triangl-iters       1)

; Kernighan and Van Wyk benchmarks
(define ack-iters           1)
(define array1-iters        1)
(define cat-iters           1)
(define string-iters        1)
(define sum1-iters          1)
(define sumloop-iters       1)
(define tail-iters          1)
(define wc-iters            1)

; C benchmarks
(define fft-iters        2000)
(define fib-iters           5)
(define fibfp-iters         2)
(define mbrot-iters       100)
(define nucleic-iters       5)
(define pnpoly-iters   100000)
(define sum-iters       10000)
(define sumfp-iters      5000)
(define tfib-iters         20)

; Other benchmarks
(define conform-iters       4)
(define dynamic-iters       2)
(define earley-iters       20)
(define fibc-iters         50)
(define graphs-iters       30)
(define lattice-iters       1)
(define matrix-iters       40)
(define maze-iters        400)
(define mazefun-iters     100)
(define nqueens-iters     200)
(define paraffins-iters   100)
(define peval-iters        20)
(define pi-iters            1)
(define primes-iters    10000)
(define ray-iters           1)
(define scheme-iters     20000)
(define simplex-iters   10000)
(define slatex-iters        2)
(define perm9-iters         1)
(define nboyer-iters       10)
(define sboyer-iters       10)
(define gcbench-iters       1)
(define compiler-iters     30)
;;; TFIB -- Like FIB but using threads.

(define (tfib n)
  (if (< n 2)
      1
      (let ((x (make-thread (lambda () (tfib (- n 2))))))
        (thread-start! x)
        (let ((y (tfib (- n 1))))
          (+ (thread-join! x) y)))))

(define (go n repeat)
  (let loop ((repeat repeat)
             (result '()))
    (if (> repeat 0)
        (let ((x (make-thread (lambda () (tfib n)))))
          (thread-start! x)
          (let ((r (thread-join! x)))
            (loop (- repeat 1) r)))
        result)))

(define (main . args)
  (run-benchmark
   "tfib"
   tfib-iters
   (lambda (result) (equal? result 610))
   (lambda (n repeat) (lambda () (go n repeat)))
   14
   100))
(main)


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2009-07-26 12:26 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-07-01 14:48 Enormous benchmark speedup Juhani Viheräkoski
2009-07-01 22:47 ` Ludovic Courtès
2009-07-02 15:49 ` Juhani Viheräkoski
2009-07-23 21:26   ` Andy Wingo
2009-07-26  1:09     ` Juhani Viheräkoski
2009-07-26 12:26       ` tfib.scm Juhani Viheräkoski

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).