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

gambit-js
by Patrick Logan 13 Déc '12

13 Déc '12

Is the gambit-js / gvm-to-javascript / universal backend source available somewhere? I poked around just a little and did not come across it. Thanks -Patrick

3 3

ELS13
by Marc Feeley 29 Nov '12

29 Nov '12

;; ______ _ _____ _ __ ____ ;; | ____| | | / ____| ( ) /_ | |___ \ ;; | |__ | | | (___ |/ | | __) | ;; | __| | | \___ \ | | |__ < ;; | |____ | |____ ____) | | | ___) | ;; |______| |______| |_____/ |_| |____/ ;; ;; European Lisp Symposium 2013 - ELS'13 ;; Madrid, Spain ;; ;; June 1-4, 2013 ;; ;; http://els2013.european-lisp-symposium.org/ The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The main theme of the 2013 European Lisp Symposium is on the use of these languages with respect to the current grand challenges: big tables, open data, semantic web, network programming, discovery, robustness, runtime failures, etc. The European Lisp Symposium 2013 solicits the submission of papers with these specific themes in mind, alongside the more traditional tracks which have appeared in the past editions. We invite submissions in the following forms: Papers: Technical papers of up to 15 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 4 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. Lightning talks: Abstracts of up to one page for talks to last for no more than 5 minutes. All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. Invited speakers: Florian Loitsch, Google: Dart, why you should care. GÈrard Assayag, Ircam: Lisp and Music Research. Important dates: March, 1st 2013: submission deadline April, 5th 2013: acceptance results June, 1-4 2013: symposium Program Commitee: Pascal Costanza, Belgium Ludovic Courtes, INRIA, France Theo D'Hondt, Vrije Universiteit Brussel, Belgium Florian Loitsch, Google, Denmark Christian Queinnec, UPMC, France Kurt Noermark, Denmark Olin Shivers, Northeastern University, USA Manuel Serrano, INRIA, France Didier Verna, EPITA, France Chair: Juan Jose Garcia-Ripoll, local organizer Christian Queinnec, PC co-chair Manuel Serrano, PC co-chair

2 1

(Good til ~Feb or so:) Complete guide to how to set up Black Hole non-syntactictower version, the "std bundled libs" directory, and the Sack web server and client middleware , inclusive of all .tar.gz files required (copy kept on Dumping Grounds as long as relevant).
by Mikael 28 Nov '12

28 Nov '12

