[concurrency-interest] Implicit parallelism

Gustav Åkesson gustav.r.akesson at gmail.com
Sun Aug 11 04:44:20 EDT 2013


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> 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 <Concurrency-interest at cs.oswego.edu>
>> http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>>
>>
> ______________________________**_________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.**oswego.edu <Concurrency-interest at cs.oswego.edu>
> http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130811/8b2bb7eb/attachment.html>


More information about the Concurrency-interest mailing list