Gambit-list Mars 2015

gambit-list@iro.umontreal.ca

13 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

object->u8vector as tree shaker?
by Bradley Lucier 29 Mar '15

29 Mar '15

Marc: It's not quite clear to me what object->u8vector does with procedures. I was thinking that if it pulled in all the functions not in system libraries, then it could be used as a tree-shaker. This is only a vague thought, but I find its interesting. Brad

3 6

CFP: ACM SIGPLAN GPCE 2015
by Faruk Caglar 20 Mar '15

20 Mar '15

[Apologies if you receive multiple copies of this email] ------------------------------------------------------------- ACM SIGPLAN GPCE 2015 14th International Conference on Generative Programming: Concepts & Experiences Oct 26-27, 2015, Pittsburgh, PA, USA http://conf.researchr.org/home/gpce2015 Co-located with: ACM SIGPLAN conference on Systems, Programming, Languages and Applications: Software for Humanity (SPLASH 2015) and ACM SIGPLAN 8th International Conference on Software Language Engineering (SLE) 2015 ----------------------------------------------------------------- IMPORTANT DATES Abstract submission : June 8, 2015 Full paper submission : June 15, 2015 Authors notification : July 24, 2015 Camera-ready : Aug 7, 2015 Conference : Oct 26-27, 2015 Workshops: Handled by SPLASH All dates are Anywhere on Earth ----------------------------------------------------------------- SCOPE GPCE is a venue for researchers and practitioners interested in techniques that use program generation, domain-specific languages, and component deployment to increase programmer productivity, improve software quality, and shorten the time-to-market of software products. In addition to exploring cutting-edge techniques of generative software, our goal is to foster further cross-fertilization between the software engineering and the programming languages research communities. ----------------------------------------------------------------- TOPICS OF INTEREST GPCE seeks contributions on all topics related to generative software and its properties. Topics of interest include, but are not limited to: Generative software * Domain-specific languages (language extension, language embedding, language design, language theory, language workbenches, interpreters, compilers) * Product lines (domain engineering, feature-oriented and aspect-oriented programming, pre-processors, feature interactions) * Metaprogramming (reflection, staging, partial evaluation), Type systems, Program synthesis * Implementation techniques and tool support (components, plug-ins, libraries, metaprogramming, macros, templates, generic programming, run-time code generation, model-driven development, composition tools, code-completion and code-recommendation systems) Practical Applications and Empirical evaluations * Empirical evaluations of all topics above (user studies, substantial case studies, controlled experiments, surveys, rigorous measurements) * Application areas and engineering practice (Cloud Computing, Internet of Things, Cyber Physical Systems, Mobile Computing, Software Defined Networking, High Performance Computing, Patterns and Middleware, Development methods) Properties of generative software * Correctness of generators and generated code (analysis, testing, formal methods, domain-specific error messages, safety, security) * Reuse and evolution * Modularity, separation of concerns, understandability, and maintainability * Performance engineering, nonfunctional properties (program optimization and parallelization, GPGPUs, multicore, footprint, metrics) We particularly welcome papers that address some of the key challenges in the field, such as, * synthesizing code from declarative specifications * supporting extensible languages and language embedding * ensuring correctness and other nonfunctional properties of generated code * proving generators correct * improving error reporting with domain-specific error messages * reasoning about generators * handling variability-induced complexity in product lines * providing efficient interpreters and execution languages * human factors in developing and maintaining generators GPCE encourages submissions about empirical evaluations and applications of generative software, and such papers will be given special consideration during reviewing. ----------------------------------------------------------------- SUBMISSION GUIDELINES Research papers: 10 pages maximum (ACM SIGPLAN style) Research papers should report on original and unpublished results of theoretical, empirical, conceptual, or experimental research that contribute to scientific knowledge in the areas listed above (the PC chair can advise on appropriateness) Tool demos and short papers: 4 pages maximum (ACM SIGPLAN style). The goal of short papers is to promote current work on research and practice. Short papers represent an early communication of research and do not always require complete results as in the case of a full paper. In this way, authors can introduce new ideas to the community, discuss ideas and get early feedback. Please note that short papers are not intended to be position statements. Short papers are included in the proceedings and will be presented with a shorter time slot at the conference. Tool demonstrations should present tools that implement generative techniques, and are available for use. Any of the GPCE topics of interest are appropriate areas for tool demonstrations, although purely commercial tool demonstrations will not be accepted. Submissions must provide a tool description of 4 pages in SIGPLAN proceedings style (see above) and a demonstration outline including screenshots of up to 4 pages. Tool demonstrations must have the words "Tool Demo" or "Tool Demonstration" in the title, possibly appended in parenthesis. The 4-page tool description will, if the demonstration is accepted, be published in the proceedings. ----------------------------------------------------------------- ORGANIZERS GENERAL CHAIR Christian Kastner, Carnegie Mellon University, Pittsburgh, PA, USA PROGRAM COMMITTEE CHAIR Aniruddha Gokhale, Vanderbilt University, Nashville, TN, USA PUBLICITY CO-CHAIRS Faruk Caglar, Vanderbilt University, Nashville, TN, USA Tomofumi Yuki, INRIA Rhone-Alpes, France PROGRAM COMMITTEE (TO BE COMPLETED) Kenichi Asai, Ochanomizu Univ, Japan Emilie Balland, INRIA Bordeaux, France Don Batory, Univ of Texas, USA Walter Binder, Univ of Lugano, Switzerland Jan Bosch, Chalmers Univ, Sweden Akshay Dabholkar, Oracle, USA Ewen Denney, NASA Ames, USA Katrina Falkner, Univ of Adelaide, Australia Bernd Fischer, Stellenbosch Univ, South Africa Matthew Flatt, Univ of Utah, USA Jeff Gray, Univ of Alabama, USA Michael Haupt, Oracle Labs, Germany James Hill, Indiana Univ Purdue Univ at Indianapolis, USA Young-Woo Kwon, Utah State Univ, USA Raffaela Mirandola, Politechnico di Milano, Italy Hridesh Rajan, Iowa State Univ, USA Laurent Reveillere, LaBRI, Univ of Bordeaux, France Marcio Ribeiro, Federal Univ of Alagoas, Brazil Tiark Rompf, Purdue Univ, USA Klaus Schmid, Stiftung Universitat Hildesheim, Germany Norbert Siegmund, Univ of Passau, Germany Yannis Smaragdakis, Univ of Athens, Greece Sumant Tambe, RTI Inc, USA Petr Tuma, Charles Univ, Czech Republic Nalini Venkatasubramanian, Univ of California, Irvine, USA Jules White, Vanderbilt Univ, USA Eric Wohlstadter, Univ of British Columbia, Canada

