[concurrency-interest] Implicit parallelism

Gustav Åkesson gustav.r.akesson at gmail.com
Mon Aug 12 07:59:51 EDT 2013


That is absolutely true, but if it a code snippet is deemed to be able to
run in parallel then profiling during runtime could determine how it should
behave depending on n and cost of operation. Some sort of dynamic
optimization which could even make better decisions than you as a
programmer.


Best Regards,
Gustav Åkesson


On Mon, Aug 12, 2013 at 1:01 PM, Oleksandr Otenko <
oleksandr.otenko at oracle.com> wrote:

>  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> 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
>>> 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
>>
>
>
>
> _______________________________________________
> Concurrency-interest mailing listConcurrency-interest at cs.oswego.eduhttp://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130812/6ddd14e5/attachment-0001.html>


More information about the Concurrency-interest mailing list