[webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit

[Filip Pizlo]

On Apr 10, 2013, at 1:03 PM, Dirk Pranke <dpranke at 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 <oliver at 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 <dpranke at 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 <oliver at 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
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130410/0658a148/attachment.html>