1 0

Finally, how get --enable-debug goodness without a console file?
by Mikael 19 Mar '15

19 Mar '15

Dear Marc, --enable-debug is great to have enabled because it adds in more debug symbol info in compiled files than just CC_FLAGS="-g -O0", right? The console file easily grows beyond 10GB and fills a whole harddrive and sinks a whole OS and machine though. Would you kindly please want to devise/suggest a middle way that delivers --enable-debug but without the console file? Perhaps all the console file logics could just be switched off by adding/removing some C define. Just anything that works is fine. Thanks, Mikael

1 0

Trimming libgambcgsc
by Bradley Lucier 19 Mar '15

19 Mar '15

Marc: The way to configure Gambit on the Raspberry Pi to get the fastest runtime is ./configure 'CC=gcc-4.8 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard' '--enable-single-host' '--enable-shared' '--enable-multiple-versions' '--disable-gnu-gcc-no-strict-aliasing’ However, there isn’t enough memory to compile _t-univ.c with this configuration. There are four files that aren’t used when building Gambit with the C back end, all in gsc: _t-univ.scm _x86.scm _asm.scm _t-x86.scm These files are part of the partial implementations of the x86 assembler back end and the “universal” back end. I recommend that these files not be included in libgambcgsc by default. Most people don’t need them, and and they inhibit building Gambit on the Pi. I got it to build eventually by removing these files from makefile.in by hand after building Gambit first simply with ./configure --enable-single-host. Brad

1 0

