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

[Filip Pizlo]

On Apr 12, 2013, at 9:46 PM, Rik Cabanier <cabanier at gmail.com> wrote:

> 
> 
> On Fri, Apr 12, 2013 at 9:39 PM, Zoltan Herczeg <zherczeg at webkit.org> wrote:
> > A message passing model a la Web Workers has some advantages compared to
> > threads with shared mutable state and locks:
> > - No possibility of deadlock
> > - No possibility of corrupting data structures due to races
> > - No performance penalty from correctly supporting fine-grained concurrent
> > access to arbitrary mutable objects
> >
> > The first is particularly important as you really do not want the web
> > page's UI thread to lock up, even if the page itself is not making
> > progress.
> >
> > I believe message passing as a concurrent programming model is much less
> > prone to severe errors than shared mutable state + locking. I think you
> > have to be super smart to even have a chance of using shared mutable state
> > correctly. That being said, I am not sure Web Workers as they exist today
> > are the best possible form of message passing.
> 
> We tried to use WebWorkers for parallel computation, but in their current
> form, they are useless. We also searched for other Worker demos on the
> net, and all of them were slower with workers. I suspect ParallelArray
> will not help either.
> 
> Have you tried pdf.js? That uses workers for various operations.
> There's an option to turn off workers and it makes pages display slower.

Pdf.js is really cool.  But I agree with Zoltan's general assessment of workers: they are not easy to use.  Just because pdf.js uses them doesn't mean we can't do better.

>  
> 
> The problem is not producing messages, but receiving and processing them
> on the other side. Why? Because that involves JS. Noone will use JS to
> search prime numbers, they want to control the UI (animations, image
> generation, physics, etc.).
> 
> Imho Workers need an API, which can be used to set (and perhaps get)
> properties without calling JS. Especially timed set (the change should be
> happen in a given time in the future). Very important for smooth
> animations. These properties must be constants: numbers, strings, RGBA
> arrays, etc. When we set dozens of properties, the extra cost on the UI
> side should be minimal.
> 
> What do you mean here? Maybe some pseudocode will make it clear for me. 
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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