Re: GPars Actors don't appear to scale

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: GPars Actors don't appear to scale

Russel Winder-2
Jochen,

Apologies for having taken so long to get back to this -- PhD examining
and workshops on Concepts and C++ took up the last couple of weeks.

On Mon, 2009-10-26 at 19:46 +0100, Jochen Theodorou wrote:
[ . . . ]
> Since I am missing some context, please don't be angry if I say things
> that are known already. Just putting in more CPUs or station doesn't
> mean the algorithm will be faster. It depends on how well the algorithm
> scales and with that of course the underlaying Groovy runtime.

You are right, we know this ;-)

As always, my tests run with embarrassingly parallel computations, i.e.
there is a fork cost and a join cost and no communications in between.
This should therefore lead to close to linear scaling with the number of
independent processors.  The caveat here for multicore processors is the
cache coherence problems.  Currently though my problems are small enough
in memory use that the cores should never have cache misses so this
should factor out the cache and memory access problems.

Using C, C++, Java, Fortran, Scala, Clojure, Python, Erlang, Chapel, C#,
D,

Haskell and OCaml have problems, as it seems Groovy has.  All are
different though.  Haskell has problems because of the lazy
computational model, OCaml has other problems -- similar to those in
Python I understand though Python has a way round it (using MPI inspired
SPMD approaches).

> For each algorithm you have a calculation and a communication part and
> with more CPUs the communication part takes more time, while the
> calculation part takes less time. What you parallelize is of course the
> calculation part only, the communication part is needed to get the end
> result. So for each algorithm you have a maximum of speed that says with
> this many CPUs you are fastest. If you use more, the performance will be
> lowered again. Of course this could mean that this happens with only 1
> CPU already, meaning using a second one will gain no speedup.

This is not a problem in this particular case.  Also this argument is a
language independent one and we have a very language dependent problem
here.

[ . . . ]

