December 2015 - Gambit-list - mailman.iro.umontreal.ca

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

07 Apr '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

Re: [gambit-list] How to express javascript prototypes
by ben yakawp 02 Jan '16

02 Jan '16

and another thing I'd like to point out with this example: I find really difficult to debug the produced code. This is probably because GambitJS doesn't simply transpile the source code but uses the target language as a host for its virtual machine which has its own semantics. I tried to use Marc Feeleys code to mimic OO style in scheme for prototypes: ; OO (define (new constructor . args) (let ((obj (create-object constructor args))) (lambda (method . args) (call-method obj method args)))) ; Prototypes (define (proto constructor . args) (lambda (method . args) (call-method constructor method args))) (define console (proto 'console)) (console log:) Error: /out.js:935 g_r1 = g_host2scm(g_r1[g_r2.toString()].call(g_r1)); TypeError: Cannot call method 'call' of undefined Question: - I would like to find out the value of "console". But what makes more sense: Debugging the value "console" in the c platform of the js platform? - How can you debug the javascript code? Alone the line "g_r1 = g_host2scm(g_r1[g_r2.toString()].call(g_r1)); " is somehow mindblowing to me. You seem to reach out to scheme again from the generated code. I cannot follow this... On Mon, Dec 21, 2015, at 01:39 PM, ben yakawp wrote: > hi > I have a the following problem: Initially I was looking for a simple way > to write code on several platforms with scheme as the "reference > platform". This is more difficult then I thought because most of the > target languages have libraries that are build with an OO model. That > leaks into the platform neutral source code, so that you write scheme > but with OO in mind. Now I see a next problem, that of Javascript making > extensive use of "prototyping", again a specific model that has to be > ported to other languages. > > So my question is, how would you express prototyping in a platform > neutral way, so that you can (hypothecally) use the source code also for > target languages that don't support prototyping. > > Hopefully I don't make this much more complicated than it is. > Ben > _______________________________________________ > Gambit-list mailing list > Gambit-list(a)iro.umontreal.ca > https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list

3 2

Problem with ignored gambini file
by ben yakawp 22 Dec '15

22 Dec '15

Hi, It seems like the gambini file(s) are ignored on my system (Ubuntu 14.04.3) . Here is what I've tried ~/.gambini ~/.gambini.scm /my/current/path/.gambini with gsi from Ubuntus 'gambc' package (v4.2.8) and also a manual build from the github repo (v4.8.1 20151113053459). My simple ~/.gambini always seems to be ignored in all the cases: ~~~ gambini ~~~ (define foo 77) ~~~~~~~~~~~~ $ gsi > foo Unbound variable: foo I don't know what I'm doing wrong here.... ben

2 1

custom top-level repl one-liners
by ben yakawp 22 Dec '15

22 Dec '15

hi Gambits repl is really awesome, especiallly the user friendly interactive debugger. I think it would be even more awesome if one could use a special repl friendly syntax to use an abritrary command. I've read something on the blog of the Gauche Scheme developer which explains it much better (1): "S-expression is great to represent tree structure, but it's a bit cumbersome to give simple commands in interactive shell; If the command line is short, the relative verbosity added by open and close parentheses gets in a way. Also in many cases simple commands take string arguments (e.g. to change working directory or to load file) and that require extra double quotes. I'm not the only one to feel that way. In Allegro CL, if you type a line begins with :, it is interpreted as special toplevel command. Scheme 48 has similar command mode, beginning with ,. I guess there are other implementations with similar features." (1): http://blog.practical-scheme.net/gauche/20150819-toplevel-repl-commands So for 'gsi' that could mean we could write repl> :define hello "world" repl> :display hello Would that be hard to implement? ben

2 1

How to express javascript prototypes
by ben yakawp 21 Dec '15

21 Dec '15

hi I have a the following problem: Initially I was looking for a simple way to write code on several platforms with scheme as the "reference platform". This is more difficult then I thought because most of the target languages have libraries that are build with an OO model. That leaks into the platform neutral source code, so that you write scheme but with OO in mind. Now I see a next problem, that of Javascript making extensive use of "prototyping", again a specific model that has to be ported to other languages. So my question is, how would you express prototyping in a platform neutral way, so that you can (hypothecally) use the source code also for target languages that don't support prototyping. Hopefully I don't make this much more complicated than it is. Ben

2 1

Shouldn't the make-will testator be invoked on process termination too?
by Adam 18 Dec '15

18 Dec '15

Marc, Is there an outer extent on wills' applicability - why don't the second two gsc runs say OUT on termination? Thanks, Adam $ gsc > (define a (box 1)) > (make-will a (lambda (v) (print "OUT.\n") (force-output))) #<will #2> > (##gc) > (set! a #f) > (##gc) OUT. > ,q $ gsc > (define a (box 1)) > (make-will a (lambda (v) (print "OUT.\n") (force-output))) #<will #2> > ,q $ gsc > (make-will (box 1) (lambda (v) (print "OUT.\n") (force-output))) #<will #2> > ,q $

2 2

#!key behavior
by Adam 18 Dec '15

18 Dec '15

Marc, Sometimes, it can be useful to have a procedure that splices out some key arguments and then passes on the remainder. E.g., (define (outerproc #!key a b #!rest r) logics (apply innerproc r)) (define (innerproc #!key c d) ..) Currently, doing (outerproc c: myvalue) causes runtime error "Unknown keyword argument passed to procedure". What's the motivation for this? Would you feel that it could be relevant to include a |declare| that would alter this behavior? Thanks, Adam

2 1

Segfault on OSX using Gambit's C Interface
by Paolo Carlesi 18 Dec '15

18 Dec '15

Hello, I'm experiencing regular segfaults on OSX 10.9.5, with the sample code shown below. Tested with Gambit 4.8.1 + GCC 4.9 and with packaged Gambit 4.7.3 + LLVM. No issue at all on Linux, GCC 4.8, with both Gambit 4.2.8 and Gambit 4.8.2. Of course I may be doing something silly. A simple struct, "My" is generated inside a c procedure, then passed multiple times to another c-lambda procedure (*->My). It's a simplified model of the code produced by a FFI SDL2 Library I'm using. The doc says that the foreign object (xoxo in the example) should not be released while the scheme code is still referencing it. I am seeing the refcount going wildly in the negative, one for each call to *->My The only way -- clumsy -- I have found to avoid this is to increment the reference count with ___addref_rc ( not shown here ). What's wrong here? Thanks! LLDB output: Process 48149 launched: '/Users/paolo/scheme/spazz/fromlin' (x86_64) Process 48149 stopped * thread #1: tid = 0x40e3c9, 0x000000010000770c fromlin`___release_rc + 28, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) frame #0: 0x000000010000770c fromlin`___release_rc + 28 fromlin`___release_rc + 28: -> 0x10000770c: movq %rax, (%rdx) 0x10000770f: movq %rdx, 0x8(%rax) 0x100007713: jmp 0x100010240 ; ___free_mem 0x100007718: nopl (%rax,%rax) stack trace: (lldb) bt * thread #1: tid = 0x40e3c9, 0x000000010000770c fromlin`___release_rc + 28, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) * frame #0: 0x000000010000770c fromlin`___release_rc + 28 frame #1: 0x0000000100002579 fromlin`___release_fn0 + 9 frame #2: 0x0000000100009009 fromlin`___garbage_collect + 3497 frame #3: 0x00000001000091bf fromlin`___alloc_scmobj + 255 frame #4: 0x000000010000d4eb fromlin`___POINTER_to_SCMOBJ + 43 frame #5: 0x000000010000d5e4 fromlin`___STRUCT_to_SCMOBJ + 20 frame #6: 0x0000000100002112 fromlin`___H__20_fromlin + 3378 frame #7: 0x0000000100004aa4 fromlin`___call + 372 frame #8: 0x0000000100004bc6 fromlin`___setup_pstate + 262 frame #9: 0x00000001000063be fromlin`___setup + 3950 (lldb) ;; SAMPLE CODE (c-declare #<<c-declare-end typedef struct My { int r; } My; c-declare-end ) (begin (c-define-type My (struct "My")) (c-define-type My* (pointer My (My*))) (c-define-type My*/nonnull (nonnull-pointer My (My*))) (c-define-type My*/release-rc (nonnull-pointer My (My*) "___release_My"))) (begin (c-declare #<<c-declare-end static ___SCMOBJ ___release_My( void* ptr ) { ___EXT(___release_rc)( ptr ); return ___FIX(___NO_ERR); } c-declare-end ) (define alloc-My (c-lambda () My*/release-rc "___result_voidstar = ___EXT(___alloc_rc)( sizeof( struct My ));")) (define *->My (c-lambda (My*/nonnull) My "___result_voidstar = (My*)___arg1;")) (define My-r (c-lambda (My*/nonnull) unsigned-int8 "___result = ___arg1->r;")) (define My-r-set! (c-lambda (My*/nonnull unsigned-int8) void "___arg1->r = ___arg2;"))) (define (evil) (let ((xoxo (alloc-My))) (My-r-set! xoxo #xff) (let loop ((c 1)) (begin (if (= 0 (remainder c 10000)) (begin (display c) (newline))) (*->My xoxo) (loop (+ 1 c)))))) (evil) ;;END CODE

3 11

How to handle and access and interact with object members host code
by ben yakawp 13 Dec '15

13 Dec '15

hi Sorry if this too obvious, but I don't understand how gambit handles objects from the hosts backend. For example: if one would like to construct a 'Node' library for the JS backend, how would you do that? The whole node api seems to be object oriented. But also the Python standard libaries (batteries) are layed out class based. You had to do something like (define o (new Lib)) (o.print "hello") This looks wrong. What am I missing? Regards ben

4 10

Set traces in the generated code?
by ben yakawp 08 Dec '15

08 Dec '15

Is it possible to set traces in the generated code that leads back to the location of the original scheme code location. Something like a #LINE directive. The only way I see now is to write something like "(dbg ##LINE##)" and then run the whole code through a preprocessor.

2 1