[concurrency-interest] Implicit parallelism

Oleksandr Otenko oleksandr.otenko at oracle.com
Mon Aug 12 07:01:46 EDT 2013


But the real problem is not determining a large enough array to sum in 
parallel, rather:

a. determining the operation you do over the array is monoidal
b. determining the actual cost of operation; summing has silly cost, you 
want to parallellize even arrays of tens of elements, if processing each 
element is costly

Alex

On 11/08/2013 09:44, Gustav Åkesson wrote:
> Hi,
>
> My point is that the programmer should (in some circumstances) not 
> care if it runs in parallel or not - the execution determines this for 
> you as long as the program semantics are not broken. That's why I 
> don't want to see .parallel or similar - that is somewhat explicit 
> parallelism. As you say, the example I gave was read-only so then it 
> should (theoretically) be possible to determine that this is safe to 
> run in parallel. The list can't change, nor the elements.
>
> But let's take another example. Let's say we have a Scala (immutable) 
> list containing Int type. If we then add all integers from 0 to x...
>
> for (i <- 0 to x) {
>  immutableIntegerList = i :: immutableIntegerList
> }
>
> Or in Java, a locally declared array which we fill with values:
>
> int[] arr = new int[x]
>
> for (int i=0; i<x; ++i)
>  arr[i] = i
> }
>
> In my mind it should be possible to split the loop constructs into y 
> parts and then concatenate the result in order. Similar to OpenMP but 
> without the explicit parallelism annotation. I know this question is 
> of rather academic type, but I'm wondering whether there has been any 
> ideas or work to bring this type of functionality to the JVM (and the 
> compilers).
>
>
> Best Regards,
> Gustav Åkesson
>
>
> On Sat, Aug 10, 2013 at 11:18 PM, Aaron Grunthal 
> <aaron.grunthal at infinite-source.de 
> <mailto:aaron.grunthal at infinite-source.de>> wrote:
>
>     Thread-safety in the context of data structure usually (but not
>     always) refers to consistent behavior when it is concurrently
>     *modified*.
>
>     In your example you mention summing over a list. That's a
>     read-only action and doesn't require immutable lists or special
>     concurrency support. Most data structures are well-behaved under
>     concurrent read-only access, barring exceptions such as
>     access-ordered LinkedHashMaps.
>
>     Java 8's parallel streams also are smart enough to not parallelize
>     on small data sets where the overhead would kill any performance
>     advantage. At least for data structures that allow size-estimates
>     or actual sizes to be obtained.
>
>     I think there shouldn't be anything keeping you from adding a
>     .parallel if you anticipate the possibility of your data
>     transformations handling non-trivial amounts of data.
>
>     - Aaron
>
>
>
>     On 10.08.2013 20:45, Gustav Åkesson wrote:
>
>         Hi guys,
>
>         My discussion here concerns implicit parallelism. Let's say we
>         have the
>         following setup:
>
>         @Immutable
>         public class Integer
>         {
>            ...
>         }
>
>         @Immutable
>         public class ImmutableArrayList
>         {
>             ...
>         }
>
>         I'm looking for a way so that the parallelism would be introduced
>         without hard-coding anything related to parallelism (i.e. not
>         stating
>         anything like .parallel or .par on the collection). Only thing
>         needed
>         would be something annotation-ish which tells the execution
>         environment
>         that this datastructure with elements is inherently
>         thread-safe. Then
>         the execution could determine if it would be beneficial to do
>         so. For
>         instance, for a structure with e.g. five elements, then it
>         would not,
>         but for millions of elements, it would most likely be. Perhaps
>         it could
>         even find some kind of sweet-spot of number of elements in
>         which the
>         parallel overhead exceeds the benefits.
>
>         Let's say we wish to sum all the integers in an ImmutableArrayList
>         (setup below), would it be possible for the compiler (javac,
>         scalac or
>         what have you) and JVM to conspire and decide "hey, let's run
>         this in
>         parallel since it doesn't violate application semantics and it
>         can/will
>         be faster"? Is there any research in this area in regards to
>         the JVM?
>
>
>         Best Regards,
>
>         Gustav Åkesson
>
>
>         _______________________________________________
>         Concurrency-interest mailing list
>         Concurrency-interest at cs.oswego.edu
>         <mailto:Concurrency-interest at cs.oswego.edu>
>         http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>     _______________________________________________
>     Concurrency-interest mailing list
>     Concurrency-interest at cs.oswego.edu
>     <mailto:Concurrency-interest at cs.oswego.edu>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130812/8a5e295f/attachment.html>


More information about the Concurrency-interest mailing list