Gambit-list Octobre 2019

gambit-list@iro.umontreal.ca

11 participants
17 discussions

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

07 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

Js backend example doesn't work
by Ben 11 Nov '19

11 Nov '19

Hi, I try to run the example for Js backend from https://mailman.iro.umontreal.ca/pipermail/gambit-list/2019-July/009103.html All the code compiles but I get a runtime error from node ---------------- gambit-test/linked_app.js:1066 return g_peps["##append"](); ^ TypeError: g_peps.##append is not a function ------------------- I guess it has something to do with the name 'append'? That this name cannot be overwritten in a local library? Regards Ben

1 2

Call for Workshop Proposals: ICFP 2020
by Sam Tobin-Hochstadt 30 Oct '19

30 Oct '19

CALL FOR WORKSHOP AND CO-LOCATED EVENT PROPOSALS ICFP 2020 25th ACM SIGPLAN International Conference on Functional Programming August 23 - 28, 2020 Jersey City, NJ, US https://icfp19.sigplan.org/ The 25th ACM SIGPLAN International Conference on Functional Programming will be held in Jersey City, New Jersey on August 23-28, 2020. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for workshops (and other co-located events, such as symposiums) to be affiliated with ICFP 2020 and sponsored by SIGPLAN. These events should be less formal and more focused than ICFP itself, include sessions that enable interaction among the attendees, and foster the exchange of new ideas. The preference is for one-day events, but other schedules can also be considered. The workshops are scheduled to occur on August 23rd (the day before ICFP) and 27-28th of August (the two days after ICFP). ---------------------------------------------------------------------- Submission details Deadline for submission: November 15, 2019 Notification of acceptance: December 13, 2019 Prospective organizers of workshops or other co-located events are invited to submit a completed workshop proposal form in plain text format to the ICFP 2020 workshop co-chairs (Jennifer Hackett and Leonidas Lampropoulos) via email to icfp-workshops-2020(a)googlegroups.com by November 15, 2019. (For proposals of co-located events other than workshops, please fill in the workshop proposal form and just leave blank any sections that do not apply.) Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by December 13, 2019, and if successful, depending on the event, they will be asked to produce a final report after the event has taken place that is suitable for publication in SIGPLAN Notices. The proposal form is available at: http://www.icfpconference.org/icfp2020-files/icfp20-workshops-form.txt Further information about SIGPLAN sponsorship is available at: http://www.sigplan.org/Resources/Proposals/Sponsored/ ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2020 organizing committee, together with the members of the SIGPLAN executive committee. Workshop Co-Chair: Jennifer Hackett (University of Nottingham) Workshop Co-Chair: Leonidas Lampropoulos (University of Maryland) General Chair: Stephanie Weirich (University of Pennsylvania) Program Chair: Adam Chlipala (MIT) ---------------------------------------------------------------------- Further information Any queries should be addressed to the workshop co-chairs (Jennifer Hackett and Leonidas Lampropoulos), via email to icfp-workshops-2020(a)googlegroups.com.

1 0

gambit build failing
by Bradley Lucier 29 Oct '19

29 Oct '19

I didn't notice this right away, because the CI build has been timing out and I (and I presume everyone else) was ignoring the build error. But this one is real: gcc -march=native -D___CAN_IMPORT_CLIB_DYNAMICALLY -O1 -Wno-unused -Wno-write-strings -Wdisabled-optimization -fwrapv -fno-strict-aliasing -fno-trapping-math -fno-math-errno -fschedule-insns2 -fomit-frame-pointer -fPIC -fno-common -mpc64 -I"../include" -c -o "" -D___LIBRARY gcc: fatal error: output filename may not be empty compilation terminated. This is with 148 15:44 update-gambit-git ; pulls and checks out latest 149 15:44 ./configure 'CC=gcc -march=native -D___CAN_IMPORT_CLIB_DYNAMICALLY' '--enable-single-host' '--enable-shared' '--enable-multiple-versions' 150 15:44 make Any ideas? Brad

1 0

table-update! primitive
by Dimitris Vyzovitis 26 Oct '19

26 Oct '19

Marc, Can we add a table-update! primitive? Updates are currently slow because they need two lookups in the hash table, one to find the current value (if any) and one to set it. The canonical signature is (table-update! table key update default), where update is applied to the current value, using default if the value is unset. -- vyzo

