Février 2020 - Gambit-list - mailman.iro.umontreal.ca

Gambit versus Python+GMP: Timing for Chudnovskys' algorithm for pi
by Bradley Lucier 08 Avr '22

08 Avr '22

Bakul Shah wrote a particularly elegant Scheme program for Chudnovskys' algorithm for pi based on the Common Lisp program here: https://bitbucket.org/tarballs_are_good/numericl/src/5fe8fe7089f48ab1c8a388… Nick Craig-Wood wrote a Python program using the GMP multiprecision library that appears to use exactly the same algorithm here: http://www.craig-wood.com/nick/articles/pi-chudnovsky/ I modified both programs a bit and include them here. They time the calculation of $10^n$ digits of pi for $n=1,2,3,4,5,6,7$. The results are heine:~/programs/gambiteer/gambit> !py python pi_chudnovsky_bs_gmpy.py 31415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679 ('chudnovsky_gmpy_mpz_bs: digits', 10, 'time', 1.0967254638671875e-05) ('chudnovsky_gmpy_mpz_bs: digits', 100, 'time', 3.0040740966796875e-05) Last 5 digits 70679 OK ('chudnovsky_gmpy_mpz_bs: digits', 1000, 'time', 0.00025582313537597656) Last 5 digits 01989 OK ('chudnovsky_gmpy_mpz_bs: digits', 10000, 'time', 0.00386810302734375) Last 5 digits 75678 OK ('chudnovsky_gmpy_mpz_bs: digits', 100000, 'time', 0.0834801197052002) Last 5 digits 24646 OK ('chudnovsky_gmpy_mpz_bs: digits', 1000000, 'time', 1.655979871749878) Last 5 digits 58151 OK ('chudnovsky_gmpy_mpz_bs: digits', 10000000, 'time', 30.67442488670349) Last 5 digits 55897 OK heine:~/programs/gambiteer/gambit> gsi chud1.scm Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits 10, CPU time: 0.. Last 5 digits 26535. Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits 100, CPU time: 0.. Last 5 digits 70679. Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits 1000, CPU time: .004. Last 5 digits 1989. Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits 10000, CPU time: .028. Last 5 digits 75678. Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits 100000, CPU time: .472. Last 5 digits 24646. Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits 1000000, CPU time: 6.448. Last 5 digits 58151. Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits 10000000, CPU time: 98.612. Last 5 digits 55897. So it appears that for this algorithm applied to large integers, GMP's bignum routines are about 3-4 times as fast as Gambit's bignum routines. Not so bad. For smaller bignums, GMP has a bigger advantage. The C program gmp-chudnovsky.c includes certain optimizations to this basic algorithm: http://gmplib.org/pi-with-gmp.html ftp://ftp.gmplib.org/pub/misc/gmp-chudnovsky.c On my machine, compiled with gcc -O3 -march=native -o gmp-chudnovsky gmp-chudnovsky.c -lgmp -lm the CPU times for 1,000,000 and 10,000,000 digits are 1.064 and 18.200 seconds, respectively. This is with a somewhat older machine model name : Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz running Ubuntu 13.04 with heine:~/programs/gambiteer/gambit> gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.3-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --enable-objc-gc --with-cloog --enable-cloog-backend=ppl --disable-cloog-version-check --disable-ppl-version-check --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) heine:~/programs/gambiteer/gambit> gsi -v v4.6.9 20130607151908 x86_64-unknown-linux-gnu "./configure '--enable-single-host' '--enable-multiple-versions' '--enable-shared'" and the Ubuntu-provided GMP 5.0.5. (I'm sure the GMP folks have a better way to build GMP on my machine than the "generic" 64-bit version provided by Ubuntu.) Brad

7 18

Simple implementation of "Using Closures for Code Generation"
by Lassi Kortela 27 Fév '20

27 Fév '20

