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

> On Fri, Apr 12, 2013 at 1:50 PM, Filip Pizlo <fpi...@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

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to