On Apr 10, 2013, at 1:03 PM, Dirk Pranke <dpra...@chromium.org> wrote:
> Right, you need some way to ensure that the functions applied to the array
> are "pure", the array doesn't mutate, etc. I thought perhaps your
> ParallelArray() type would be ensuring this (e.g., by enforcing type checking
> and freezing the array), but maybe I misunderstood you?
Ah - this is the key thing. ParallelArray requires the runtime and compiler to:
- Ensure that the closure passed to it is pure enough to parallelize (formally,
no loop-carried side-effects). If you already have the compiler do this
analysis then we might as well do it for any call to forEach().
- You're right that in one of the versions of the ParallelArray proposal, they
make ParallelArray immutable. But this doesn't help much. We already infer
that things are immutable in JS engines. If immutability helped, then we could
just infer it automatically. It would just be another kind of array inference.
All of the major JS inference already do array inference, and
purity/immutability is a particularly simple property to infer. But I don't
actually think you really need to prove that the array doesn't *ever* change -
proving that the closure doesn't change the array in bad ways is all that is
necessary, and that is even easier to detect since it's a property of the
closure (or more broadly, the loop body) and not the array itself.
-F
> Even then, I'm not sure how easy ensuring the functions were pure would be.
>
> Plus there's the problem of figuring how best to parallelize the operations,
> which is also often non-trivial.
>
> -- Dirk
>
> On Wed, Apr 10, 2013 at 12:58 PM, Oliver Hunt <oli...@apple.com> wrote:
> I'm not sure what you mean here: a parallel array is simply an array of
> numbers; there is nothing "magic" about it.
>
> If we _really_ wanted to be blunt about it, we could simply say (in Array.map)
>
> if (length >= giant && function.isEasyPeasy() && everything in the array is a
> number)
> return doHardcoreMap();
>
> // carry on doing regular map
> ...
>
> Understand that the parallel APIs have to do all of this as well, the only
> thing they lose is the "is everything a number" check
>
> --Oliver
>
>
> On Apr 10, 2013, at 12:50 PM, Dirk Pranke <dpra...@chromium.org> wrote:
>
>> Right, I get how ParallelArrays would work. I was asking Filip how you might
>> infer that an array could be a ParallelArray.
>>
>> -- Dirk
>>
>> On Wed, Apr 10, 2013 at 12:45 PM, Oliver Hunt <oli...@apple.com> wrote:
>> The parallel arrays apis aren't a magic "make my code parallel" wand.
>>
>> They don't make general code parallel, they simply provide a bunch of
>> functions like map, etc where if you restrict your list of language features
>> to a specific subset, they'll vectorise it.
>>
>> For instance
>>
>> ParallelArray([1,2,3]).map(function(a,v) { return v * 2; })
>>
>> would be vectorised
>>
>> ParallelArray([1,2,3]).map(function(a,v) { return v.x * 2; })
>>
>> wouldn't be.
>>
>> This isn't "solve autovectorisation", this is "we've been given a specific
>> operation to perform on each element of an array, parallelise it if
>> possible", and what's possible is arbitrarily limited, and require a
>> distinct type that isn't an array.
>>
>> --Oliver
>
>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
