Re: Results of tests of guile-2.9
Mikael Djurfeldt writes: > That sounds great! Can you say something about how much quicker 2.9.1 is > compared to 2.2? You can find that by looking at the benchmarks by ecraven: https://ecraven.github.io/r7rs-benchmarks/ Comparing 2.9 and 2.2 there, you see a 30% reduction in execution time (averaged by geometric mean). In other words: Guile 2.9 is about 50% faster than Guile 2.2. And looking at details, Guile 2.9 is faster than Guile 2.2 in almost every test, and it did not experience significant slowdown in any test. I also did a summary of all the results which shows that Guile is closing in on MIT-scheme and chicken (but you’ll notice that the ordering is very different from the one on the site, which shows nicely that your result depends on what you look at, and how you look — and you can see that they have very different performance characteristics): The first number is the geometric mean of the slowdown against the fastest implementation in each test. The number in parens is the number of successful tests. 1.9881572085609192 (38 / 38) stalin-unknown 2.1500822915753734 (57 / 57) chez-9.5.1-m64 2.738525957787122 (55 / 55) gambitc-v4.9.0 2.7694443820075634 (55 / 55) gerbil-v0.14-DEV 4.205151966183653 (50 / 50) bigloo-4.3a 5.442681840154815 (57 / 57) larceny-1.3 5.707385688762197 (57 / 57) racket-7.0/r7rs 8.679978781946975 (50 / 50) chicken-4.13.0 9.248983537329178 (51 / 51) mit-9.2.1 10.587408686012083 (55 / 55) guile-2.9.1.3-1f678 10.615583087968362 (41 / 41) bones-unknown 11.524752498102057 (56 / 56) cyclone-0.9.3 14.448014458884698 (57 / 57) petite-9.5.1-m64 15.089971411932236 (56 / 56) guile-2.2.4 18.035143748368437 (45 / 45) ypsilon-unknown 19.005148516339332 (44 / 44) femtolisp-unknown 19.139543005333042 (56 / 56) gauche-0.9.6 27.645742735331833 (57 / 57) sagittarius-0.9.2 31.157381722908422 (36 / 36) rscheme-unknown 34.153836451059746 (39 / 39) scheme48-unknown 36.48670680531284 (41 / 41) picrin-unknown 38.99165232121692 (48 / 48) kawa-3.0 47.53962620985255 (28 / 28) rhizome-unknown 55.1945662817 (11 / 11) s9fes-unknown 64.80503623166697 (35 / 35) SISC-1.16.6 86.0140998934114 (48 / 48) chibi-unknown 109.67746150832924 (35 / 35) chickencsi-4.13.0 180.3672988266313 (17 / 17) foment-0.4 created with `for i in bigloo-4.3a bones-unknown chez-9.5.1-m64 chibi-unknown chicken-4.13.0 chickencsi-4.13.0 cyclone-0.9.3 femtolisp-unknown foment-0.4 gambitc-v4.9.0 gauche-0.9.6 gerbil-v0.14-DEV guile-2.2.4 guile-2.9.1.3-1f678 ironscheme kawa-3.0 larceny-1.3 mit-9.2.1 petite-9.5.1-m64 picrin-unknown racket-7.0/r7rs rhizome-unknown rscheme-unknown s9fes-unknown sagittarius-0.9.2 scheme48-unknown SISC-1.16.6 stalin-unknown tinyscheme ypsilon-unknown; do echo $(./evaluate-r7rs-benchmark.w /tmp/all.csv $i | tail -n 1) $i; done | sort -g` using https://bitbucket.org/ArneBab/wisp/src/tip/examples/evaluate-r7rs-benchmark.w Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: GTK3 bindings status
Hi Mike! I'm just here to say, thanks for the work! Mike Gran 于 2018年11月12日周一 07:52写道： > Hi- > > After a few weeks hacking, I have actually got a library that parses > GObject-Introspection *.typelib files to create Guile bindings, and I > have added just enough machinery to get GTK's famous Example 1 to run. > > Theirs > https://developer.gnome.org/gtk3/stable/gtk-getting-started.html > Mine > https://github.com/spk121/guile-gi/blob/master/test/example-1.scm > > The library code is an awful mess, so I wouldn't bother trying to > build it or use it, yet, but, it was a milestone I though I might > report. > > The cool part of that example is that I'm using a lambda as a GObject > button "clicked" signal callback, which ended up requiring quite a bit > of infrastructure and FFI. > > So a few weeks ago there was a bit of discussion about the best way to > accomplish a GTK3 binding for Guile. I got a lot of great advice, > but, I decided to choose a low-level approach to it, mostly in C, for > now, which I believe is necessary to smooth the edges between > GTK's API and Scheme. Also, I decided to skip GOOPS for a more direct > approach, which may or may not be a terrible idea. > > Regards, > Mike > >
Re: Results of tests of guile-2.9
That sounds great! Can you say something about how much quicker 2.9.1 is compared to 2.2? Den sön 11 nov. 2018 21:53 skrev Stefan Israelsson Tampe < stefan.ita...@gmail.com>: > Hi, > > I've taken 2.9 on a ride with my active code bases, guile-log, > guile-syntax-parse and python-on -guile. > > Generelly it's a pleasure as always to work with guile. I can compile all > code and especially the > clpfd code in the prolog part works out nicely (A huge file that takes now > 6minutes to compile > a 10MB go file). > > What's was surprising was that guile-syntax-parse code is much much > quicker than before. Especially the compilation of the racket match.scm > file has improved quite a lot. Prolog code > compiles more quick as well which is very much appriciated. > > A few hickups. > > 1. compiling with O0 fails for me because guile does not translate all > letrec forms down to lover level forms. > > 2. If you put a lambda as a syntax value and try to execute that code you > get an unhelpful message down in the compiler tower, (types.scm). > > Else super work and thanks! >
Results of tests of guile-2.9
Hi, I've taken 2.9 on a ride with my active code bases, guile-log, guile-syntax-parse and python-on -guile. Generelly it's a pleasure as always to work with guile. I can compile all code and especially the clpfd code in the prolog part works out nicely (A huge file that takes now 6minutes to compile a 10MB go file). What's was surprising was that guile-syntax-parse code is much much quicker than before. Especially the compilation of the racket match.scm file has improved quite a lot. Prolog code compiles more quick as well which is very much appriciated. A few hickups. 1. compiling with O0 fails for me because guile does not translate all letrec forms down to lover level forms. 2. If you put a lambda as a syntax value and try to execute that code you get an unhelpful message down in the compiler tower, (types.scm). Else super work and thanks!
