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