[TFP'15] final call for papers - deadline extended march 31 -
by Peter Achten 18 Mar '15

18 Mar '15

----------------------------- L A S T C A L L F O R P A P E R S ----------------------------- ======== TFP 2015 =========== 16th Symposium on Trends in Functional Programming June 3-5, 2015 Inria Sophia Antipolis, France http://tfp2015.inria.fr/ The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions (see below). Authors of draft papers will be invited to submit revised papers based on the feedback receive at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. The selected revised papers will be published as a Springer Lecture Notes in Computer Science (www.springer.com/lncs) volume. TFP 2015 will be the main event of a pair of functional programming events. TFP 2015 will be accompanied by the International Workshop on Trends in Functional Programming in Education (TFPIE), which will take place on June 2nd. The TFP symposium is the heir of the successful series of Scottish Functional Programming Workshops. Previous TFP symposia were held in * Edinburgh (Scotland) in 2003; * Munich (Germany) in 2004; * Tallinn (Estonia) in 2005; * Nottingham (UK) in 2006; * New York (USA) in 2007; * Nijmegen (The Netherlands) in 2008; * Komarno (Slovakia) in 2009; * Oklahoma (USA) in 2010; * Madrid (Spain) in 2011; * St. Andrews (UK) in 2012; * Provo (Utah, USA) in 2013; * and in Soesterberg (The Netherlands) in 2014. For further general information about TFP please see the TFP homepage. (http://www.tifp.org/). == INVITED SPEAKERS == TFP is pleased to announce talks by the following two invited speakers: * Laurence Rideau is a researcher at INRIA and is interested in the semantics of programming languages , the formal methods, and the verification tools for programs and mathematical proofs. She participated in the beginnings of the Compcert project (certified compiler), and is part of the Component Mathematical team in the MSR-INRIA joint laboratory, who performed the formalization of the Feit-Thompson theorem successfully. Thirty years ago, computers barged in mathematics with the famous proof of the Four Color Theorem. Initially limited to simple calculation, their role is now expanding to the reasoning whose complexity is beyond the capabilities of most humans, as the proof of the classification of finite simple groups. We present our large collaborative adventure around the formalization of the Feit-Thompson theorem (http://en.wikipedia.org/wiki/Feit%E2%80%93Thompson_theorem) that is a first step to the classification of finite groups and that uses a palette of methods and techniques that range from formal logic to software (and mathematics) engineering. * Anil Madhavapeddy == SCOPE == The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: Research Articles: leading-edge, previously unpublished research work Position Articles: on what new trends should or should not be Project Articles: descriptions of recently started new projects Evaluation Articles: what lessons can be drawn from a finished project Overview Articles: summarizing work with respect to a trendy subject Articles must be original and not simultaneously submitted for publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include: Functional programming and multicore/manycore computing Functional programming in the cloud High performance functional computing Extra-functional (behavioural) properties of functional programs Dependently typed functional programming Validation and verification of functional programs Debugging and profiling for functional languages Functional programming in different application areas: security, mobility, telecommunications applications, embedded systems, global computing, grids, etc. Interoperability with imperative programming languages Novel memory management techniques Program analysis and transformation techniques Empirical performance studies Abstract/virtual machines and compilers for functional languages (Embedded) domain specific languages New implementation strategies Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2015 program chair, Manuel Serrano. == BEST PAPER AWARDS == To reward excellent contributions, TFP awards a prize for the best paper accepted for the formal proceedings. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are listed as first authors, and a student would present the paper. A prize for the best student paper is awarded each year. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, that paper will then receive both prizes. == SPONSORS == TFP is financially supported by Erlang Solutions. == PAPER SUBMISSIONS == Acceptance of articles for presentation at the symposium is based on a lightweight peer review process of extended abstracts (4 to 10 pages in length) or full papers (20 pages). The submission must clearly indicate which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate which authors are research students, and whether the main author(s) are students. A draft paper for which ALL authors are students will receive additional feedback by one of the PC members shortly after the symposium has taken place. We use EasyChair for the refereeing process. Papers must be submitted at: https://easychair.org/conferences/?conf=tfp2015 Papers must be written in English, and written using the LNCS style. For more information about formatting please consult the Springer LNCS web site: http://www.springer.com/computer/lncs?SGWID=0-164-6-793341-0 == IMPORTANT DATES == Submission of draft papers: March 31, 2015 Notification: April 7, 2015 Registration: May 4, 2015 TFP Symposium: June 3-5, 2015 Student papers feedback: June 9, 2015 Submission for formal review: July 1, 2015 Notification of acceptance: September 8, 2015 Camera ready paper: October 8, 2015 == PROGRAM COMMITTEE == Janis Voigtländer University of Bonn, DE Scott Owens University of Kent, UK Neil Sculthorpe Swansea University, UK Colin Runciman University of York, UK Manuel Serrano Inria (PC chair), FR Rinus Plasmeijer University of Nijmegen, NL Tomas Petricek University of Cambridge, UK Marco T. Morazan Seton Hall University, USA Wolfgang De Meuter Vrije Universiteit Brussel, BE Michel Mauny Ensta ParisTech, FR Sam Lindley The University of Edinburgh, UK Daan Leijen Microsoft, USA Jurriaan Hage Utrecht University, NL Andy Gill University of Kansas, USA Thomas Gazagnaire University of Cambrige, UK Lars-Ake Fredlund Universidad Politécnica de Madrid, ES Jean-Christophe Filliatre Université Paris Sud Orsay, FR Marc Feeley Université de Montréal, CA Olaf Chitil University of Kent, UK Edwin Brady University of St Andrews, UK

1 0

old fixnum and flonum primitives
by Marc Feeley 18 Mar '15

18 Mar '15

The fixnum and flonum primitives are available using two naming schemes. For example, fixnum and flonum addition are implemented by these primitives: ##fx+ and ##fixnum.+ ##fl+ and ##flonum.+ The long name has been deprecated for quite some time and will be removed in the next release of Gambit. Please make sure your code does not use the long names. Marc

1 0

Bug on OS X, due to linker's incomplete support of thread local storage class
by Gmail 16 Mar '15

16 Mar '15

I tried to use Gambit-C with the 'multiple-vms’ option enabled, to harness full cpu power by SMP. But ‘compile-file’ on REPL failed with the message: ld: illegal thread local variable reference to regular symbol ____tls_ptr for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) After some experiments, it seems that the OS X linker does not properly support dynamic linking of externally defined TLS variables. This can be verified easily with the following code. // test.c extern __thread int tls_id; int get_tls_id() { return tls_id; } On OS X, both gcc and clang failed to produce a dynamically loadable object file. (OS X 10.10.1, Xcode 6.2, clang-600.0.57; gcc-4.8 intalled from homebrew.) $ gcc-4.8 -shared test.c -o libfoo.so $ gcc-4.9 -shared test.c -o libfoo.so $ clang -bundle test.c -o libfoo.so The three give the same error: Undefined symbols for architecture x86_64: "_tls_num", referenced from: _get_tls_num in test-9d6352.o (maybe you meant: _get_tls_num) ld: symbol(s) not found for architecture x86_64 While on Linux (ArchLinux 3.18.6 X86_64, gcc 4.9.2), it worked. The produced library linked fine with main.c (as follows), execution gives 1. // main.c #include <stdio.h> __thread int tls_id; extern int get_tls_id(); int main () { int id = 0; tls_id = 1; id = get_tls_id(); printf(“tls id is %d\n”, id); return 0; } I also tried to fallback on the pthread_get/setspecific() approach, by manually change CONF_THREAD_LOCAL_STORAGE_CLASS in configure/configure.ac. Well, gsc/gsi crashes on running, due to a memory related bug. I am fairly new to Gambit, hope someone more familiar with its source would help to pin this bug. If configures as enable-multiple-threaded-vm, then it crashes in alloc_scmobj_still(): (lldb) target create "gsc" Current executable set to 'gsc' (x86_64). (lldb) r Process 96941 launched: '/Users/whimse/Work/MobileGames/Rabbit/gambit/gsc/gsc' (x86_64) Process 96941 stopped * thread #1: tid = 0x6176f, 0x0000000100014399 gsc`alloc_scmobj_still(___ps=0x00007fff7678a300, subtype=18, bytes=24) + 105 at mem.c:1209, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x198) frame #0: 0x0000000100014399 gsc`alloc_scmobj_still(___ps=0x00007fff7678a300, subtype=18, bytes=24) + 105 at mem.c:1209 1206 * Account for words allocated only for non-permanent objects. 1207 */ 1208 -> 1209 words_nonmovable += words; 1210 1211 if (WORDS_OCCUPIED > heap_size 1212 #ifdef CALL_GC_FREQUENTLY (lldb) bt * thread #1: tid = 0x66281, 0x0000000100014399 gsc`alloc_scmobj_still(___ps=0x00007fff7678a300, subtype=18, bytes=24) + 105 at mem.c:1209, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x198) * frame #0: 0x0000000100014399 gsc`alloc_scmobj_still(___ps=0x00007fff7678a300, subtype=18, bytes=24) + 105 at mem.c:1209 frame #1: 0x0000000100014246 gsc`___alloc_scmobj(___ps=0x00007fff7678a300, subtype=18, bytes=24) + 70 at mem.c:1284 frame #2: 0x0000000100024686 gsc`___POINTER_to_SCMOBJ(___ps=0x00007fff7678a300, x=0x0000000102800000, tags=-2, release_fn=0x000000010003a200, obj=0x00007fff5fbff200, arg_num=127) + 86 at c_intf.c:5152 frame #3: 0x000000010002478f gsc`___NONNULLPOINTER_to_SCMOBJ(___ps=0x00007fff7678a300, x=0x0000000102800000, tags=-2, release_fn=0x000000010003a200, obj=0x00007fff5fbff200, arg_num=127) + 111 at c_intf.c:5194 frame #4: 0x000000010003c8ed gsc`___os_device_stream_open_predefined(index=-4, flags=64) + 365 at os_io.c:8032 frame #5: 0x0000000100082517 gsc`___H__20___kernel_23_36(___ps=0x0000000100e6f640) + 391 at _kernel.c:17902 frame #6: 0x0000000100010346 gsc`trampoline(___ps=0x0000000100e6f640) + 38 at setup.c:1939 frame #7: 0x0000000100010298 gsc`___call(___ps=0x0000000100e6f640, nargs=0, proc=4305759265, stack_marker=4331667505) + 552 at setup.c:2029 frame #8: 0x000000010001087a gsc`___setup_pstate(___ps=0x0000000100e6f640, ___vms=0x0000000100e6f640) + 330 at setup.c:2406 frame #9: 0x0000000100010966 gsc`___setup_vmstate(___vms=0x0000000100e6f640) + 38 at setup.c:2439 frame #10: 0x0000000100010b04 gsc`___setup(setup_params=0x00007fff5fbff6a8) + 404 at setup.c:3380 frame #11: 0x000000010000eaa6 gsc`___main(linker=0x000000010000d4e0) + 5478 at main.c:715 frame #12: 0x00000001000299e6 gsc`___main_char(argc=1, argv=0x00007fff5fbff8a8, linker=0x000000010000d4e0, script_line=0x0000000000000000) + 150 at os_base.c:413 frame #13: 0x000000010000d533 gsc`main(argc=1, argv=0x00007fff5fbff8a8) + 51 at _gsc_.c:14993 frame #14: 0x00007fff912225c9 libdyld.dylib`start + 1 frame #15: 0x00007fff912225c9 libdyld.dylib`start + 1 If configures as single-threaded-vms, then it crashes in next_msection(): (lldb) target create "gsc" Current executable set to 'gsc' (x86_64). (lldb) r Process 2727 launched: '/Users/whimse/Work/MobileGames/Rabbit/gambit/gsc/gsc' (x86_64) Process 2727 stopped * thread #1: tid = 0x630ab, 0x000000010001c16f gsc`next_msection(___ps=0x00007fff7678a300, ms=0x0000000000000000) + 47 at mem.c:1788, stop reason = EXC_BAD_ACCESS (code=1, address=0x8) frame #0: 0x000000010001c16f gsc`next_msection(___ps=0x00007fff7678a300, ms=0x0000000000000000) + 47 at mem.c:1788 1785 ___msection *result; 1786 1787 if (nb_msections_used == 0) -> 1788 result = the_msections->head; 1789 else 1790 result = alloc_msection->next; 1791 (lldb) bt * thread #1: tid = 0x630ab, 0x000000010001c16f gsc`next_msection(___ps=0x00007fff7678a300, ms=0x0000000000000000) + 47 at mem.c:1788, stop reason = EXC_BAD_ACCESS (code=1, address=0x8) * frame #0: 0x000000010001c16f gsc`next_msection(___ps=0x00007fff7678a300, ms=0x0000000000000000) + 47 at mem.c:1788 frame #1: 0x0000000100015d21 gsc`next_heap_msection(___ps=0x00007fff7678a300) + 129 at mem.c:1834 frame #2: 0x000000010001778b gsc`___garbage_collect(___ps=0x00007fff7678a300, nonmovable_words_needed=9) + 443 at mem.c:4584 frame #3: 0x0000000100013dd7 gsc`alloc_scmobj_still(___ps=0x00007fff7678a300, subtype=18, bytes=24) + 263 at mem.c:1221 frame #4: 0x0000000100013be6 gsc`___alloc_scmobj(___ps=0x00007fff7678a300, subtype=18, bytes=24) + 70 at mem.c:1284 frame #5: 0x0000000100023b66 gsc`___POINTER_to_SCMOBJ(___ps=0x00007fff7678a300, x=0x0000000102800000, tags=-2, release_fn=0x00000001000396e0, obj=0x00007fff5fbff200, arg_num=127) + 86 at c_intf.c:5152 frame #6: 0x0000000100023c6f gsc`___NONNULLPOINTER_to_SCMOBJ(___ps=0x00007fff7678a300, x=0x0000000102800000, tags=-2, release_fn=0x00000001000396e0, obj=0x00007fff5fbff200, arg_num=127) + 111 at c_intf.c:5194 frame #7: 0x000000010003bdcd gsc`___os_device_stream_open_predefined(index=-4, flags=64) + 365 at os_io.c:8032 frame #8: 0x0000000100080d07 gsc`___H__20___kernel_23_36(___ps=0x0000000100e4c640) + 391 at _kernel.c:17902 frame #9: 0x000000010000fd16 gsc`trampoline(___ps=0x0000000100e4c640) + 38 at setup.c:1939 frame #10: 0x000000010000fc68 gsc`___call(___ps=0x0000000100e4c640, nargs=0, proc=4305615905, stack_marker=4331667505) + 552 at setup.c:2029 frame #11: 0x000000010001024a gsc`___setup_pstate(___ps=0x0000000100e4c640, ___vms=0x0000000100e4c640) + 330 at setup.c:2406 frame #12: 0x0000000100010336 gsc`___setup_vmstate(___vms=0x0000000100e4c640) + 38 at setup.c:2439 frame #13: 0x00000001000104d4 gsc`___setup(setup_params=0x00007fff5fbff6a8) + 404 at setup.c:3380 frame #14: 0x000000010000e476 gsc`___main(linker=0x000000010000ceb0) + 5478 at main.c:715 frame #15: 0x0000000100028ec6 gsc`___main_char(argc=1, argv=0x00007fff5fbff8a8, linker=0x000000010000ceb0, script_line=0x0000000000000000) + 150 at os_base.c:413 frame #16: 0x000000010000cf03 gsc`main(argc=1, argv=0x00007fff5fbff8a8) + 51 at _gsc_.c:14993 frame #17: 0x00007fff912225c9 libdyld.dylib`start + 1 frame #18: 0x00007fff912225c9 libdyld.dylib`start + 1

4 4

Reliable way of knowing whether you are in the REPL
by Álvaro Castro-Castilla 15 Mar '15

15 Mar '15

Hello, I'm trying to find a way of knowing if some code is being run interactively or in batch mode. Is there a reliable way for this? Thank you

2 1

Gambit on Raspberry Pi 2 B
by Bradley Lucier 10 Mar '15

10 Mar '15

I got a Raspberry Pi 2 B (RPI2), and it’s a lot of fun. Gambit from Github runs out of the box with the compiler that’s shipped with Raspbian (the RPI version of Debian). I was trying out some options to see how to best take advantage of the hardware. The numbers follow my sig. Brad I have a simple test: cutie-pi:~/programs/gambit> gsi -v v4.7.4 20150228031125 armv7l-unknown-linux-gnueabihf "./configure 'CC=gcc -march=armv7-a -mfpu=vfpv4 -mhard-float' '--enable-single-host' '--enable-shared' '--enable-multiple-versions'" cutie-pi:~/programs/gambit> gsi -e '(define a (time (expt 3 1000000)))(define b (time (* a a)))' (time (expt 3 1000000)) 494 ms real time 490 ms cpu time (490 user, 0 system) 7 collections accounting for 8 ms real time (10 user, 0 system) 9166544 bytes allocated 2001 minor faults no major faults (time (* a a)) 522 ms real time 530 ms cpu time (520 user, 10 system) 2 collections accounting for 4 ms real time (10 user, 0 system) 8817880 bytes allocated 2067 minor faults no major faults You can install gcc-4.8, but then it runs out of memory compiling _t-univ.c, so I reconfigured Gambit to not include _t-univ.*, and got the following results: cutie-pi:~/programs/gambit> gsi -v v4.7.4 20150228031125 armv7l-unknown-linux-gnueabihf "./configure 'CC=gcc-4.8 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard' '--enable-single-host' '--enable-shared' '--enable-multiple-versions'" cutie-pi:~/programs/gambit> gsi -e '(define a (time (expt 3 1000000)))(define b (time (* a a)))' (time (expt 3 1000000)) 430 ms real time 430 ms cpu time (420 user, 10 system) 7 collections accounting for 8 ms real time (10 user, 0 system) 9166544 bytes allocated 2001 minor faults no major faults (time (* a a)) 453 ms real time 450 ms cpu time (440 user, 10 system) 2 collections accounting for 3 ms real time (0 user, 0 system) 8817880 bytes allocated 2067 minor faults no major faults And on an experiment in spectral identification that mainly does F64 inner products, I get with the default build (time (run-experiment-and-graph 5)) 785617 ms real time 785590 ms cpu time (785040 user, 550 system) 33 collections accounting for 442 ms real time (350 user, 80 system) 3216061748 bytes allocated 30338 minor faults no major faults and with the gcc-4.8 build I get > (time (run-experiment-and-graph 5)) (time (run-experiment-and-graph 5)) 739829 ms real time 739790 ms cpu time (739620 user, 170 system) 33 collections accounting for 292 ms real time (310 user, 0 system) 3216060588 bytes allocated 17663 minor faults no major faults On my Intel Core i7 with firefly:~> gsi -v v4.7.4 20150228031125 x86_64-unknown-linux-gnu "./configure '--enable-single-host' '--enable-shared' '--enable-multiple-versions’” I get firefly:~> gsi -e '(define a (time (expt 3 1000000)))(define b (time (* a a)))' (time (expt 3 1000000)) 19 ms real time 19 ms cpu time (19 user, 0 system) 2 collections accounting for 0 ms real time (0 user, 0 system) 9133952 bytes allocated 2154 minor faults no major faults (time (* a a)) 20 ms real time 20 ms cpu time (20 user, 0 system) 2 collections accounting for 0 ms real time (0 user, 0 system) 8817984 bytes allocated 1637 minor faults no major faults and > (time (run-experiment-and-graph 5)) (time (run-experiment-and-graph 5)) 50700 ms real time 50709 ms cpu time (50630 user, 79 system) 39 collections accounting for 66 ms real time (60 user, 8 system) 3754964264 bytes allocated 74006 minor faults no major faults I thought I should be able to get things to run faster on the RPI2, but I don’t know what the gcc options should be. Maybe 32-bit versus 64-bit is the big difference. cat /proc/cpuinfo says processor : 3 model name : ARMv7 Processor rev 5 (v7l) BogoMIPS : 38.40 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 5 Hardware : BCM2709 Revision : a21041 Serial : 00000000c222f2d2 and processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 60 model name : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz stepping : 3 microcode : 0x7 cpu MHz : 3497.750 cache size : 8192 KB physical id : 0 siblings : 8 core id : 3 cpu cores : 4 apicid : 7 initial apicid : 7 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm bogomips : 6784.67 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management:

4 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Gambit-list Mars 2015