> > For different reasons, I am rapidly coming to the same conclusion.  I am
> > rapidly coming to the conclusion that Groovy destroys all parallelism
> > even when it uses all the cores :-(
>
> Not groovy, the runtime implementation. just imagine, that for each and
> every method call you make in Groovy, you have to read from a volatile
> field. This should make clear that then every method call will require
> synchronization with the memory and that for each CPU. This imposes a
> big communication overhead that is even in a single threaded case
> noticeable, especially because it makes hotspot nearly useless. This is
> a thing I intend to target in Groovy 1.8.
Hummm...  I am going to have to think about this a bit more but on the
surface it implies that unless something changes, Groovy is and always
will be completely useless for any sort of multiprocessor computations.
This undermines any and all GPars activity.

Currently, using Java (or Scala) directly it is possible to get near
linear scaling of embarrassingly parallel solutions.  This means the
problem being seen in using GPars is not inherent in the JVM, native
threads and binding of threads to processors (though remember I am
talking only about Ubuntu, Mac OS X, and Solaris here -- I suspect
Windows is unlikely to be able to achieve the desired behaviour, but
this is prejudice on my part).  So unless Groovy can be made not to have
this "lack of cache" behaviour then it rules itself out as a parallelism
coordination language, and I will have to switch back to the use of
Python and Jython.

No matter how much we like Groovy and hence GPars, if it isn't going to
do the job needed we must be honest about this.  There is nothing worse
than pretending a framework can do what it cannot.

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: [hidden email]
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,   f: +44 8700 516 084   voip: sip:[hidden email]
London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GPars Actors don't appear to scale

Russel Winder-2
Weird loss of sentence:

On Wed, 2009-11-11 at 17:47 +0000, Russel Winder wrote:
[ . . . ]

> Using C, C++, Java, Fortran, Scala, Clojure, Python, Erlang, Chapel, C#,
> D,

I get near linear scaling for the problem at hand, so there is nothing
wrong with my algorithm or hardware.

[ . . . ]

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: [hidden email]
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,   f: +44 8700 516 084   voip: sip:[hidden email]
London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GPars Actors don't appear to scale

Alex Tkachman
I have the same applying my static compiler to groovy code adopted
from your java

On Wed, Nov 11, 2009 at 7:52 PM, Russel Winder
<[hidden email]> wrote:

> Weird loss of sentence:
>
> On Wed, 2009-11-11 at 17:47 +0000, Russel Winder wrote:
> [ . . . ]
>
>> Using C, C++, Java, Fortran, Scala, Clojure, Python, Erlang, Chapel, C#,
>> D,
>
> I get near linear scaling for the problem at hand, so there is nothing
> wrong with my algorithm or hardware.
>
> [ . . . ]
>
> --
> Russel.
> =============================================================================
> Dr Russel Winder      Partner
>                                            xmpp: [hidden email]
> Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
> 41 Buckmaster Road,   f: +44 8700 516 084   voip: sip:[hidden email]
> London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: GPars Actors don't appear to scale

Vaclav
Administrator
In reply to this post by Russel Winder-2
Hello Russel,

I'd like to add some comments to your insightful opinion. I'm very glad you've brought the topic up to our attention. It definitely deserves to be widely discussed, since, in my opinion, the Groovy community has to act on the deficiency now or never. Companies are starting to plan they java.next strategies and concurrency is typicaly pretty high on the list of features to look for. A potential candidate for Java replacement must undoubtedly scale well on multi-processors now in the multi-core era.

You clearly showed that Groovy is currently not ready to be used on heavily computational parallel algorithms. Its method invocation mechanism doesn't scale well beyond one cpu or thread and that is certainly bad news for many.
On the other hand, I tend to disagree that non-scalable Groovy renders GPars useless. Far from that, I would say. People use GPars to spouse parallel downloads, file scans, invoke multiple web-services concurrently, in which cases the algorithms scale well in Groovy, since method invocation is no longer the bottleneck. Check the recent "FastTranslate Plugin" (http://docs.codehaus.org/display/GRIFFON/FastTranslate+Plugin) as an example of GPars being used for the purpose. GPars can also effectively orchestrate Java-written routines so that even highly computational calculations would scale (almost) linearly.

Obviously we have to have the Groovy deficiency in mind when choosing features to support in GPars. STM or Dataflow operators make much less sense than, for example, parallel collections, actors, remoting or asynchronous closures.

Even with the scalability issue Groovy still has pretty good chances to become a widely used scripting / configuration / mashup / DSL language and GPars can provide easy-to-use concurrency constructs targeted at these domains.

Cheers,

Vaclav
 



Hummm...  I am going to have to think about this a bit more but on the
surface it implies that unless something changes, Groovy is and always
will be completely useless for any sort of multiprocessor computations.
This undermines any and all GPars activity.

Currently, using Java (or Scala) directly it is possible to get near
linear scaling of embarrassingly parallel solutions.  This means the
problem being seen in using GPars is not inherent in the JVM, native
threads and binding of threads to processors (though remember I am
talking only about Ubuntu, Mac OS X, and Solaris here -- I suspect
Windows is unlikely to be able to achieve the desired behaviour, but
this is prejudice on my part).  So unless Groovy can be made not to have
this "lack of cache" behaviour then it rules itself out as a parallelism
coordination language, and I will have to switch back to the use of
Python and Jython.

No matter how much we like Groovy and hence GPars, if it isn't going to
do the job needed we must be honest about this.  There is nothing worse
than pretending a framework can do what it cannot.

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                           xmpp: [hidden email]
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,   f: +44 8700 516 084   voip: [hidden email]
London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder



--
E-mail: [hidden email]
Blog: http://www.jroller.com/vaclav
Linkedin page: http://www.linkedin.com/in/vaclavpech
Reply | Threaded
Open this post in threaded view
|

Re: GPars Actors don't appear to scale

Vaclav
Administrator
Sorry, a typo correction: spouse -> spawn

On Thu, Nov 12, 2009 at 10:20 AM, Vaclav Pech <[hidden email]> wrote:
Hello Russel,

I'd like to add some comments to your insightful opinion. I'm very glad you've brought the topic up to our attention. It definitely deserves to be widely discussed, since, in my opinion, the Groovy community has to act on the deficiency now or never. Companies are starting to plan they java.next strategies and concurrency is typicaly pretty high on the list of features to look for. A potential candidate for Java replacement must undoubtedly scale well on multi-processors now in the multi-core era.

You clearly showed that Groovy is currently not ready to be used on heavily computational parallel algorithms. Its method invocation mechanism doesn't scale well beyond one cpu or thread and that is certainly bad news for many.
On the other hand, I tend to disagree that non-scalable Groovy renders GPars useless. Far from that, I would say. People use GPars to spouse parallel downloads, file scans, invoke multiple web-services concurrently, in which cases the algorithms scale well in Groovy, since method invocation is no longer the bottleneck. Check the recent "FastTranslate Plugin" (http://docs.codehaus.org/display/GRIFFON/FastTranslate+Plugin) as an example of GPars being used for the purpose. GPars can also effectively orchestrate Java-written routines so that even highly computational calculations would scale (almost) linearly.

Obviously we have to have the Groovy deficiency in mind when choosing features to support in GPars. STM or Dataflow operators make much less sense than, for example, parallel collections, actors, remoting or asynchronous closures.

Even with the scalability issue Groovy still has pretty good chances to become a widely used scripting / configuration / mashup / DSL language and GPars can provide easy-to-use concurrency constructs targeted at these domains.

Cheers,

Vaclav

 



Hummm...  I am going to have to think about this a bit more but on the
surface it implies that unless something changes, Groovy is and always
will be completely useless for any sort of multiprocessor computations.
This undermines any and all GPars activity.

Currently, using Java (or Scala) directly it is possible to get near
linear scaling of embarrassingly parallel solutions.  This means the
problem being seen in using GPars is not inherent in the JVM, native
threads and binding of threads to processors (though remember I am
talking only about Ubuntu, Mac OS X, and Solaris here -- I suspect
Windows is unlikely to be able to achieve the desired behaviour, but
this is prejudice on my part).  So unless Groovy can be made not to have
this "lack of cache" behaviour then it rules itself out as a parallelism
coordination language, and I will have to switch back to the use of
Python and Jython.

No matter how much we like Groovy and hence GPars, if it isn't going to
do the job needed we must be honest about this.  There is nothing worse
than pretending a framework can do what it cannot.

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                           xmpp: [hidden email]
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,   f: +44 8700 516 084   voip: [hidden email]
London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder






--
E-mail: [hidden email]
Blog: http://www.jroller.com/vaclav
Linkedin page: http://www.linkedin.com/in/vaclavpech
Reply | Threaded
Open this post in threaded view
|

Re: GPars Actors don't appear to scale

Dierk König
In reply to this post by Vaclav
>
> On the other hand, I tend to disagree that non-scalable Groovy  
> renders GPars useless. Far from that, I would say.

+1 on that.

Seems a bit like the "baby and bathwater" issue to me ;-)

One issue that comes to my mind here is using "Functions" as  
replacements of Closures.
A Function as I envision it would have no delegate/owner magic but  
work solely on the
arguments passed into it.

We can still decide whether the visual appearance should be  
distinguishable from
Closures or not (he, some AST magic should do the trick).

cheers
Dierk

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: GPars Actors don't appear to scale

Alex Tkachman
First of all I also disagree with fully useless. Just as Vaclav said
it gives limited scoped

Second, delegate/owner issue is more about serialization. Performance
issue is internal locks (not so many) and volatile flags (a lot) of
groovy runtime. We should deal with it in groovy core

But

On Fri, Nov 13, 2009 at 3:41 PM, Dierk König <[hidden email]> wrote:

>>
>> On the other hand, I tend to disagree that non-scalable Groovy renders
>> GPars useless. Far from that, I would say.
>
> +1 on that.
>
> Seems a bit like the "baby and bathwater" issue to me ;-)
>
> One issue that comes to my mind here is using "Functions" as replacements of
> Closures.
> A Function as I envision it would have no delegate/owner magic but work
> solely on the
> arguments passed into it.
>
> We can still decide whether the visual appearance should be distinguishable
> from
> Closures or not (he, some AST magic should do the trick).
>
> cheers
> Dierk
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: GPars Actors don't appear to scale

Jochen Theodorou
In reply to this post by Russel Winder-2
Russel Winder schrieb:

> Jochen,
>
> Apologies for having taken so long to get back to this -- PhD examining
> and workshops on Concepts and C++ took up the last couple of weeks.
>
> On Mon, 2009-10-26 at 19:46 +0100, Jochen Theodorou wrote:
> [ . . . ]
>> Since I am missing some context, please don't be angry if I say things
>> that are known already. Just putting in more CPUs or station doesn't
>> mean the algorithm will be faster. It depends on how well the algorithm
>> scales and with that of course the underlaying Groovy runtime.
>
> You are right, we know this ;-)
>
> As always, my tests run with embarrassingly parallel computations, i.e.
> there is a fork cost and a join cost and no communications in between.
> This should therefore lead to close to linear scaling with the number of
> independent processors.  The caveat here for multicore processors is the
> cache coherence problems.  Currently though my problems are small enough
> in memory use that the cores should never have cache misses so this
> should factor out the cache and memory access problems.