3 4

Gerbil: FFI Gerbil modules, why instead of a single Scheme file, a .ssi with (extern ..) + a .scm?
by Adam 22 Oct '19

22 Oct '19

Hi Vyzo, Browsing Gerbil modules for instance here https://github.com/vyzo/gerbil/tree/master/src/std/db I see that FFI modules tend to have a non-standard format, instead of just being a file whateverclibmodule.scm (or .ss in the Gerbil convention, though .scm is supported since last week right) which contains normal Scheme and Scheme FFI code interspersed e.g. (define-c-lambda funame ...) implies (export funame) , you have a .scm file and a .ssi file, where the .ssi contains (extern funame). Why is this? Thanks, Adam

2 7

Gerbil: What's the defsyntax-for-import&/export forms for, e.g. rename-in/out, except-in/out
by Adam 22 Oct '19

22 Oct '19

Hi Vyzo, The core prelude ( https://github.com/vyzo/gerbil/blob/master/src/gerbil/prelude/core.ss) defines some extensions to |import| and |export|. Bumped into studying this in proto.ss, which contains (export ... (struct-out !rpc ...) ...). struct-out can be understood from its use - it's for exporting a structure with its constructors, accessors, mutators. (struct-out's definition code is totally unreadable to me though.) All of these are undocumented, may you want to comment on what they are for also with a single use example (or add to some documentation section in your guide)? Thanks! Adam defsyntax-for-import-export:s: - for-syntax - for-template defsyntax-for-import:s:: - only-in - except-in - rename-in - prefix-in - group-in defsyntax-for-export:s: - except-out - rename-out - prefix-out - struct-out

2 3

Scope of safe use of u8-vector that is not ___STILL/___FIXED, in the C world
by Adam 22 Oct '19

22 Oct '19

Hi Marc, Should any u8vector and other heap allocated object that is processed in the C world be ___STILL/___FIXED, or if it's only a c-lambda that does not store the ___SCMOBJ for future access anywhere, is it OK to pass ordinary u8vectors and other heap allocated objects to the C world and access them up to the point of returning the c-lambda - also of course presuming the c-lambda does not do any Scheme world calls, including Gambit runtime calls, but only uses ordinary gambit.h-local accessors e.g. ___U8VECTORREF. Question arose here https://github.com/vyzo/gerbil/issues/341 . Thanks, Adam

1 0

Whole-program tree-shake & trampolinefreeness by amalgamating runtime&program, possible?
by Adam 19 Oct '19

19 Oct '19

Dear Marc, An interesting question came up when discussing treeshaked Gerbil static builds: One could get a C-compiled program * that is optimally and maximally tree-shaked hence omitting inclusion in the binary of evidently unused code, and * with optimal performance in the respect of having no trampoline calls at all, if one would just append together Gambit's runtime's .scm files with one's program's .scm files, into one gigantic total.scm file, which has (declare (optimize-dead-definitions)) and is built with --enable-single-host . To take this conversation one step further, I like to ask, is this practically possible? I'd really guess it is. If so, your hints about how I can actually do this would be much appreciated. My program consists of the three vanilla Gambit .scm files a.scm b.scm c.scm . I guess very roughly this will be a tweak of echo "(declare (optimize-dead-definitions))" > total.scm cat gambit/lib/*.scm a.scm b.scm c.scm >> total.scm gsc -e '(compile-file-to-target "total.scm")' (aka gsc -c total.scm) cat gambit/lib/os_*.c total.c > c_total.c gcc -o mystaticexe -Igambit/include/ c_total.c Here especially, any more C files than gambit/lib/os_*.c needed, and should the Gambit runtime .c and .scm files be appended in a particular order if so which? Thanks! Adam

2 2

Cross-compilation Q
by Adam 19 Oct '19

19 Oct '19

Hi Marc, Talked to Vyzo, and this question came up: In the C backend using GCC, Gambit supports cross-compliation (say to an ARM Mac OS or Android from some AMD Unix machine), right. How do you pull off cross-compilation relative to not having ./configure have a host to autodetect features on, Which considerations do I need to make for successful cross-compliation? Do I need a separate Gambit build for each destination platform (so I'd do the |compile-file| within the respective build), or can my default Gambit installation be tweaked to compile against multiple platforms? Thanks!

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Gambit-list Octobre 2019