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

[Rik Cabanier]

On Fri, Apr 12, 2013 at 10:34 PM, Filip Pizlo <fpizlo at apple.com> wrote:

>
> 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.
>

I completely agree. Not only are they hard; apparently it's unspecified
what API's are available to them. [1]
I was just replying to his point that all uses of workers make things
slower.


1:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Apr/0054.html

>
>> 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/981f513f/attachment.html>