[gambit-list] threading

Bakul Shah bakul at bitblocks.com
Fri Mar 10 21:32:43 EST 2017


Goroutines are “free running”, which is often sufficient. If you want synchronization, you have to pay for it. Channels are the easiest to use for this and the recommended way. You can factor out channel creation time, by doing so upfront.

> On Mar 10, 2017, at 5:23 PM, Marc Feeley <feeley at iro.umontreal.ca> wrote:
> 
> Bakul, thanks for the suggestion!  I did a quick test and Go does take advantage of multiple cores and performs similarly to Gambit on this benchmark.  I will have to investigate further.
> 
> Are channels necessary in this program to simulate Gambit’s thread-join! ?  I fear this could needlessly add overhead.
> 
> Marc
> 
>> On Mar 10, 2017, at 7:47 PM, Bakul Shah <bakul at bitblocks.com> wrote:
>> 
>> 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