August 2017 - Gambit-list - mailman.iro.umontreal.ca

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

08 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 --enable-auto-forcing: Scope, how/where implemented, how build (with) it properly?
by Adam 18 Sep '17

18 Sep '17

Hi Marc! Three questions regarding promise auto-forcing: 1) Scope If build correctly (e.g. per the instructions below), every single Scheme-world evaluation in the whole GVM will be included in the auto forcing scheme, right? E.g. (begin (declare (not safe)) (print (##string-append (delay "Hello world")) "\n")) and any other quirky Scheme code cases are also included. Do any declares affect auto-forcing behavior? 2) How/where is it implemented? I'm trying to follow the code path of the "--enable-auto-forcing" ./configure argument, but I cannot figure out how it is propagated as to affect anything in include/ , gsc/ , lib/ , anywhere. Also I can't find any logics in gsc/ , lib/ or include/ (that's where they should be I supposed) that pertain to automatic forcing of promises. Possibly the "macro-force-vars", which is used all over the runtime and compiler, would have something to do with this, but I don't find its definition anywhere. What am I missing, would you like to take a minute to describe where and how the auto-forcing logics are implemented? 3) How build Gambit with it enabled properly? Also, enabling auto-force requires a full recompile of Gambit's own sources (for *all* C files involved to be recompiled, including the runtime, e.g. including the repl, will auto-force, and not just user code and hence just a tiny part of the logics, which would lead to a totally uneven application of auto-forcing), right, so the following is how to properly switch it on right?: git clone https://github.com/gambit/gambit.git cd gambit ./configure --enable-auto-force make -j4 mv gsc/gsc gsc-boot make bootclean make -j4 sudo make install Or do you suggest any other sequence or way? Should I use "from-scratch" instead of "make bootclean" + "make"? Thanks!

3 15

--enable-single-host is sufficient for general use
by Bradley Lucier 18 Sep '17

18 Sep '17

There is a table at http://www.math.purdue.edu/~lucier/gambit-optimization-comparison.html benchmarking Gambit with various levels of optimization. I would conclude that for general purposes, one doesn't need --enable-c-opt or --enable-gcc-opts when configuring. Brad

7 14

gambitscheme.org seems down
by C K Kashyap 29 Aug '17

29 Aug '17

Hi, Is it just me or is gambitscheme.org unreachable? Regards, Kashyap

1 0

gsc -report for finding non-reachable defines
by Sven Hartrumpf 24 Aug '17

24 Aug '17

Hi. Thanks to a suggestion by Marc on the Chicken mailing list, I am experimenting with using the output of 'gsc -report' to remove non-reachable defines. I assume each defined identifier reported with D and one of A or R or C as reachable, all others as non-reachable. The found set of non-reachable identifiers is incomplete, but it can be improved by repeating the analysis on the reduced source: > scms r-matcher.scm cond-expand-command: ... alexpand-command: ... reachable-command: (gsc -:h3700000 -report r-matcher.alexp > r-matcher.alexp.gsc) reduce-command: (cfa-reduce -k r-matcher.alexp r-matcher.reach > r-matcher.rea1) defines: #removed: 718 (24.73%) #kept: 2185 iter 1 size: 3822249 bytes reachable-command: (gsc -:h3700000 -report r-matcher.rea1 > r-matcher.rea1.gsc) reduce-command: (cfa-reduce -k r-matcher.rea1 r-matcher.reach > r-matcher.rea2) defines: #removed: 252 (11.53%) #kept: 1933 iter 2 size: 3519136 bytes reachable-command: (gsc -:h3700000 -report r-matcher.rea2 > r-matcher.rea2.gsc) reduce-command: (cfa-reduce -k r-matcher.rea2 r-matcher.reach > r-matcher.rea3) defines: #removed: 150 (7.76%) #kept: 1783 iter 3 size: 3277324 bytes reachable-command: (gsc -:h3700000 -report r-matcher.rea3 > r-matcher.rea3.gsc) reduce-command: (cfa-reduce -k r-matcher.rea3 r-matcher.reach > r-matcher.rea4) defines: #removed: 93 (5.22%) #kept: 1690 iter 4 size: 3154753 bytes reachable-command: (gsc -:h3700000 -report r-matcher.rea4 > r-matcher.rea4.gsc) reduce-command: (cfa-reduce -k r-matcher.rea4 r-matcher.reach > r-matcher.rea5) defines: #removed: 42 (2.49%) #kept: 1648 iter 5 size: 3000686 bytes reachable-command: (gsc -:h3700000 -report r-matcher.rea5 > r-matcher.rea5.gsc) reduce-command: (cfa-reduce -k r-matcher.rea5 r-matcher.reach > r-matcher.rea6) defines: #removed: 60 (3.64%) #kept: 1588 iter 6 size: 2924187 bytes reachable-command: (gsc -:h3700000 -report r-matcher.rea6 > r-matcher.rea6.gsc) reduce-command: (cfa-reduce -k r-matcher.rea6 r-matcher.reach > r-matcher.rea7) defines: #removed: 26 (1.64%) #kept: 1562 iter 7 size: 2600067 bytes reachable-command: (gsc -:h3700000 -report r-matcher.rea7 > r-matcher.rea7.gsc) reduce-command: (cfa-reduce -k r-matcher.rea7 r-matcher.reach > r-matcher.rea8) defines: #removed: 16 (1.02%) #kept: 1546 iter 8 size: 2586789 bytes reachable-command: (gsc -:h3700000 -report r-matcher.rea8 > r-matcher.rea8.gsc) reduce-command: (cfa-reduce -k r-matcher.rea8 r-matcher.reach > r-matcher.rea9) defines: #removed: 12 (0.78%) #kept: 1534 iter 9 size: 2584936 bytes reachable-command: (gsc -:h3700000 -report r-matcher.rea9 > r-matcher.rea9.gsc) reduce-command: (cfa-reduce -k r-matcher.rea9 r-matcher.reach > r-matcher.rea10) defines: #removed: 6 (0.39%) #kept: 1528 iter 10 size: 2580332 bytes reachable-command: (gsc -:h3700000 -report r-matcher.rea10 > r-matcher.rea10.gsc) reduce-command: (cfa-reduce -k r-matcher.rea10 r-matcher.reach > r-matcher.rea11) defines: #removed: 1 (0.07%) #kept: 1527 iter 11 size: 2579734 bytes reachable-command: (gsc -:h3700000 -report r-matcher.rea11 > r-matcher.rea11.gsc) reduce-command: (cfa-reduce -k r-matcher.rea11 r-matcher.reach > r-matcher.rea12) defines: #removed: 0 (0.00%) #kept: 1527 iter 12 size: 2579734 bytes The loop is terminated if no change of the source file is achieved (fixed point). Here are some questions: 1. There are still non-reachable functions in the final source file, e.g. if two functions call each other but are never called from a third function. 2. Can the analysis by 'gsc -report' be made more aggressive or can it be hinted by providing some identifiers that are known to be non-reachable? 3. Is there a way to stop gsc when the report is ready? Without such a feature, the above 12-step analysis takes 20 minutes because it also generates .o files in each iteration. Greetings Sven

2 4

SMP works up to what point in GSC, any practical use possible currently?
by Adam 21 Aug '17

21 Aug '17

Hi Marc, When starting GSC, spawning more GVM:s will work (= a part of SMP), the heap will work across more GVM:s (= another part of SMP), however the IO subsystem is not SMP:ified at all so as soon as you hit the REPL things will break bad. Is this a correct understanding, and, is there any practical use of the SMP currently? Like, some subset of the runtime that actually is SMP-proof (e.g. all except for IO) so you could use secondary GVM:s for computation in green threads and talk to them via some SMP-proof messaging primitives? Adam

2 4

Making UTF-8 the default for Gambit
by Faré 16 Aug '17

16 Aug '17

Is it possible to build Gambit such that UTF-8 is the default for I/O? Or should it heed the LC_CTYPE or LC_ALL variable? I had a bug while compiling gerbil code that vyzo traced to disagreement between I/O options used by gambit and gerbil. The workaround was to export GAMBOPT=t8,f8,-8 rather than fight to propagate the proper options to gsc. I would like to build gambit with these options as the default, so I can distribute a version that works out of the box. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org He wa'n't no common dog, he wa'n't no mongrel; he was a composite. A composite dog is a dog that is made up of all the valuable qualities that's in the dog breed — kind of a syndicate; and a mongrel is made up of all riffraff that's left over. — Mark Twain

4 5

UDP
by Guillaume Cartier 12 Aug '17

12 Aug '17

Hi everyone, What is the current state of UDP in Gambit? I found - an old post where Marc says he has preliminary support and - https://github.com/bitwize/gamsock which looks interesting but hasn't been updated in years Anything else available if I need to integrate UDP in my Gambit application? Thanks

4 8

Any Gambit coders who want jobs please email me :)
by Adam 10 Aug '17

10 Aug '17

Hi list, If there's any Gambit coders who want jobs, please email me. I don't have any position right now, but I should in a foreseeable future, and preparing takes time also. Please pass references to code or projects of which you are proud, and any CV. Adam

1 0

Extended deadline: IFL 2017 (29th Symposium on Implementation and Application of Functional Languages)
by publicityifl＠gmail.com 07 Aug '17

07 Aug '17

<div dir="ltr">Hello, Please, find below the third call for papers for IFL 2017. Note that some of the deadlines have been extended. Details are given below. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL --- IFL 2017 - CALL FOR PAPERS: DEADLINES EXTENDED ============================================== 29th SYMPOSIUM ON IMPLEMENTATION AND APPLICATION OF FUNCTIONAL LANGUAGES ======================================================================= University of Bristol, UK In cooperation with ACM SIGPLAN Wednesday 30 August - Friday 1 September, 2017 <a href="http://iflconference.org/">http://iflconference.org/</a> Scope ----- The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2017 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Peer-review ----------- Following the IFL tradition, IFL 2017 will use a post-symposium review process to produce the formal proceedings. All participants of IFL 2017 are invited to submit either a draft paper or an extended abstract describing work to be presented at the symposium. At no time may work submitted to IFL be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy: <a href="http://www.sigplan.org/Resources/Policies/Republication">http://www.sigplan.org/Resources/Policies/Republication</a> The submissions will be screened by the program committee chair to make sure they are within the scope of IFL, and will appear in the draft proceedings distributed at the symposium. Submissions appearing in the draft proceedings are not peer-reviewed publications. Hence, publications that appear only in the draft proceedings are not subject to the ACM SIGPLAN republication policy. After the symposium, authors will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full article for the formal review process. From the revised submissions, the program committee will select papers for the formal proceedings considering their correctness, novelty, originality, relevance, significance, and clarity. The formal proceedings will appear in the International Conference Proceedings Series of the ACM Digital Library. Important dates --------------- Note that the original deadlines for submission and registration have been extended. | | | | ----------------------| -----------------------------------------------------------| | Thu 17 August 2017 | Submission deadline draft papers | | Fri 18 August 2017 | Notification of acceptance for presentation | | Mon 21 August 2017 | Early registration deadline | | Mon 21 August 2017 | Submission deadline for pre-symposium proceedings | | Fri 25 August 2017 | Late registration deadline | | Wed 30 August 2017 - Fri 1 September 2017 | IFL Symposium | | Mon 4 December 2017 | Submission deadline for post-symposium proceedings | | Wed 31 January 2018 | Notification of acceptance for post-symposium proceedings | | Mon 12 March 2018 | Camera-ready version for post-symposium proceedings | Submission details ------------------ Prospective authors are encouraged to submit papers or extended abstracts to be published in the draft proceedings and to present them at the symposium. All contributions must be written in English. Papers must use the new ACM two columns conference format, which can be found at: <a href="http://www.acm.org/publications/proceedings-template">http://www.acm.org/publications/proceedings-template</a> For the pre-symposium proceedings we adopt a 'weak' page limit of 12 pages. For the post-symposium proceedings the page limit of 12 pages is firm. Authors submit through EasyChair: <a href="https://easychair.org/conferences/?conf=ifl2017">https://easychair.org/conferences/?conf=ifl2017</a> Topics ------ IFL welcomes submissions describing practical and theoretical work as well as submissions describing applications and tools in the context of functional programming. If you are not sure whether your work is appropriate for IFL 2017, please contact the PC chair at <a href="mailto:nicolas.wu@bristol.ac.uk">nicolas.wu(a)bristol.ac.uk</a>. Topics of interest include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialization - run-time code generation - partial evaluation - (abstract) interpretation - metaprogramming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - (embedded) domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques - (industrial) applications Peter Landin Prize ------------------ The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. Programme committee ------------------- Chair: Nicolas Wu, University of Bristol, UK - Kenichi Asai, Ochanomizu University, Japan - Sandrine Blazy, University of Rennes 1, France - Carlos Camarao, Universidade Federal de Minas Gerais, Brazil - Stephen Dolan, University of Cambridge, UK - Jurriaan Hage, Utrecht University, Netherlands - Yukiyoshi Kameyama, University of Tsukuba, Japan - Benjamin Lerner, Brown University, USA - Bas Lijnse, Radboud University, Netherlands - Garrett Morris, University of Kansas, USA - Miguel Pagano, Universidad Nacional de C√≥rdoba, Argentina - Tomas Petricek, Alan Turing Institute, UK - Maciej Pir√≥g, University of Wroclaw, Poland - Exequiel Rivas, Universidad Nacional de Rosario, Argentina - Neil Sculthorpe, Nottingham Trent University, UK - Melinda Toth, Eotvos Lorand University, Hungary - Phil Trinder, Glasgow University, UK - Kanae Tsushima, National Institute of Informatics, Japan - Marcos Viera, Universidad de la Republica, Uruguay - Meng Wang, University of Kent, UK Venue ----- The IFL 2017 will be held in association with the Department of Computer Science, University of Bristol, UK. Bristol is located in South West England, and can be easily reached from Bristol Airport. See the website for more information on the venue. </div>  <a style='display: block; margin: 32px 0 40px 0; padding: 10px; font-size: 1em; text-align: center; border: 0; border-top: 1px solid gray; ' href='https://goo.gl/2ksdRv'>powered by GSM. Free mail merge and email marketing software for Gmail.</a>

1 0