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
On Apr 10, 2013, at 12:37 PM, Dirk Pranke <[email protected]> wrote:
>
>
>
> On Wed, Apr 10, 2013 at 7:37 AM, Filip Pizlo <[email protected]> wrote:
>
>
> On Apr 10, 2013, at 2:29 AM, "Pozdnyakov, Mikhail"
> <[email protected]> wrote:
>
> >
> >
> >> Why not infer ParallelArrays automatically?
> > Sorry, did not get it. Could you please elaborate?
>
> Normal JS arrays. You use them with pure computation. Profiler notices this.
> And then the same things that you have in the ParallelArrays proposal now
> work except you don't need a new type.
>
>
> Compiler writers have been chasing this problem for 50 years, with (AFAIK)
> very limited success for languages that don't give you compile-time
> annotations to help you along. I'm not aware of any work on JIT compilers
> doing this. Why do you think we could do better? (Honest question, I'm not
> trying to be snarky, nor am I an expert).
>
> _______________________________________________
> webkit-dev mailing list
> [email protected]
> https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-dev
