OFFTOPIC: GPars performance vs Go [was Re: A few notes on choosing between Go and D for a quick project]

[Bienlein via Digitalmars-d]

> A priori I do not believe the claim made here: a GPars task is 
> submitted
> to a thread pool, which is exactly what the goroutines are. 
> Thus the
> number of Java threads is not a bound on the number of GPars 
> tasks. Any
> bounds will be provided by the Fork/Join pool.

Here is a GPars sample from 
http://www.gpars.org/1.0.0/guide/guide/GroovyCSP.html

final class Copy implements Callable {
     private final DataflowChannel inChannel
     private final DataflowChannel outChannel1
     private final DataflowChannel outChannel2

public def call() {
	final PGroup group = Dataflow.retrieveCurrentDFPGroup()
	while (true) {
		def i = inChannel.val
		group.task {
			outChannel1 << i
			outChannel2 << i
		}.join()
	}
}

If inChannel.val blocks, the thread serving the Copy instance is 
blocked and lost for serving other channels. If this happens 
several times the JVM has run out of threads and the application 
is in limbo.

This is not the case in Go. When a goroutine is blocked by a 
blocking take on an empty channel, the Go scheduler withdraws the 
thread serving this goroutine and assigns it to some other 
goroutine.