(Per: Message for you at the bottom!) Hi Matthew and anyone interested in getting BH non-syntactictower + std-bundled libs + Sack going, *Objective* To make you get going in a Black Hole environment that's been proven by experience to work very very well, giving a rapid start with 'batteries included'-style nicety, which is of value for those who are at a beginner level in these particular tools and libraries. *Note on **validity duration of this email* Basically this email ought to be as good as the last said word, until ~February 2013. Regarding BH, this email and files referred to here will be valid until the BH repos and docs online have been tweaked and a bit restructured. A separate annoncement will be made when this has happened. Regarding Sack, this email and files referred to here are valid currently. The work needed to make the Sack github repo<https://github.com/pereckerdal/sack/> support both Black Hole versions out of the box is almost nil but has not been done. I'll do this personally at latest at the time the step above is done. For anyone interested, there's a production-quality HTTPS server extension to Sack. The next days as from this writing, the HTTPS client functionality is tweaked, as well as an asynchronous http* client API introduced, similar to XmlHttpRequest. If you want this, ask for it. This is a limited-purpose snapshot and for the Black Hole + bundled libs archive, GIT repo files have been duly omitted. *Prerequisites *Super-basic knowledge of Gambit, in particular naturally understanding when ,q = quit Gambit, is needed. Gambit installed on your system. Paths here are written from a Unix point of view but making it go on Windows is straightforward. Optional: Gambit compiled from source, and the source still available in your home directory (~/gambc-v4*). *To install these software components, please follow the following installation steps:* * * Download the archive with non-syntactictower Black Hole and the "bundled libs", + archive overview:* * Download 2012-11-28-bh-non-syntactictower+bundled-libs.tar.gzavailable for direct download at Gambit's Dumping Grounds page<http://dynamo.iro.umontreal.ca/wiki/index.php/Dumping_Grounds#Module_systems> . It will be available there for as long as it's not clearly obsolete. This is a file set that has two parts: * In the root directory: BH, that equals the legacy branch with pull request 45 linked to above included, though I'm sending it to you separately also just to be really safe you get the right thing. * In the std/ directory: The "bundled libraries" found on https://github.com/pereckerdal/std , though in a more tested and tried version, and with some extensions. * Untar this file in your home directory (~), i.e. cd ~; tar xvfz bh-non-syntactictower+bundled-libs.tar.gz . * Compile Black Hole: cd blackhole; gsc build * * Set up Black Hole:* * Make a /usr/bin/bsc file: cat > /usr/bin/bsc #!/bin/sh gsc -:dar,t8,l30,m20000,-n,tn,f8 -e '(load "~~/lib/blackhole/build.o1")(set! module#*compiler-options* (list (string->symbol "debug")))' $@ - [ctrl+D] chmod +x /usr/bin/bsc * Make ~~/lib/blackhole/build.o1 link to ~/blackhole/build.o1: ln -s /usr/local/Gambit-C/lib/blackhole ~/blackhole * For the package resolver for the std package to find module files, which it looks for in ~~/lib/modules/std : ln -s /usr/local/Gambit-C/lib/modules ~/blackhole * * * * Set up the bundled libraries:* * the (std net/tcp-ip) module has some lowlevel dependencies, if you want access to it, copy lib/*.h of your Gambit source distribution into /usr/local/Gambit-C/lib/ i.e. something like: cd ~/gambc-v4[tab] cd lib cp *.h /usr/local/Gambit-C/lib/ * Compile the bundle libraries: bsc (modules-compile! (modules-in-dir "~~/lib/modules"))) Please note that compiling the (std string/digest) module may occupy ~1.5-2GB memory. The others should be require much less though. * * Set up the Sack web server and client middleware:* * Create a project directory for yourself, say ~/proj : mkdir ~/proj; cd ~/proj * Download the 2012-11-28-sack-current-for-BH-non-syntactictower.tar.gzfile from Gambit's Dumping Grounds page<http://dynamo.iro.umontreal.ca/wiki/index.php/Dumping_Grounds#Networking_2>. It will be available there for as long as it's not clearly obsolete. * Unpack Sack into ~/proj/lib : mkdir ~/proj/lib; cd ~/proj/lib; tar xvfz ../sack-current-2012-11-28-for-BH-non-syntactictower.tar.gz; cd .. * Optional: Compile Sack: bsc (modules-compile! (modules-in-dir "lib/sack"))) *Done!* * * You can now run Gambit with Black Hole from your shell anytime under the name bsc . It's nicely pre-setup with UTF-8 encoding, clear exception reporting, and per-line output buffering for performance (note, invoking |force-output| after any |display| etc. may be needed). * * *Example HTTP server:* (presuming you're in ~/proj :) bsc (import (std misc/u8v) lib/sack/src/server) (define (simple-webserver! server #!rest rest) (apply sack-start! (cons (lambda (env) (let ((first? #t)) (values 200 '(("Content-Type" . "text/html")) (lambda () (let ((r (and first? (string->utf8-u8vector (server))))) (set! first? #f) r))))) rest))) (simple-webserver! (lambda () "Hello World!") port-number: 5000) *Example HTTP client:* (presuming you're in ~/proj :) bsc (import (std misc/u8v) lib/sack/src/http-client) (utf8-u8vector->string (http-response-get-content (http-get-url " http://dynamo.iro.umontreal.ca/wiki/index.php/Main_Page"))) If you have any queries please don't hesitate to ask. Mikael (*Per:* Dear Per, Through this email I'm providing a temporary workaround for the following, though, can you please include this pull request https://github.com/pereckerdal/blackhole/pull/45 in the legacy BH repo? Matthew and anyone downloading legacy BH from github is experiencing complete malfunction until this pull request is included. Thanks!) 2012/11/28 Matthew Phillips <matthew(a)phillipsoft.biz> > > > On Wed, Nov 28, 2012 at 3:26 PM, Mikael <mikael.rcv(a)gmail.com> wrote: > >> Ah, noted Sack uses the syntactictower branch's module naming scheme for >> SRFI:s. Let me know if I should email over one with the non-syntactictower >> branch's. >> >> >> Apart from what's released online yet, Sack has stable HTTPS server >> support, let me know if you want it. >> >> >> Release of improved HTTPS client support as well as an asynchronous HTTP* >> client API (akin to the API exported by the web browser XHR object) is >> underway. >> >> Brgds >> >> >> > If you could send me the Sack that works with the legacy branch, that > would be wonderful. >

2 2

Http Client confusion
by Matthew Phillips 28 Nov '12

28 Nov '12

Must be a user error, according to the Black Hole documentation there is an http client in std, but that doesn't seem to the case: Gambit Scheme w/ Black Hole (import (std net/http-client)) *** ERROR IN ##execute-program -- No such file or directory (with-input-from-file "/home/matthew/.blackhole/pkgs/std-v0.0.4/net/http-client.scm" '#<procedure #2 bh#read-all-expr>) matthew@notebook-server:~/Downloads/gambtest/sack/src$ ls ~/.blackhole/pkgs/std- v0.0.4/net/ tcpip.ol tcpip.scm So I decide to try Sack, looks to be still developed. Gambit Scheme w/ Black Hole (import http-client) *** ERROR IN ##execute-program -- These variables are undefined: (string->u8vector write-urlencoded) #<module-reference #9 loader: #<loader #10 name: local> path: "/home/matthew... So no luck on this one either. I'm close to doing the dreaded right-it-yourself but would rather not, so far I'm not having luck with BH.