In the interest of learning more about the fundamentals of Scheme and interpreters, is there a simple, pedagogical implementation of the paper "Using closures for code generation" (Feeley/Lapalme 1987) available somewhere? IIRC the Gambit and Chicken interpreters use the technique but those would probably be a bit daunting for a first study since they also do so many other things. In related news, for anyone who enjoys learning about programming language fundamentals there's a new GitHub repo "A Bestiary of Single-File Implementations of Programming Languages" (https://github.com/marcpaq/b1fipl) which catalogues small interpreters. I've had a great time browsing it.

2 1

GCC Optimization setting
by Faré 26 Fév '20

26 Fév '20

So as to better package gambit in nixpkgs, I tried the benchmarks at https://github.com/ecraven/r7rs-benchmarks with Gambit 4.9.3 on my x64 machine. Often -O1 was slightly faster than -O2, sometimes the opposite, with the difference usually less than 10% either way, but up to 17% in favor of -O1 and up to 43% in favor of -O2. However, -Os most often beat both -O1 and -O2, so that's what I chose in the end for NixOS. Note that AFAICT, the benchmark compare the compiled code, not the compilation time. I admit I failed to check the compilation times. I assume -Os is slightly faster than -O2 and somewhat slower than -O1, but would have to check on Gambit-generated code. PS: I also assume clang is still desperately slower than GCC in the code it produces for Gambit. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Those who do not understand Lisp are condemned to not even being able to reinvent it poorly. — Faré, without apologies to Henry Spencer.

2 1

R7RS Modules and Macros
by Tara Lorenz 25 Fév '20

25 Fév '20

Hello, i was under the impression that at least syntax-rules macro would work the new r7rs module-system. However, with this file $ cat x.sld (define-library (x) (import (gambit)) (export a b c d) (begin (define (a) "usual variable") (define-macro (b) "plain old defmacro") (define-syntax c (syntax-rules () ((_) "via syntax-rules"))) (define-syntax d (lambda (stx) (syntax-case stx () ((_) #'"per syntax-case")))))) this is what i get, as expected: $ gsi . Gambit v4.9.3 > (include "x.sld") > (import (x)) > (a) "usual variable" > (b) "plain old defmacro" > (c) "via syntax-rules" > (d) "per syntax-case" > (exit 0) Howerver without the include, things look not so well: $ gsi . Gambit v4.9.3 > (import (x)) > (a) "usual variable" > (b) *** ERROR IN (stdin)(a)3.2 -- Unbound variable: x#b 1> ,t > (c) *** ERROR IN (stdin)(a)5.2 -- Unbound variable: x#c 1> ,t > (d) *** ERROR IN (stdin)(a)7.2 -- Unbound variable: x#d 1> When doing the same exercise using the lolevel module system, as in: $ cat lolevel\#.scm cat lolevel\#.scm (##namespace ("lolevel#" a b c d)) (##import gambit) (define-macro (b) "plain old defmacro") (define-syntax c (syntax-rules () ((_) "via syntax-rules"))) (define-syntax d (lambda (stx) (syntax-case stx () ((_) #'"per syntax-case")))) $ cat lolevel.scm (##supply-module lolevel) (define (a) "usual variable") a simple '(include (lolevel))' suffices, no need for explicitly including anything. So, am i missing something or are my expectations wrong? I should add, that i experience the same problem with the udem-dltem srfi/26 code. So maybe something is just wrong on my side. Cheers, Tara

2 1

Gerbil Q: gerbil.pkg doesn't produce module context, what's wrong?
by Phillip Suero 18 Fév '20

18 Fév '20

Hi! This: echo "(package: a)" > gerbil.pkg echo "(define (abc) 'yes)" > a.scm gxi (import ./a) fails with: > (import ./a) *** ERROR IN ##main -- Syntax Error *** ERROR IN (console)(a)1.9 --- Syntax Error: Cannot resolve relative module path; not in module context ... form: ./a This should obviously work, right?! what's wrong?? Phil

3 6