[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