2 3

R7RS 7th draft available
by Alex Shinn 10 Nov '12

10 Nov '12

[Sent to multiple lists via bcc.] The seventh and semi-final draft is available at: http://trac.sacrideo.us/wg/raw-attachment/wiki/WikiStart/r7rs-draft-7.pdf This includes many changes from the 6th draft, including those resulting from the many formal (and informal) comments we received. Thanks to everyone who helped! The Steering Committee will form an electorate and call for ratification based on this draft, after which we will fix any errors in the eighth and final draft. Any issues arising after that point will be tracked separately in an errata list. A release of chibi-scheme with all changes up to this point will be made shortly, along with a full R7RS test suite. -- Alex

1 0

Re: [gambit-list] [racket] translate from Racket to Common Lisp
by Marc Feeley 07 Nov '12

07 Nov '12

Le 2012-11-06 à 3:50 AM, Hugh Aguilar <hughaguilar96(a)yahoo.com> a écrit : > I am very impressed that Racket is as fast as it is. I had expected the compilers such as Gambit to be much faster than the VM-JIT system. If Racket had a 64-bit x86 assembler available, I might even consider using it instead of Gambit. > > > Message: 1 > Date: Mon, 5 Nov 2012 08:09:19 -0500 > From: Sam Tobin-Hochstadt <samth(a)ccs.neu.edu> > To: Matthew Flatt <mflatt(a)cs.utah.edu> > Cc: "users(a)racket-lang.org" <users(a)racket-lang.org> > Subject: Re: [racket] translate from Racket to Common Lisp > Message-ID: > <CAK=HD+Yyr1R4K6emrgSXqie2c_AmT1BzhLpP1X=1NDXRgzsjGg(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > It's impressive to note the change in relative performance for Racket > over past 3 years since you published the benchmarks on the blog -- > Racket has gone from slower than Gambit on the majority of benchmarks, > sometimes by a significant margin, to faster on most of them, and > never more than 2x slower (except ctak). For your information, it seems that the change in relative performance has more to do with the change in C compiler over the past 3 years than anything else. The benchmarks were run on Mac OS X with the C compiler available with Xcode. Recently Apple dropped distributing the GNU gcc compiler with Xcode, and the "gcc" program that is installed is actually a version which uses the gcc compiler parser but LLVM as a back-end (i.e. llvm-gcc). That C compiler has bugs which prevent using gcc's computed gotos which are critical for the best performance. This is what Gambit's "configure" script has to say when using llvm-gcc: configure: ************************************************************************** *** *** *** The LLVM GCC compiler that is being used may have a bug in the *** *** compilation of label values (i.e. &&label). This bug was *** *** discovered when compiling Gambit with Xcode on Mac OS X (see bug *** *** ID# 9956714). For this reason the use of computed gotos in the *** *** generated code has been disabled. This greatly reduces the run *** *** time performance. The system runs 5 times slower than when it is *** *** compiled with GNU GCC. It is highly recommended that you use *** *** another C compiler if possible. *** *** *** ************************************************************************** I have suggested to Matthew that he rerun the benchmarks on a linux machine where GNU gcc is the default C compiler. It will be interesting to see how that affects performance. Marc

5 11

Slow Bit Hacking with c-lambda
by tcl super dude 07 Nov '12

07 Nov '12

Hi everyone, I have been working on an image processing library that I want to use on android. I know that performance is a bit of a problem on image processing, so I started to study some bit hacking to improve the performance on my integer operations. My problem now is that I don't know why my c-lambdas take so much time to execute. All operations take constant time and there is no branching. Probably is some sort of conversion time between C types and GAMBIT types. I expected min-integer and abs-integer to be a lot faster than min and abs, respectively. Any help is appreciated. URL REFERENCE: http://graphics.stanford.edu/~seander/bithacks.html#IntegerAbs http://graphics.stanford.edu/~seander/bithacks.html#IntegerMinOrMax MY ENVIRONMENT: Linux casa 3.6.4-1-ARCH #1 SMP PREEMPT Mon Oct 29 15:13:56 CET 2012 i686 GNU/Linux gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/lto-wrapper Target: i686-pc-linux-gnu Configured with: /build/src/gcc-4.7.2/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id --with-ppl --enable-cloog-backend=isl --disable-ppl-version-check --disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu --disable-multilib --disable-libssp --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-checking=release Thread model: posix gcc version 4.7.2 (GCC) Gambit v4.6.6 (SINGLE HOST and GCC extensions enabled) SCHEME CODE: compiled with ---> gambitc -exe bithacks.scm ;; bithacks.scm (declare (not safe) (fixnum) (inline) (inline-primitives)) ;; INTEGER ABSOLUTE (define abs-integer (c-lambda (int) int "// we want to find the absolute value of arg1 int const mask = ___arg1 >> sizeof(int) * CHAR_BIT - 1; ___result = (___arg1 + mask) ^ mask;")) (define min-integer (c-lambda (int int) int "// find the smaller of arg1 arg2 ___result = ___arg2 ^ ((___arg1 ^ ___arg2) & -(___arg1 < ___arg2));")) (define (test-abs) (let ((result 0)) (begin (display "abs:\n") (time (let loop-i ((i 0)) (cond ((fx< i 100000) (set! result (abs i)) (loop-i (fx+ 1 i)))))) (display "abs-integer:\n") (time (let loop-j ((j 0)) (cond ((fx< j 100000) (set! result (abs-integer j)) (loop-j (fx+ 1 j))))))))) (define (test-min) (let ((result 0)) (begin (display "min:\n") (time (let loop-i ((i 0)) (cond ((fx< i 100000) (set! result (min i result)) (loop-i (fx+ 1 i)))))) (display "min-integer:\n") (time (let loop-j ((j 0)) (cond ((fx< j 100000) (set! result (min-integer j result)) (loop-j (fx+ 1 j))))))))) ;; run tests (test-abs) (test-min) ;;;;;;;;;;;;;;;;;;;;;; RESULTS;;;;;;;;;;;;;;;;;;;;; abs: (time (let loop-i ((i 0)) (cond ((fx< i 100000) (set! result (abs i)) (loop-i (fx+ 1 i)))))) 2 ms real time 3 ms cpu time (3 user, 0 system) no collections no bytes allocated no minor faults no major faults abs-integer: (time (let loop-j ((j 0)) (cond ((fx< j 100000) (set! result (abs-integer j)) (loop-j (fx+ 1 j)))))) 22 ms real time 23 ms cpu time (23 user, 0 system) no collections no bytes allocated 2 minor faults no major faults min: (time (let loop-i ((i 0)) (cond ((fx< i 100000) (set! result (min i result)) (loop-i (fx+ 1 i)))))) 2 ms real time 3 ms cpu time (0 user, 3 system) no collections no bytes allocated no minor faults no major faults min-integer: (time (let loop-j ((j 0)) (cond ((fx< j 100000) (set! result (min-integer j result)) (loop-j (fx+ 1 j)))))) 28 ms real time 30 ms cpu time (27 user, 3 system) no collections no bytes allocated no minor faults no major faults

3 3

Re: [gambit-list] Slow Bit Hacking with c-lambda
by tcl super dude 04 Nov '12

04 Nov '12

Now scheme min is even faster.. that is ok. But what I don't understand is how that simple C implementation get so low performance. abs: (time (let loop-i ((i 0)) (cond ((fx< i 100000) (set! result (abs i)) (loop-i (fx+ 1 i)))))) 1 ms real time 0 ms cpu time (0 user, 0 system) no collections no bytes allocated no minor faults no major faults abs-integer: (time (let loop-j ((j 0)) (cond ((fx< j 100000) (set! result (abs-integer j)) (loop-j (fx+ 1 j)))))) 18 ms real time 17 ms cpu time (17 user, 0 system) no collections no bytes allocated 1 minor fault no major faults min: (time (let loop-i ((i 0)) (cond ((fx< i 100000) (set! result (min i result)) (loop-i (fx+ 1 i)))))) 0 ms real time 0 ms cpu time (0 user, 0 system) no collections no bytes allocated no minor faults no major faults min-integer: (time (let loop-j ((j 0)) (cond ((fx< j 100000) (set! result (min-integer j result)) (loop-j (fx+ 1 j)))))) 26 ms real time 26 ms cpu time (23 user, 3 system) no collections no bytes allocated no minor faults no major faults On Sun, Nov 4, 2012 at 7:31 PM, Mikael More <mikael.more(a)gmail.com> wrote: > Ah, also throw in the following: > * (declare (not interrupts-enabled)) > > This might be a big deal - when it's off, Gambit doesn't produce any > hooks for stack overflow or thread system interrupts but executes your code > according to a typical C model > > * (declare (standard-bindings) (extended-bindings)) too? > > > What is the performance you get from Gambit now, and what kind of > performance is it you want to get? > > > 2012/11/4 tcl super dude <tcleval(a)gmail.com> > >> I assumed I could get a bit of performance improvement over min procedure >> because I don't do any branch. I' thought min-integer to be at least close >> to gambit-c time. The problem is that those operations and a few more are >> performed thousands of times. Gambit loops are usually 2x slower than C, so >> I hoped I could improve some basic operations as I only perform them on >> integers. I don't Understand how a simple shift to extract the lower bits >> could make so much difference. Maybe if someone point me to the >> implementation of min and abs on gambit, I can understand the difference. I >> ve looked for these procedures on gambit's source but could not point it >> out. >> >> I'll try to implement them using vectors and see what happens. >> >> now compiled with (block): >> >> >> abs: >> >> (time (let loop-i ((i 0)) (cond ((fx> (loop-i (fx+ 1 i)))))) >> 2 ms real time >> >> 3 ms cpu time (3 user, 0 system) >> >> no collections >> >> no bytes allocated >> >> no minor faults >> >> no major faults >> >> abs-integer: >> >> (time (let loop-j ((j 0)) (cond ((fx< j 100000) (set! result (abs-integer >> j)) (loop-j (fx+ 1 j)))))) >> 19 ms real time >> >> 20 ms cpu time (17 user, 3 system) >> >> no collections >> >> no bytes allocated >> >> 2 minor faults >> >> no major faults >> >> min: >> >> (time (let loop-i ((i 0)) (cond ((fx> result)) (loop-i (fx+ 1 i)))))) >> 2 ms real time >> >> 3 ms cpu time (0 user, 3 system) >> >> no collections >> >> no bytes allocated >> >> no minor faults >> no major faults >> min-integer: >> (time (let loop-j ((j 0)) (cond ((fx< j 100000) (set! result (min-integer >> j result)) (loop-j (fx+ 1 j)))))) >> 27 ms real time >> 27 ms cpu time (27 user, 0 system) >> no collections >> no bytes allocated >> no minor faults >> no major faults >> >> >> On Sun, Nov 4, 2012 at 5:15 PM, Mikael <mikael.rcv(a)gmail.com> wrote: >> >>> First, please add (declare (block)) and re-compile, this way Gambit >>> won't need to re-look up the procedures in the global namespace that you >>> call, on each invocation. Please report what kind of improvement you got >>> with this. >>> >>> >>> Now just to make this round of emails complete: >>> >>> What would be good/very good performance in your view? >>> >>> Could you send jobs in some kind of batch format to C? >>> >>> Note that Gambit-internal fxnum variables have a special encoding (the >>> lowermost two(?) bits are object type identifier, which are shifted out >>> when converting them to C int), this takes a little bit of time. >>> >>> If for instance you make u32vectors/s32vectors/etc. [and send batch ops >>> made on those to C to be performed etc.] then you can just read out the >>> content of those vectors 'raw' in C, there's no interconversion there. >>> >>> Brgds >>> >>> 2012/11/4 tcl super dude <tcleval(a)gmail.com> >>> >>>> Hi everyone, >>>> >>>> I have been working on an image processing library that I want to use >>>> on android. I know that performance is a bit of a problem on image >>>> processing, so I started to study some bit hacking to improve the >>>> performance on my integer operations. My problem now is that I don't know >>>> why my c-lambdas take so much time to execute. All operations take constant >>>> time and there is no branching. Probably is some sort of conversion time >>>> between C types and GAMBIT types. I expected min-integer and abs-integer to >>>> be a lot faster than min and abs, respectively. Any help is appreciated. >>>> >>>> URL REFERENCE: >>>> http://graphics.stanford.edu/~seander/bithacks.html#IntegerAbs >>>> http://graphics.stanford.edu/~seander/bithacks.html#IntegerMinOrMax >>>> >>>> >>>> MY ENVIRONMENT: >>>> Linux casa 3.6.4-1-ARCH #1 SMP PREEMPT Mon Oct 29 15:13:56 CET 2012 >>>> i686 GNU/Linux >>>> >>>> gcc -v >>>> Using built-in specs. >>>> COLLECT_GCC=gcc >>>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/lto-wrapper >>>> Target: i686-pc-linux-gnu >>>> Configured with: /build/src/gcc-4.7.2/configure --prefix=/usr >>>> --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man >>>> --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared >>>> --enable-threads=posix --with-system-zlib --enable-__cxa_atexit >>>> --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch >>>> --enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id >>>> --with-ppl --enable-cloog-backend=isl --disable-ppl-version-check >>>> --disable-cloog-version-check --enable-lto --enable-gold >>>> --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold >>>> --with-linker-hash-style=gnu --disable-multilib --disable-libssp >>>> --disable-build-with-cxx --disable-build-poststage1-with-cxx >>>> --enable-checking=release >>>> Thread model: posix >>>> gcc version 4.7.2 (GCC) >>>> >>>> Gambit v4.6.6 (SINGLE HOST and GCC extensions enabled) >>>> >>>> >>>> SCHEME CODE: compiled with ---> gambitc -exe bithacks.scm >>>> >>>> ;; bithacks.scm >>>> >>>> >>>> (declare >>>> (not safe) >>>> (fixnum) >>>> (inline) >>>> (inline-primitives)) >>>> >>>> ;; INTEGER ABSOLUTE >>>> (define abs-integer >>>> (c-lambda (int) int >>>> "// we want to find the absolute value of arg1 >>>> int const mask = ___arg1 >> sizeof(int) * CHAR_BIT - 1; >>>> ___result = (___arg1 + mask) ^ mask;")) >>>> >>>> >>>> (define min-integer >>>> (c-lambda (int int) int >>>> "// find the smaller of arg1 arg2 >>>> ___result = ___arg2 ^ ((___arg1 ^ ___arg2) & -(___arg1 < >>>> ___arg2));")) >>>> >>>> (define (test-abs) >>>> (let ((result 0)) >>>> (begin >>>> (display "abs:\n") >>>> (time >>>> (let loop-i ((i 0)) >>>> (cond ((fx>>> (set! result (abs i)) >>>> (loop-i (fx+ 1 i)))))) >>>> (display "abs-integer:\n") >>>> (time >>>> (let loop-j ((j 0)) >>>> (cond ((fx< j 100000) >>>> (set! result (abs-integer j)) >>>> (loop-j (fx+ 1 j))))))))) >>>> >>>> (define (test-min) >>>> (let ((result 0)) >>>> (begin >>>> (display "min:\n") >>>> (time >>>> (let loop-i ((i 0)) >>>> (cond ((fx>>> (set! result (min i result)) >>>> (loop-i (fx+ 1 i)))))) >>>> (display "min-integer:\n") >>>> (time >>>> (let loop-j ((j 0)) >>>> (cond ((fx< j 100000) >>>> (set! result (min-integer j result)) >>>> (loop-j (fx+ 1 j))))))))) >>>> >>>> ;; run tests >>>> >>>> (test-abs) >>>> (test-min) >>>> >>>> ;;;;;;;;;;;;;;;;;;;;;; RESULTS;;;;;;;;;;;;;;;;;;;;; >>>> >>>> abs: >>>> (time (let loop-i ((i 0)) (cond ((fx>>> (loop-i (fx+ 1 i)))))) >>>> 2 ms real time >>>> 3 ms cpu time (3 user, 0 system) >>>> no collections >>>> no bytes allocated >>>> no minor faults >>>> no major faults >>>> abs-integer: >>>> (time (let loop-j ((j 0)) (cond ((fx< j 100000) (set! result >>>> (abs-integer j)) (loop-j (fx+ 1 j)))))) >>>> 22 ms real time >>>> 23 ms cpu time (23 user, 0 system) >>>> no collections >>>> no bytes allocated >>>> 2 minor faults >>>> no major faults >>>> min: >>>> (time (let loop-i ((i 0)) (cond ((fx>>> result)) (loop-i (fx+ 1 i)))))) >>>> 2 ms real time >>>> 3 ms cpu time (0 user, 3 system) >>>> no collections >>>> no bytes allocated >>>> no minor faults >>>> no major faults >>>> min-integer: >>>> (time (let loop-j ((j 0)) (cond ((fx< j 100000) (set! result >>>> (min-integer j result)) (loop-j (fx+ 1 j)))))) >>>> 28 ms real time >>>> 30 ms cpu time (27 user, 3 system) >>>> no collections >>>> no bytes allocated >>>> no minor faults >>>> no major faults >>>> >>>> >>>> _______________________________________________ >>>> Gambit-list mailing list >>>> Gambit-list(a)iro.umontreal.ca >>>> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list >>>> >>>> >>> >> >> _______________________________________________ >> Gambit-list mailing list >> Gambit-list(a)iro.umontreal.ca >> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list >> >> >

2 3

Re: [gambit-list] Slow Bit Hacking with c-lambda
by Mikael 04 Nov '12

04 Nov '12

Ah, also throw in the following: * (declare (not interrupts-enabled)) This might be a big deal - when it's off, Gambit doesn't produce any hooks for stack overflow or thread system interrupts but executes your code according to a typical C model * (declare (standard-bindings) (extended-bindings)) too? What is the performance you get from Gambit now, and what kind of performance is it you want to get? 2012/11/4 tcl super dude <tcleval(a)gmail.com> > I assumed I could get a bit of performance improvement over min procedure > because I don't do any branch. I' thought min-integer to be at least close > to gambit-c time. The problem is that those operations and a few more are > performed thousands of times. Gambit loops are usually 2x slower than C, so > I hoped I could improve some basic operations as I only perform them on > integers. I don't Understand how a simple shift to extract the lower bits > could make so much difference. Maybe if someone point me to the > implementation of min and abs on gambit, I can understand the difference. I > ve looked for these procedures on gambit's source but could not point it > out. > > I'll try to implement them using vectors and see what happens. > > now compiled with (block): > > > abs: > > (time (let loop-i ((i 0)) (cond ((fx (loop-i (fx+ 1 i)))))) > 2 ms real time > > 3 ms cpu time (3 user, 0 system) > > no collections > > no bytes allocated > > no minor faults > > no major faults > > abs-integer: > > (time (let loop-j ((j 0)) (cond ((fx< j 100000) (set! result (abs-integer > j)) (loop-j (fx+ 1 j)))))) > 19 ms real time > > 20 ms cpu time (17 user, 3 system) > > no collections > > no bytes allocated > > 2 minor faults > > no major faults > > min: > > (time (let loop-i ((i 0)) (cond ((fx result)) (loop-i (fx+ 1 i)))))) > 2 ms real time > > 3 ms cpu time (0 user, 3 system) > > no collections > > no bytes allocated > > no minor faults > no major faults > min-integer: > (time (let loop-j ((j 0)) (cond ((fx< j 100000) (set! result (min-integer > j result)) (loop-j (fx+ 1 j)))))) > 27 ms real time > 27 ms cpu time (27 user, 0 system) > no collections > no bytes allocated > no minor faults > no major faults > > > On Sun, Nov 4, 2012 at 5:15 PM, Mikael <mikael.rcv(a)gmail.com> wrote: > >> First, please add (declare (block)) and re-compile, this way Gambit won't >> need to re-look up the procedures in the global namespace that you call, on >> each invocation. Please report what kind of improvement you got with this. >> >> >> Now just to make this round of emails complete: >> >> What would be good/very good performance in your view? >> >> Could you send jobs in some kind of batch format to C? >> >> Note that Gambit-internal fxnum variables have a special encoding (the >> lowermost two(?) bits are object type identifier, which are shifted out >> when converting them to C int), this takes a little bit of time. >> >> If for instance you make u32vectors/s32vectors/etc. [and send batch ops >> made on those to C to be performed etc.] then you can just read out the >> content of those vectors 'raw' in C, there's no interconversion there. >> >> Brgds >> >> 2012/11/4 tcl super dude <tcleval(a)gmail.com> >> >>> Hi everyone, >>> >>> I have been working on an image processing library that I want to use on >>> android. I know that performance is a bit of a problem on image processing, >>> so I started to study some bit hacking to improve the performance on my >>> integer operations. My problem now is that I don't know why my c-lambdas >>> take so much time to execute. All operations take constant time and there >>> is no branching. Probably is some sort of conversion time between C types >>> and GAMBIT types. I expected min-integer and abs-integer to be a lot faster >>> than min and abs, respectively. Any help is appreciated. >>> >>> URL REFERENCE: >>> http://graphics.stanford.edu/~seander/bithacks.html#IntegerAbs >>> http://graphics.stanford.edu/~seander/bithacks.html#IntegerMinOrMax >>> >>> >>> MY ENVIRONMENT: >>> Linux casa 3.6.4-1-ARCH #1 SMP PREEMPT Mon Oct 29 15:13:56 CET 2012 i686 >>> GNU/Linux >>> >>> gcc -v >>> Using built-in specs. >>> COLLECT_GCC=gcc >>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/lto-wrapper >>> Target: i686-pc-linux-gnu >>> Configured with: /build/src/gcc-4.7.2/configure --prefix=/usr >>> --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man >>> --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared >>> --enable-threads=posix --with-system-zlib --enable-__cxa_atexit >>> --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch >>> --enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id >>> --with-ppl --enable-cloog-backend=isl --disable-ppl-version-check >>> --disable-cloog-version-check --enable-lto --enable-gold >>> --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold >>> --with-linker-hash-style=gnu --disable-multilib --disable-libssp >>> --disable-build-with-cxx --disable-build-poststage1-with-cxx >>> --enable-checking=release >>> Thread model: posix >>> gcc version 4.7.2 (GCC) >>> >>> Gambit v4.6.6 (SINGLE HOST and GCC extensions enabled) >>> >>> >>> SCHEME CODE: compiled with ---> gambitc -exe bithacks.scm >>> >>> ;; bithacks.scm >>> >>> >>> (declare >>> (not safe) >>> (fixnum) >>> (inline) >>> (inline-primitives)) >>> >>> ;; INTEGER ABSOLUTE >>> (define abs-integer >>> (c-lambda (int) int >>> "// we want to find the absolute value of arg1 >>> int const mask = ___arg1 >> sizeof(int) * CHAR_BIT - 1; >>> ___result = (___arg1 + mask) ^ mask;")) >>> >>> >>> (define min-integer >>> (c-lambda (int int) int >>> "// find the smaller of arg1 arg2 >>> ___result = ___arg2 ^ ((___arg1 ^ ___arg2) & -(___arg1 < >>> ___arg2));")) >>> >>> (define (test-abs) >>> (let ((result 0)) >>> (begin >>> (display "abs:\n") >>> (time >>> (let loop-i ((i 0)) >>> (cond ((fx>> (set! result (abs i)) >>> (loop-i (fx+ 1 i)))))) >>> (display "abs-integer:\n") >>> (time >>> (let loop-j ((j 0)) >>> (cond ((fx< j 100000) >>> (set! result (abs-integer j)) >>> (loop-j (fx+ 1 j))))))))) >>> >>> (define (test-min) >>> (let ((result 0)) >>> (begin >>> (display "min:\n") >>> (time >>> (let loop-i ((i 0)) >>> (cond ((fx>> (set! result (min i result)) >>> (loop-i (fx+ 1 i)))))) >>> (display "min-integer:\n") >>> (time >>> (let loop-j ((j 0)) >>> (cond ((fx< j 100000) >>> (set! result (min-integer j result)) >>> (loop-j (fx+ 1 j))))))))) >>> >>> ;; run tests >>> >>> (test-abs) >>> (test-min) >>> >>> ;;;;;;;;;;;;;;;;;;;;;; RESULTS;;;;;;;;;;;;;;;;;;;;; >>> >>> abs: >>> (time (let loop-i ((i 0)) (cond ((fx>> (loop-i (fx+ 1 i)))))) >>> 2 ms real time >>> 3 ms cpu time (3 user, 0 system) >>> no collections >>> no bytes allocated >>> no minor faults >>> no major faults >>> abs-integer: >>> (time (let loop-j ((j 0)) (cond ((fx< j 100000) (set! result >>> (abs-integer j)) (loop-j (fx+ 1 j)))))) >>> 22 ms real time >>> 23 ms cpu time (23 user, 0 system) >>> no collections >>> no bytes allocated >>> 2 minor faults >>> no major faults >>> min: >>> (time (let loop-i ((i 0)) (cond ((fx>> result)) (loop-i (fx+ 1 i)))))) >>> 2 ms real time >>> 3 ms cpu time (0 user, 3 system) >>> no collections >>> no bytes allocated >>> no minor faults >>> no major faults >>> min-integer: >>> (time (let loop-j ((j 0)) (cond ((fx< j 100000) (set! result >>> (min-integer j result)) (loop-j (fx+ 1 j)))))) >>> 28 ms real time >>> 30 ms cpu time (27 user, 3 system) >>> no collections >>> no bytes allocated >>> no minor faults >>> no major faults >>> >>> >>> _______________________________________________ >>> Gambit-list mailing list >>> Gambit-list(a)iro.umontreal.ca >>> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list >>> >>> >> > > _______________________________________________ > Gambit-list mailing list > Gambit-list(a)iro.umontreal.ca > https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list > >

1 0

ICFP 2013: Call for workshops and co-located events
by David Van Horn 29 Oct '12

29 Oct '12

CALL FOR WORKSHOP AND CO-LOCATED EVENT PROPOSALS ICFP 2013 18th ACM SIGPLAN International Conference on Functional Programming September 22 - 28, 2013 Boston, Massachusetts, USA http://icfpconference.org/icfp2013/ The 18th ACM SIGPLAN International Conference on Functional Programming will be held in Boston, Massachusetts on September 22-28, 2013. 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 tutorials) to be affiliated with ICFP 2013 and sponsored by SIGPLAN. These events should be more informal and 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 September 22-24 (the three days before ICFP) and September 28 (the day after ICFP). ---------------------------------------------------------------------- Submission details Deadline for submission: December 7, 2012 Notification of acceptance: January 7, 2013 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 2013 workshop co-chairs (Patrik Jansson and Sam Tobin-Hochstadt), via email to icfp13-workshops(a)ccs.neu.edu by December 7, 2012. (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 January 7, 2013, 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/icfp2013/icfp13-workshops-form.txt Further information about SIGPLAN sponsorship is available at: http://acm.org/sigplan/sigplan_workshop_proposal.htm ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2013 organizing committee, together with the members of the SIGPLAN executive committee. Workshop Co-Chair: Patrik Jansson (Chalmers University of Technology) Workshop Co-Chair: Sam Tobin-Hochstadt (Northeastern University) General Chair : Greg Morrisset (Harvard University) Program Chair: Tarmo Uustalu (Tallinn University of Technology) ---------------------------------------------------------------------- Further information Any queries should be addressed to the workshop co-chairs (Patrik Jansson and Sam Tobin-Hochstadt), via email to icfp13-workshops(a)ccs.neu.edu

1 0