This depends on a good usage of the cache, also linear is only the
computation part, not the forking and joining. Looking at the complete
process you will never get linear scaling this way.

> Using C, C++, Java, Fortran, Scala, Clojure, Python, Erlang, Chapel, C#,
> D,
>
> Haskell and OCaml have problems, as it seems Groovy has.  All are
> different though.  Haskell has problems because of the lazy
> computational model, OCaml has other problems -- similar to those in
> Python I understand though Python has a way round it (using MPI inspired
> SPMD approaches).

the lazy computation model is causing problems? Could you explain a
little? I am interested to know because I have ideas for Groovy in the
same direction and it would be good if I would know of problems related
to that.

>> For each algorithm you have a calculation and a communication part and
>> with more CPUs the communication part takes more time, while the
>> calculation part takes less time. What you parallelize is of course the
>> calculation part only, the communication part is needed to get the end
>> result. So for each algorithm you have a maximum of speed that says with
>> this many CPUs you are fastest. If you use more, the performance will be
>> lowered again. Of course this could mean that this happens with only 1
>> CPU already, meaning using a second one will gain no speedup.
>
> This is not a problem in this particular case.  Also this argument is a
> language independent one and we have a very language dependent problem
> here.

The language library might impose additional communication parts, that
will then cause additional problems.

[ . . . ]

