* 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).