I have some news concerning the multiple threaded version of Gambit with encouraging preliminary performance results for mutex based synchronization.

The test program starts N threads that each increment a counter a million times. The incrementation is in a critical section implemented with a global mutex. So this is a scenario where there is intense contention for a single mutex by all the threads. I wrote the program in Scheme and also wrote a C version using pthreads. The Scheme program and the results are attached below.

When the programs are run (on OS X) with more than one thread (I tried 1 to 7 threads on a 4 core machine), the Gambit program is up to 15x faster than the C program using pthreads. Not bad for a first experiment with *no* tuning of the implementation! I think Gambit is so much faster because suspending a thread, which happens frequently here, is very fast thanks to continuations.

Marc

(declare (standard-bindings) (extended-bindings) (fixnum) (not safe) (block))

(define count 0)

(define mut (make-mutex))

(define (body) (let loop ((n 1000000)) (if (> n 0) (begin (mutex-lock! mut) (set! count (+ count 1)) (mutex-unlock! mut) (loop (- n 1))))))

(define (iota n) (let loop ((i (- n 1)) (lst '())) (if (>= i 0) (loop (- i 1) (cons i lst)) lst)))

(define threads (map (lambda (id) (thread-start! (make-thread body))) (iota (##current-vm-processor-count))))

(map thread-join! threads)

(pp count)

% make gsc -exe test1.scm time ./test1 -:p1 1000000 0.08 real 0.08 user 0.00 sys time ./test1 -:p2 2000000 0.33 real 0.33 user 0.00 sys time ./test1 -:p4 4000000 0.82 real 0.91 user 0.06 sys time ./test1 -:p7 7000000 1.55 real 2.21 user 0.31 sys gcc -O pthread1.c -o test1-pthread time ./test1-pthread 1 count=1000000 0.02 real 0.02 user 0.00 sys time ./test1-pthread 2 count=2000000 5.49 real 0.56 user 5.42 sys time ./test1-pthread 4 count=4000000 12.77 real 1.11 user 12.10 sys time ./test1-pthread 7 count=7000000 22.71 real 2.32 user 21.25 sys