>>> For different reasons, I am rapidly coming to the same conclusion.  I am
>>> rapidly coming to the conclusion that Groovy destroys all parallelism
>>> even when it uses all the cores :-(
>> Not groovy, the runtime implementation. just imagine, that for each and
>> every method call you make in Groovy, you have to read from a volatile
>> field. This should make clear that then every method call will require
>> synchronization with the memory and that for each CPU. This imposes a
>> big communication overhead that is even in a single threaded case
>> noticeable, especially because it makes hotspot nearly useless. This is
>> a thing I intend to target in Groovy 1.8.
>
> Hummm...  I am going to have to think about this a bit more but on the
> surface it implies that unless something changes, Groovy is and always
> will be completely useless for any sort of multiprocessor computations.
> This undermines any and all GPars activity.

I know. But I think the problem can be solved. Only... it is a balance
act between minimizing implicit synchronization and still getting the
right thing. I developed some ideas for this and I think it will work.
If it really does I will only after I tried it out. Groovy concentrated
too much on simple parallel problems only.

> Currently, using Java (or Scala) directly it is possible to get near
> linear scaling of embarrassingly parallel solutions.  This means the
> problem being seen in using GPars is not inherent in the JVM, native
> threads and binding of threads to processors (though remember I am
> talking only about Ubuntu, Mac OS X, and Solaris here -- I suspect
> Windows is unlikely to be able to achieve the desired behaviour, but
> this is prejudice on my part).  So unless Groovy can be made not to have
> this "lack of cache" behaviour then it rules itself out as a parallelism
> coordination language, and I will have to switch back to the use of
> Python and Jython.

that is why we decided to make a Groovy 1.8 even though originally and
at the last GDC we decided 2.0 would be next.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: GPars Actors don't appear to scale

Jochen Theodorou
In reply to this post by Dierk König
Dierk König schrieb:
> One issue that comes to my mind here is using "Functions" as
> replacements of Closures.
> A Function as I envision it would have no delegate/owner magic but work
> solely on the
> arguments passed into it.
>
> We can still decide whether the visual appearance should be
> distinguishable from
> Closures or not (he, some AST magic should do the trick).

owner/delegate magic is used only if it is to find he meaning of a
vanilla name. If you work only on local variables and parameters, then
you will have no request to owner/delegate.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: GPars Actors don't appear to scale

Russel Winder-2
In reply to this post by Vaclav
On Thu, 2009-11-12 at 10:20 +0100, Vaclav Pech wrote:

> Hello Russel,
>
> I'd like to add some comments to your insightful opinion. I'm very
> glad you've brought the topic up to our attention. It definitely
> deserves to be widely discussed, since, in my opinion, the Groovy
> community has to act on the deficiency now or never. Companies are
> starting to plan they java.next strategies and concurrency is typicaly
> pretty high on the list of features to look for. A potential candidate
> for Java replacement must undoubtedly scale well on multi-processors
> now in the multi-core era.
I like that: "grumpy and bad-tempered == insightful" :-)

I believe there is a real issue here, one that might make Clojure or
JRuby or Jython the preferred choice over Groovy -- which would be bad.
Whilst it never ceases to amaze me how slow and backward some
organizations can be, the more forward looking organizations are indeed
beginning to make their choices over the next year, and this will then
filter to the more conservative ones.

Java is now the conservative and safe language that doesn't really
change.  But neither does it support the abstractions needed for
parallel computing in the near. medium and far future -- and
increasingly it looks as though it never will.  Scala is now looking
more and more like the static language of the JVM, though it has its
problems.  Clojure, Jython, JRuby and Groovy are the dynamic languages
of the JVM, at least for now.

Clojure, Jython, JRuby and Groovy are not though replacements for
Java.  

> You clearly showed that Groovy is currently not ready to be used on
> heavily computational parallel algorithms. Its method invocation
> mechanism doesn't scale well beyond one cpu or thread and that is
> certainly bad news for many.
> On the other hand, I tend to disagree that non-scalable Groovy renders
> GPars useless. Far from that, I would say. People use GPars to spouse
> parallel downloads, file scans, invoke multiple web-services
> concurrently, in which cases the algorithms scale well in Groovy,
> since method invocation is no longer the bottleneck. Check the recent
> "FastTranslate
> Plugin" (http://docs.codehaus.org/display/GRIFFON/FastTranslate
> +Plugin) as an example of GPars being used for the purpose. GPars can
> also effectively orchestrate Java-written routines so that even highly
> computational calculations would scale (almost) linearly.
>
I think what is begin said here is that the dynamic languages will be
coordination languages and not computational languages.  IF this is
agreed then:

1.  We need to make sure that all the "marketing blurb" and indeed all
the documentation for GPars makes it clear that Groovy and GPars only
describes the parallel structure of an application and should never be
used for actual computation.   The expectation is always that the grunt
work is done in Java.  So the consequence is that we need a really
lightweight and obvious way of making it clear that GPars is organizing
Java computations.

2.  We need to make sure that any and all of the Groovy "problems" do
not interfere with the actual computations but only with the
organization of the computations -- and better still not them either.

> Obviously we have to have the Groovy deficiency in mind when choosing
> features to support in GPars. STM or Dataflow operators make much less
> sense than, for example, parallel collections, actors, remoting or
> asynchronous closures.
>
> Even with the scalability issue Groovy still has pretty good chances
> to become a widely used scripting / configuration / mashup / DSL
> language and GPars can provide easy-to-use concurrency constructs
> targeted at these domains.

I don't think anyone is disagreeing per se.  The problem is that so far
the Groovy "problems" have interfered with all performance aspects of
GPars actors and that leaves us with a big problem.

I'll try doing the content in Java with the coordination in Groovy+GPars
and see if that is any better.  I'll also make comparison with Scala
since I think that is the nearest competition currently -- though I
guess "native Java" is also competition and should be compared with.

In the end if we can come up with a model framework that allows people
idioms of how to use Java, Scala, Groovy and GPars to best effect then
we will be doing ourselves and the community a big service.  The
examples above need adding to the "no problem" category as a big plus.
I guess we should start another wiki page to capture all this.


--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: [hidden email]
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,   f: +44 8700 516 084   voip: sip:[hidden email]
London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GPars Actors don't appear to scale

Russel Winder-2
In reply to this post by Dierk König
On Fri, 2009-11-13 at 14:41 +0100, Dierk König wrote:
> >
> > On the other hand, I tend to disagree that non-scalable Groovy  
> > renders GPars useless. Far from that, I would say.
>
> +1 on that.
>
> Seems a bit like the "baby and bathwater" issue to me ;-)

