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@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@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@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?