[gambit-list] threading

Bakul Shah bakul at bitblocks.com
Fri Mar 10 19:47:52 EST 2017


How about Go?

------------
package main

import "fmt"

func fib(n int) int {
        switch {
        case n < 2: return 1
        case n < 20: return fib(n-1) + fib(n - 2)
        default:
                ch := make(chan int)
                go func() {
                        ch<-fib(n-1)
                }()
                fn2 := fib(n-2)
                return fn2 + <- ch
        }
}

func main()  {
        fmt.Println(fib(45))
}
------------

> On Mar 10, 2017, at 3:50 PM, Marc Feeley <feeley at iro.umontreal.ca> wrote:
> 
> Now that truly concurrent threading is working fairly well I decided to benchmark Gambit against Python for a simple threaded program (threaded Fibonacci with a thread granularity of roughly 50 microseconds creating 30,000 threads).  I was happy to see that Gambit performs well.  Here are the timings:
> 
> % time gsi -:p4 tfib.scm 
> 
> real    0m0.355s
> user    0m1.234s
> sys     0m0.041s
> 
> % time python3 tfib.py
> 
> real    0m3.965s
> user    0m3.326s
> sys     0m1.535s
> 
> On 4 processors Gambit has a “user” time that is about 4 times the “real” time, and the system time is almost nil.
> 
> But wait a second… the Python system time is huge and the user and real times are roughly the same… after a little bit of research I just recalled the GIL (Global Interpreter Lock) that effectively serializes the execution of the interpreter so only one thread is active at any point in time (when in the interpreter). I can’t believe how such a crapily implemented language can be so popular…
> 
> Any suggestions for a popular and efficient threaded language to compare to?






More information about the Gambit-list mailing list