Gambit-list Août 2009

gambit-list@iro.umontreal.ca

42 participants
44 discussions

Edge triggered I/O with libevent
by Adam Langley 04 Avr '13

04 Avr '13

Gambit uses the select call on POSIX systems to multiplex IO operations. This is fine for small numbers of file descriptors, but falls apart quickly with large numbers[1]. libevent[2] is a wrapper library around a number of modern IO multiplexing systems (epoll on Linux, kqueue on the BSDs as well as poll and select). Attached is a patch which converts Gambit to using edge triggered I/O with epoll and libevent. This also requires a patch (attached) of libevent since the standard distribution doesn't include edge triggering support and the upstream appears to be on holiday. (epoll is required because I don't have a BSD box on which to develop edge triggering support for kqueue) This patch (for Gambit) preprocesses away to nothing unless --enable-libevent is passed to the configure script. (Note that, since this patches the configure.ac script, you'll need to run autoconf to regenerate). I hope I've not broken anything, but at this stage I've only tested that the console and tcp ports work. This patch (in the future) should also allow people, who write programs which use socket calls directly, to integrate into the main event loop at some point. Testing is more than welcome and, if you find a form of IO which is broken, please email me. [1] http://monkey.org/~provos/libevent/libevent-benchmark2.jpg [2] http://monkey.org/~provos/libevent/ -- Adam Langley agl(a)imperialviolet.org http://www.imperialviolet.org (+44) (0)7906 332512 PGP: 9113 256A CC0F 71A6 4C84 5087 CDA5 52DF 2CB6 3D60

2 2

Interactive 3D graphics with Gambit-C
by Alex Sandro Queiroz e Silva 06 Jan '10

06 Jan '10

Hallo, I am thinking about doing some basic 3D graphics with Gambit-C. Although I am sure code generated by Gambit-C is fast enough[1], I am a bit worried about the garbage collector. What's the type of garbage collector used by Gambit? If it kicks in during interactive rendering, should I expect annoying pauses? [1] - http://www.ventonegro.org/2008/09/the-need-for-speed/ -alex http://www.ventonegro.org/

5 7

Re: [gambit-list] Speed improvement of lib/digest.scm
by Marc Feeley 18 Nov '09

18 Nov '09

On 19-Feb-09, at 4:49 PM, Mikael More wrote: > Cool! > > Useful! > > What is the approx speed on your machine btw? > On my 2GHz Mac Book Pro: For MD5: 0.06 seconds per MB. For SHA-1: 0.13 seconds per MB. That's still about 3 times slower than the "md5" utility on my machine, but still not too bad for bit-bashing code entirely written in Scheme. Marc

4 10

bindings to GSL
by michele.zaffalon＠gmail.com 29 Sep '09

29 Sep '09

Hi, I am looking for bindings to the GSL library. Is there some initial work already done that I could use? Thanks, michele

3 2

gambit + blackhole + srfi 13
by Steve Huffman 02 Sep '09

02 Sep '09

Hi All, I'm attempting to compile Black Hole on Gambit 4.5.1. I've installed BH from Git. I ran modules-compile!, and each of the standard BH modules compiled successfully, except for srfi-13, which fails because it runs out of memory. I'm running OS X with 4 gigs of ram. I notice the cc process that is spawned uses about 3.5 gigs before it dies. That seems a bit excessive, no? > (modules-compile! (modules-in-dir "~~/lib/modules/std") #t) Compiling 1 modules "/usr/local/Gambit-C/lib/modules/std/srfi/13.scm" (1/1) cc1(209) malloc: *** mmap(size=97247232) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug cc1: out of memory allocating 97245440 bytes after a total of 0 bytes Warning: Compilation failed: C compilation or link failed while compiling "/usr/local/Gambit-C/lib/modules/std/srfi/13.scm" > Thanks for any help, Steve

3 3

srfi-9
by Michele Zaffalon 31 Aoû '09

31 Aoû '09

Hi, here's a trivial question, but I couldn't find it in the documentation. The documentation says that Gambit has support for srfi 9. However none of the procedures seem implemented. What am I doing wrong? michele

3 5

different set! behavior in interpreted and compiled code
by vasil 30 Aoû '09

30 Aoû '09

Hi! Suppose I have a.scm with next code: ;;------------------------------------------ (define l #f) (let ((t 0)) (set! l (lambda (q) (pp t) (set! t q)))) ;;------------------------------------------ Then I start gsc and do next things: Gambit v4.5.1 > (load "a.scm") ".../a.scm" > (l 2) 0 > (l 3) 2 > (compile-file "a.scm") > (load "a") ".../a.o1" > (l 2) 0 #&2 > (l 3) 2 #&3 Why in compiled code set! returns boxed value, but in interpreted code not? Vasil

2 2

Memory issue with threads
by vasil 29 Aoû '09

29 Aoû '09

Hi! I'm trying to understand what is happening with memory in next test cases: 1. Making many threads, but not staring them -------------------------------------------- Gambit v4.5.1 > (gc-report-set! #t) > (##gc) *** GC: 1 ms, 1.33M alloc, 2.14M heap, 654K live (30% 635200+34704) > (define t (do ((i 0 (+ 1 i)) (l '() (cons (make-thread (lambda () (void))) l))) ((> i 1000000) l))) *** GC: 2 ms, 2.82M alloc, 4.77M heap, 2.08M live (44% 2149968+34704) *** GC: 5 ms, 5.50M alloc, 10.0M heap, 4.76M live (47% 4953664+34704) *** GC: 16 ms, 10.8M alloc, 20.5M heap, 10.0M live (49% 10459472+34704) *** GC: 27 ms, 21.3M alloc, 41.5M heap, 20.5M live (49% 21468624+34704) *** GC: 54 ms, 42.3M alloc, 83.5M heap, 41.5M live (50% 43486848+34704) *** GC: 97 ms, 84.3M alloc, 168M heap, 83.5M live (50% 87527232+34704) *** GC: 200 ms, 168M alloc, 336M heap, 168M live (50% 175605712+34704) *** GC: 392 ms, 336M alloc, 672M heap, 336M live (50% 351765360+34704) *** GC: 801 ms, 672M alloc, 1.31G heap, 671M live (50% 704080736+34704) > (##gc) *** GC: 1417 ms, 1.15G alloc, 2.30G heap, 1.15G live (50% 1232640240+34704) > (set! t #f) > (##gc) *** GC: 943 ms, 1.15G alloc, 2.30G heap, 1.15G live (50% 1232640192+34704) 2. Making many threads, starting them and waiting for termination ----------------------------------------------------------------- Gambit v4.5.1 > (gc-report-set! #t) > (##gc) *** GC: 3 ms, 1.33M alloc, 2.14M heap, 654K live (30% 635200+34704) > (define t (do ((i 0 (+ 1 i)) (l '() (cons (make-thread (lambda () (void))) l))) ((> i 1000000) l))) *** GC: 4 ms, 2.83M alloc, 4.77M heap, 2.12M live (44% 2187824+34704) *** GC: 6 ms, 5.47M alloc, 10.0M heap, 4.76M live (47% 4953664+34704) *** GC: 14 ms, 10.7M alloc, 20.5M heap, 10.0M live (49% 10460704+34704) *** GC: 26 ms, 21.2M alloc, 41.5M heap, 20.5M live (49% 21468624+34704) *** GC: 51 ms, 42.2M alloc, 83.5M heap, 41.5M live (50% 43486848+34704) *** GC: 97 ms, 84.2M alloc, 168M heap, 83.5M live (50% 87527232+34704) *** GC: 199 ms, 168M alloc, 336M heap, 168M live (50% 175605712+34704) *** GC: 396 ms, 336M alloc, 672M heap, 336M live (50% 351765360+34704) *** GC: 814 ms, 672M alloc, 1.31G heap, 671M live (50% 704080736+34704) > (##gc) *** GC: 1404 ms, 1.15G alloc, 2.30G heap, 1.15G live (50% 1232640240+34704) > (for-each (lambda (x) (thread-start! x) (thread-join! x)) t) > (##gc) *** GC: 660 ms, 1.55G alloc, 1.16G heap, 596M live (50% 624635824+34704) > (set! t #f) > (##gc) *** GC: 133 ms, 1.55G alloc, 2.14M heap, 654K live (30% 635200+34704) --------------------------------------------------------------------- The question is: why GC does not collect unreferenced thread objects in first case and do collect them in second case? Vasil

2 2

gsc segfaults
by Ralf Schmitt 28 Aoû '09

28 Aoû '09

Hi all, I get a segfault when trying to compile srfi-13: $ curl -O http://srfi.schemers.org/srfi-13/srfi-13.scm $ gsc -e '(load "~~/lib/syntax-case.scm")' srfi-13.scm zsh: segmentation fault gsc -e '(load "~~/lib/syntax-case.scm")' srfi-13.scm this happens with gambit v4.5.1 on a x86-64 arch linux using gcc 4.4.1. Regards, - Ralf

5 5

Problems with using both -o and -c at the commandline with v4.5.1
by Cameron Hatfield 27 Aoû '09

27 Aoû '09

I've been trying for a little bit now to try to get this type of command line working: gsc -:d- -c -o <build directory>\<sub set build directory> ..\<some set of paths>\main.scm > out.txt And I end up with this error: *** ERROR IN ##main -- string expected for output: parameter What am I doing wrong? At least judging by the documentation, using the flags together should be supported. I've also tried many different permutation of the above command, just in case including: gsc -:d- -o <build directory>\<sub set build directory> -c ..\<some set of paths>\main.scm > out.txt gsc -:d- -o -c <build directory>\<sub set build directory> ..\<some set of paths>\main.scm > out.txt gsc -:d- -c <build directory>\<sub set build directory> ..\<some set of paths>\main.scm > out.txt Full story: I'm trying to get the gambit compiler working with the waf build system. Currently using this as the arguments to the build step: gsc -:d- -c -o ${TGT[0].bld_dir(env)} ${SRC} > out.txt Sadly, all I get is the above error. Any ideas? Thanks, Cameron

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Gambit-list Août 2009