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

[Igor Trindade Oliveira]

I think the start point here would be the use case, we are talking about a
web browser, normally the user wants to parallelize some data and visualize
it. This visualization can be done through html/svg/canvas/webgl. Thinking
about WebGL and canvas(accelerated canvas), threads can be nocive because
context switch is expensive(specially in mobile devices). Now looking on
OpenCL, it provides an extension that shares data between opencl and opengl
driver, so we do not need to readback from gpu.
Other interesting point discussed already: we should be able to create a
low level API where the user can create a high level abstraction, about
this statement  WebCL has a big advantage because someone[1] already proved
it can be done.

[1]
http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/pubfiles/lashc2012.pdf


On Fri, Apr 12, 2013 at 11:25 PM, Rik Cabanier <cabanier at gmail.com> wrote:

>
>
> 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
>>
>>
>>
>
> _______________________________________________
> 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/20130413/b83b069b/attachment.html>