Does anyone know approximately what the minimum work size is needed in order for a goroutine to be beneficial (assuming that there are free cores for the work to be offloaded to)?
+2
A:
I've been plodding through project euler with Go. While I don't have a definite answer for you I found the goroutine-based primality sieve in the Go docs to be an order of magnitude slower than simply checking each number for primality. Setting GOMAXPROCS to a higher value didn't help, either.
fbrereto
2009-11-14 04:33:46
Parallelization only helps with speed if the results are independent, or can be broken up into independent chunks. The prime sieve, however, explicitly depends on the previous results: it's not really parallel if all but one of the goroutines are blocking at any given time.
Jurily
2009-11-14 07:54:43
+4
A:
goroutine is an abstraction that you use if it helps you model your application better. You're doing concurrency oriented programming, so think about the parts of your application that have concurrency within them.
Think about an OO system and imagine asking the same question about whether you should instantiate an object.
Do the thing that makes sense first.
Dustin
2009-11-14 06:31:49
Exactly, goroutines are 'just' a very useful conceptual abstraction to organize your programs. That they help increase performance by making parallelization simple is just a nice side effect.
uriel
2009-11-14 14:03:38
+1
A:
goroutines are lightweight and don't take up much resources. You should use them where ever it is appropriate to the problem. Currently go doesn't seem to be exceptionally good at using multiple cores (it seems there is a bit too much overhead in allocating additional host threads.)
I think the real question is when to use multiple cores rather than when to use goroutines. The answer to that is probably the same as for other languages and additional host processes. (Unfortunately you can't easily specify when a goroutine should occupy a new host process or which process it should occupy.)
smosher
2009-11-14 11:36:42
go-routines don't actually allocate new threads as the routines are mutliplexed over existing system threads. It does basically come down to when is it beneficial to use multiple cores; however, the answer will not be the same as other languages as other comparable languages (c, c++, java) do not have a built-in parallel construct and have to be manually managed or use a pre-compiler construct like openMP
Mark
2009-11-16 03:30:38
Yes, I understand that. My post is commenting on the fact that the number of host processes should be limited when using goroutines in situations where allocating host processes is inappropriate.
smosher
2009-11-16 04:11:36
A:
Using goroutines isn't just about hardware efficiency. Sometimes they make the software easier to write and make it easier to keep bugs out. The language allows the programmer to express concurrency naturally and simply. That's worth a lot to me.
My own experience with problems that are natural candidates for concurrency is that go easily allows me to max out all the available cores on CPU bound problems using a trivial "scatter/gather" approach. Your mileage may vary.
Hotei
Hotei
2010-05-06 20:07:30