Yes and no.  It is really about knowing the problems and creating idioms
of use that clearly indicate GPars is "good in these areas for these
problems" and clearly states that if you are looking for "such and such
a problem then GPars has to be used very carefully or not at all".

I guess what I am saying is that "parallelism frameworks" tend to imply
they always have an answer for all problems.  By falling into this group
GPars will do itself a disservice.  By being clear about where it has
performance issues, we should avoid misrepresentation -- which is the
fastest way to getting a bad reputation.

> One issue that comes to my mind here is using "Functions" as  
> replacements of Closures.
> A Function as I envision it would have no delegate/owner magic but  
> work solely on the
> arguments passed into it.
>
> We can still decide whether the visual appearance should be  
> distinguishable from
> Closures or not (he, some AST magic should do the trick).

Anything that gets rid of global shared memory has a role!

What is also needed is an "API" that clearly separates the Groovy world
and the world that doesn't have volatile lookup problems as Groovy is
now reported as having (see Jochen's emails).

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: [hidden email]
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,   f: +44 8700 516 084   voip: sip:[hidden email]
London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GPars Actors don't appear to scale

Jochen Theodorou
In reply to this post by Alex Tkachman
Alex Tkachman schrieb:
[...]
> Second, delegate/owner issue is more about serialization. Performance
> issue is internal locks (not so many) and volatile flags (a lot) of
> groovy runtime. We should deal with it in groovy core

a while ago I had the idea to support dummies for owner/delegate, for
Closures that are really anonymous functions. Then it would be possible
to serialize those without having to serialize the real owner/delegate.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: GPars Actors don't appear to scale

Vaclav
Administrator
In reply to this post by Russel Winder-2
Hi Russel,

thank you for your comments.

I believe there is a real issue here, one that might make Clojure or
JRuby or Jython the preferred choice over Groovy -- which would be bad.
Whilst it never ceases to amaze me how slow and backward some
organizations can be, the more forward looking organizations are indeed
beginning to make their choices over the next year, and this will then
filter to the more conservative ones.

Can't agree more. Exactly what feel myself. The next year will be big in this regard. I've noticed several large corporations making up their strategic plans already.
 

I think what is begin said here is that the dynamic languages will be
coordination languages and not computational languages.  IF this is
agreed then:

Well, having heard Jochen's plans to address the concurrency bottleneck in 1.8 I believe Groovy has ambitions beyond pure coordination language. I'm only afraid that 1.8 might come a bit too late to have impact on the game.

1.  We need to make sure that all the "marketing blurb" and indeed all
the documentation for GPars makes it clear that Groovy and GPars only
describes the parallel structure of an application and should never be
used for actual computation.   The expectation is always that the grunt
work is done in Java.  So the consequence is that we need a really
lightweight and obvious way of making it clear that GPars is organizing
Java computations.

2.  We need to make sure that any and all of the Groovy "problems" do
not interfere with the actual computations but only with the
organization of the computations -- and better still not them either.

I still hope the synchronization issue in Groovy will be eventually removed. Otherwise I agree, we'll have to be honest with our users and admit that GPars can only help them if they either perform IO or organize non-Groovy computations. So let's wait a bit more.

I'll try doing the content in Java with the coordination in Groovy+GPars
and see if that is any better.  I'll also make comparison with Scala
since I think that is the nearest competition currently -- though I
guess "native Java" is also competition and should be compared with.

This would be indeed very interesting. Please keep me informed about the progress.
 
In the end if we can come up with a model framework that allows people
idioms of how to use Java, Scala, Groovy and GPars to best effect then
we will be doing ourselves and the community a big service.  The
examples above need adding to the "no problem" category as a big plus.
I guess we should start another wiki page to capture all this.



Cheers,

Vaclav

Reply | Threaded
Open this post in threaded view
|

Re: GPars Actors don't appear to scale

BungleFeet
I thought I'd step into my time-machine and resurrect this thread... :)

Did the problems with synchronization on method invocation in Groovy ever get sorted out? Does JDK7 and "indy" solve the problem?

I ask because while I have been using GPars successfully for a few years now to parallelize IO-bound problems, I now have a CPU-bound problem that I'd like to attack, using GPars if possible.  Is the advice still to avoid GPars for this kind of work?

Cheers,
Ewan

Reply | Threaded
Open this post in threaded view
|

Re: GPars Actors don't appear to scale

Russel Winder-3
On Thu, 2013-02-28 at 23:00 -0800, BungleFeet wrote:
> I thought I'd step into my time-machine and resurrect this thread... :)
>
> Did the problems with synchronization on method invocation in Groovy ever
> get sorted out? Does JDK7 and "indy" solve the problem?

Can you give me a small example of code that exhibited the problem so I
can experiment?

> I ask because while I have been using GPars successfully for a few years now
> to parallelize IO-bound problems, I now have a CPU-bound problem that I'd
> like to attack, using GPars if possible.  Is the advice still to avoid GPars
> for this kind of work?

Whoever gave any such advice? GPars has always been very successful for
parallelizing compute-bound things. At least for data parallel, actor,
dataflow and CSP architecture systems.

--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[hidden email]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GPars Actors don't appear to scale

BungleFeet
Hi Russel, thanks for the quick response.


On 1 March 2013 07:10, Russel Winder <[hidden email]> wrote:
On Thu, 2013-02-28 at 23:00 -0800, BungleFeet wrote:
> I thought I'd step into my time-machine and resurrect this thread... :)
>
> Did the problems with synchronization on method invocation in Groovy ever
> get sorted out? Does JDK7 and "indy" solve the problem?

Can you give me a small example of code that exhibited the problem so I
can experiment?

I don't have any code yet, I wanted to check before starting that I wasn't wasting my time using GPars on my problem.

> I ask because while I have been using GPars successfully for a few years now
> to parallelize IO-bound problems, I now have a CPU-bound problem that I'd
> like to attack, using GPars if possible.  Is the advice still to avoid GPars
> for this kind of work?

Whoever gave any such advice? GPars has always been very successful for
parallelizing compute-bound things. At least for data parallel, actor,
dataflow and CSP architecture systems.

I'm referring to a discussion on this mailing list between Jochen, Vaclav, yourself and others (see http://gpars-user-mailing-list.19372.n3.nabble.com/Re-GPars-Actors-don-t-appear-to-scale-td32544.html#a4024815), where you discuss some facets of Groovy's dynamic method invocation that may hinder parallel processing with GPars. To quote Jochen and yourself:

"> for each and every method call you make in Groovy, you have to read from a volatile 
> field. This should make clear that then every method call will require 
> synchronization with the memory and that for each CPU. This imposes a 
> big communication overhead that is even in a single threaded case 
> noticeable, especially because it makes hotspot nearly useless. This is 
> a thing I intend to target in Groovy 1.8.
Hummm...  I am going to have to think about this a bit more but on the 
surface it implies that unless something changes, Groovy is and always 
will be completely useless for any sort of multiprocessor computations. 
This undermines any and all GPars activity."

Later on, Vaclav responds:

"You clearly showed that Groovy is currently not ready to be used on heavily computational parallel algorithms. Its method invocation mechanism doesn't scale well beyond one cpu or thread and that is certainly bad news for many.
On the other hand, I tend to disagree that non-scalable Groovy renders GPars useless. Far from that, I would say. People use GPars to spouse parallel downloads, file scans, invoke multiple web-services concurrently, in which cases the algorithms scale well in Groovy, since method invocation is no longer the bottleneck."

Now, obviously this discussion is from three years ago, so the picture might be different now. However, I don't remember reading any more about this topic on the mailing list, so I thought I'd ask.

Cheers,
Ewan



--
Russel.
=============================================================================
Dr Russel Winder      t: <a href="tel:%2B44%2020%207585%202200" value="+442075852200">+44 20 7585 2200   voip: [hidden email]
41 Buckmaster Road    m: <a href="tel:%2B44%207770%20465%20077" value="+447770465077">+44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Reply | Threaded
Open this post in threaded view
|

Re: GPars Actors don't appear to scale

Vaclav
Administrator
Hi Ewan,

I'm pretty sure that the internal workings of Groovy method dispatch have evolved towards better concurrency in 1.8 and 2.0. My measures now indicate multithreading in Groovy code actually brings benefits even for CPU-bound tasks (4-core machine):

One thread invocation 9425
Two threads invocation 5584
Four threads invocation 3954
Eight threads invocation 3413

With @CompileStatic, we can still get better results, though:

One thread invocation 5691
Two threads invocation 3442
Four threads invocation 2397
Eight threads invocation 2029

Regards,

Vaclav




On Fri, Mar 1, 2013 at 9:24 AM, Ewan Dawson <[hidden email]> wrote:
Hi Russel, thanks for the quick response.


On 1 March 2013 07:10, Russel Winder <[hidden email]> wrote:
On Thu, 2013-02-28 at 23:00 -0800, BungleFeet wrote:
> I thought I'd step into my time-machine and resurrect this thread... :)
>
> Did the problems with synchronization on method invocation in Groovy ever
> get sorted out? Does JDK7 and "indy" solve the problem?

Can you give me a small example of code that exhibited the problem so I
can experiment?

I don't have any code yet, I wanted to check before starting that I wasn't wasting my time using GPars on my problem.

> I ask because while I have been using GPars successfully for a few years now
> to parallelize IO-bound problems, I now have a CPU-bound problem that I'd
> like to attack, using GPars if possible.  Is the advice still to avoid GPars
> for this kind of work?

Whoever gave any such advice? GPars has always been very successful for
parallelizing compute-bound things. At least for data parallel, actor,
dataflow and CSP architecture systems.

I'm referring to a discussion on this mailing list between Jochen, Vaclav, yourself and others (see http://gpars-user-mailing-list.19372.n3.nabble.com/Re-GPars-Actors-don-t-appear-to-scale-td32544.html#a4024815), where you discuss some facets of Groovy's dynamic method invocation that may hinder parallel processing with GPars. To quote Jochen and yourself:

"> for each and every method call you make in Groovy, you have to read from a volatile 
> field. This should make clear that then every method call will require 
> synchronization with the memory and that for each CPU. This imposes a 
> big communication overhead that is even in a single threaded case 
> noticeable, especially because it makes hotspot nearly useless. This is 
> a thing I intend to target in Groovy 1.8.
Hummm...  I am going to have to think about this a bit more but on the 
surface it implies that unless something changes, Groovy is and always 
will be completely useless for any sort of multiprocessor computations. 
This undermines any and all GPars activity."

Later on, Vaclav responds:

"You clearly showed that Groovy is currently not ready to be used on heavily computational parallel algorithms. Its method invocation mechanism doesn't scale well beyond one cpu or thread and that is certainly bad news for many.
On the other hand, I tend to disagree that non-scalable Groovy renders GPars useless. Far from that, I would say. People use GPars to spouse parallel downloads, file scans, invoke multiple web-services concurrently, in which cases the algorithms scale well in Groovy, since method invocation is no longer the bottleneck."

Now, obviously this discussion is from three years ago, so the picture might be different now. However, I don't remember reading any more about this topic on the mailing list, so I thought I'd ask.

Cheers,
Ewan



--
Russel.
=============================================================================
Dr Russel Winder      t: <a href="tel:%2B44%2020%207585%202200" value="+442075852200" target="_blank">+44 20 7585 2200   voip: [hidden email]
41 Buckmaster Road    m: <a href="tel:%2B44%207770%20465%20077" value="+447770465077" target="_blank">+44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder




--
E-mail: [hidden email]
Blog: http://www.jroller.com/vaclav
Linkedin page: http://www.linkedin.com/in/vaclavpech
Reply | Threaded
Open this post in threaded view
|

Re: GPars Actors don't appear to scale

BungleFeet
Great, thanks Václav.  I'd hoped that was the case, good to have it confirmed.

Regards,
Ewan


On 1 March 2013 13:51, Václav Pech <[hidden email]> wrote:
Hi Ewan,

I'm pretty sure that the internal workings of Groovy method dispatch have evolved towards better concurrency in 1.8 and 2.0. My measures now indicate multithreading in Groovy code actually brings benefits even for CPU-bound tasks (4-core machine):

One thread invocation 9425
Two threads invocation 5584
Four threads invocation 3954
Eight threads invocation 3413

With @CompileStatic, we can still get better results, though:

One thread invocation 5691
Two threads invocation 3442
Four threads invocation 2397
Eight threads invocation 2029

Regards,

Vaclav




On Fri, Mar 1, 2013 at 9:24 AM, Ewan Dawson <[hidden email]> wrote:
Hi Russel, thanks for the quick response.


On 1 March 2013 07:10, Russel Winder <[hidden email]> wrote:
On Thu, 2013-02-28 at 23:00 -0800, BungleFeet wrote:
> I thought I'd step into my time-machine and resurrect this thread... :)
>
> Did the problems with synchronization on method invocation in Groovy ever
> get sorted out? Does JDK7 and "indy" solve the problem?

Can you give me a small example of code that exhibited the problem so I
can experiment?

I don't have any code yet, I wanted to check before starting that I wasn't wasting my time using GPars on my problem.

> I ask because while I have been using GPars successfully for a few years now
> to parallelize IO-bound problems, I now have a CPU-bound problem that I'd
> like to attack, using GPars if possible.  Is the advice still to avoid GPars
> for this kind of work?

Whoever gave any such advice? GPars has always been very successful for
parallelizing compute-bound things. At least for data parallel, actor,
dataflow and CSP architecture systems.

I'm referring to a discussion on this mailing list between Jochen, Vaclav, yourself and others (see http://gpars-user-mailing-list.19372.n3.nabble.com/Re-GPars-Actors-don-t-appear-to-scale-td32544.html#a4024815), where you discuss some facets of Groovy's dynamic method invocation that may hinder parallel processing with GPars. To quote Jochen and yourself:

"> for each and every method call you make in Groovy, you have to read from a volatile 
> field. This should make clear that then every method call will require 
> synchronization with the memory and that for each CPU. This imposes a 
> big communication overhead that is even in a single threaded case 
> noticeable, especially because it makes hotspot nearly useless. This is 
> a thing I intend to target in Groovy 1.8.
Hummm...  I am going to have to think about this a bit more but on the 
surface it implies that unless something changes, Groovy is and always 
will be completely useless for any sort of multiprocessor computations. 
This undermines any and all GPars activity."

Later on, Vaclav responds:

"You clearly showed that Groovy is currently not ready to be used on heavily computational parallel algorithms. Its method invocation mechanism doesn't scale well beyond one cpu or thread and that is certainly bad news for many.
On the other hand, I tend to disagree that non-scalable Groovy renders GPars useless. Far from that, I would say. People use GPars to spouse parallel downloads, file scans, invoke multiple web-services concurrently, in which cases the algorithms scale well in Groovy, since method invocation is no longer the bottleneck."

Now, obviously this discussion is from three years ago, so the picture might be different now. However, I don't remember reading any more about this topic on the mailing list, so I thought I'd ask.

Cheers,
Ewan



--
Russel.
=============================================================================
Dr Russel Winder      t: <a href="tel:%2B44%2020%207585%202200" value="+442075852200" target="_blank">+44 20 7585 2200   voip: [hidden email]
41 Buckmaster Road    m: <a href="tel:%2B44%207770%20465%20077" value="+447770465077" target="_blank">+44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder




--
E-mail: [hidden email]
Blog: http://www.jroller.com/vaclav
Linkedin page: http://www.linkedin.com/in/vaclavpech

Reply | Threaded
Open this post in threaded view
|

Re: GPars Actors don't appear to scale

Vaclav
Administrator
I'm pretty sure the Groovy core guys, and namely Jochen, should know, where the limits currently are.

Vaclav


On Fri, Mar 1, 2013 at 2:59 PM, Ewan Dawson <[hidden email]> wrote:
Great, thanks Václav.  I'd hoped that was the case, good to have it confirmed.

Regards,
Ewan


On 1 March 2013 13:51, Václav Pech <[hidden email]> wrote:
Hi Ewan,

I'm pretty sure that the internal workings of Groovy method dispatch have evolved towards better concurrency in 1.8 and 2.0. My measures now indicate multithreading in Groovy code actually brings benefits even for CPU-bound tasks (4-core machine):

One thread invocation 9425
Two threads invocation 5584
Four threads invocation 3954
Eight threads invocation 3413

With @CompileStatic, we can still get better results, though:

One thread invocation 5691
Two threads invocation 3442
Four threads invocation 2397
Eight threads invocation 2029

Regards,

Vaclav




On Fri, Mar 1, 2013 at 9:24 AM, Ewan Dawson <[hidden email]> wrote:
Hi Russel, thanks for the quick response.


On 1 March 2013 07:10, Russel Winder <[hidden email]> wrote:
On Thu, 2013-02-28 at 23:00 -0800, BungleFeet wrote:
> I thought I'd step into my time-machine and resurrect this thread... :)
>
> Did the problems with synchronization on method invocation in Groovy ever
> get sorted out? Does JDK7 and "indy" solve the problem?

Can you give me a small example of code that exhibited the problem so I
can experiment?

I don't have any code yet, I wanted to check before starting that I wasn't wasting my time using GPars on my problem.

> I ask because while I have been using GPars successfully for a few years now
> to parallelize IO-bound problems, I now have a CPU-bound problem that I'd
> like to attack, using GPars if possible.  Is the advice still to avoid GPars
> for this kind of work?

Whoever gave any such advice? GPars has always been very successful for
parallelizing compute-bound things. At least for data parallel, actor,
dataflow and CSP architecture systems.

I'm referring to a discussion on this mailing list between Jochen, Vaclav, yourself and others (see http://gpars-user-mailing-list.19372.n3.nabble.com/Re-GPars-Actors-don-t-appear-to-scale-td32544.html#a4024815), where you discuss some facets of Groovy's dynamic method invocation that may hinder parallel processing with GPars. To quote Jochen and yourself:

"> for each and every method call you make in Groovy, you have to read from a volatile 
> field. This should make clear that then every method call will require 
> synchronization with the memory and that for each CPU. This imposes a 
> big communication overhead that is even in a single threaded case 
> noticeable, especially because it makes hotspot nearly useless. This is 
> a thing I intend to target in Groovy 1.8.
Hummm...  I am going to have to think about this a bit more but on the 
surface it implies that unless something changes, Groovy is and always 
will be completely useless for any sort of multiprocessor computations. 
This undermines any and all GPars activity."

Later on, Vaclav responds:

"You clearly showed that Groovy is currently not ready to be used on heavily computational parallel algorithms. Its method invocation mechanism doesn't scale well beyond one cpu or thread and that is certainly bad news for many.
On the other hand, I tend to disagree that non-scalable Groovy renders GPars useless. Far from that, I would say. People use GPars to spouse parallel downloads, file scans, invoke multiple web-services concurrently, in which cases the algorithms scale well in Groovy, since method invocation is no longer the bottleneck."

Now, obviously this discussion is from three years ago, so the picture might be different now. However, I don't remember reading any more about this topic on the mailing list, so I thought I'd ask.

Cheers,
Ewan



--
Russel.
=============================================================================
Dr Russel Winder      t: <a href="tel:%2B44%2020%207585%202200" value="+442075852200" target="_blank">+44 20 7585 2200   voip: [hidden email]
41 Buckmaster Road    m: <a href="tel:%2B44%207770%20465%20077" value="+447770465077" target="_blank">+44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder




--
E-mail: [hidden email]
Blog: http://www.jroller.com/vaclav
Linkedin page: http://www.linkedin.com/in/vaclavpech




--
E-mail: [hidden email]
Blog: http://www.jroller.com/vaclav
Linkedin page: http://www.linkedin.com/in/vaclavpech
Reply | Threaded
Open this post in threaded view
|

Re: GPars Actors don't appear to scale

Jochen Theodorou
Am 01.03.2013 15:14, schrieb Václav Pech:
> I'm pretty sure the Groovy core guys, and namely Jochen, should know,
> where the limits currently are.

that's actually a difficult question

If primitive optimizations are used, then Groovy should perform very
well in the multi threaded case. The normal callsite caching got also
optimized quite a bit in that regard (results from the work on primitive
optimizations), so even that one should be faster compared to before
1.8. As for indy... it should have similar behaviour as primitive
optimizations, while covering more cases than primitive
optimizations.... so much as general information

The above should be especially true if categories are active.

There are still some cases in which we use a memory synchronized path
all the time. Indy will not have them anymore in the future, I am
actually currently not sure if that is already the case. These paths are
quite special, but can be hit.

bye blackdrag

--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email