OFFTOPIC: GPars performance vs Go [was Re: A few notes on choosing between Go and D for a quick project]
Russel Winder via Digitalmars-d
digitalmars-d at puremagic.com
Wed Mar 18 01:40:06 PDT 2015
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
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.
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: This is a digitally signed message part
More information about the Digitalmars-d