On Tue, 2015-03-17 at 20:50 +0000, Bienlein via Digitalmars-d wrote: > > Go is only a CSP-like, it isn't CSP. cf Python-CSP and PyCSP, > > not to > > mention JCSP and GPars. > > I'm not really sure whether this can be put exactly that way. On > a machine with 4 GB RAM you can spawn about 80.000 goroutines > (aka green threads). Let's say each threads calculates a large > fibonacci number. If the fibonacci calculation yields the > processor frequently all 80.000 run seamingly in parallel and > return their result almost "at the same time". > > With GPars this would not work. You can only start some 2.000 > Java threads on a machine with the same amount of memory. If also > the fibonacci calculation in Groovy/GPars yields the processor, > using GPars the first 2.000 fibonacci calculations will > nevertheless crowd out the following 2.000 threads of all those > 80.000 fibonacci calculations and so on. I once tried this out > with both Go and Groovy/GPars.
<This needs to go to the GPars mailing lists list so I have cross posted.> 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. If you have code you can send me, I will run it and do the benchmarking. If not I guess I will have to write some. Until we have the results of executing code, the above must be treated as pure conjecture, which I believe will be refuted. If the claim however turns out to be true, then it highlights a bug in GPars. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
