[webkit-dev] Parallel JavaScript: Why a separate ParallelArray types

[Filip Pizlo]

On Apr 12, 2013, at 7:03 PM, Dirk Pranke <dpranke at chromium.org> wrote:

> On Fri, Apr 12, 2013 at 1:50 PM, Filip Pizlo <fpizlo at apple.com> wrote:
> I'm curious: would you want to use ParallelArray, if you had the flexibility of building a different abstraction?
> 
> I find ParallelArray to be an awkward abstraction to begin with.  I like work queues and such.  The whole idea that the only parallelism you get is from arrays feels narrow-minded.
> 
> I think the needs of the HPC / GPU-accelerating crowd are quite different from the people looking for general concurrency solutions to the multi-core problem.

Mandatory snarky remark: I don't think that HPC is what people will be doing in JavaScript, in a browser!

But in all seriousness, I'm all for considering the HPC and GPU-acceleration workloads along with all of the other use cases of concurrency.  I believe that the best programming models are the ones that cover even more usage scenarios than their designer intended. :-)

> 
> For what it's worth, NRWT is (IMO) an interesting example of a highly-parallel program.

I know, it's pretty cool!

> In a sense, the problem is perfectly suited to map/reduce, and the performance of NRWT scales linearly well up to (at least) 48-core machines; the necessarily-serial part of the program is quite small. However, in order to turn it into a usable program (where you can actually tell what's going on and manage it well), you do need to actually monitor tasks and queues and provide problem-specific feedback to the user. I'm not sure what the message of that is, exactly …

To me it's just that: concurrency is hard and there is no silver bullet.  In the absence of silver bullets the best you can do, as a programming language/programming model designer is to give people a general tool, and do the best you can to guard them on the security and isolation front.  We can do this in JavaScript: it's a memory-safe language already.

-Filip


> 
> -- Dirk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130412/46f398ff/attachment.html>