ject: Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray
> types
>
> These languages are popular, but I believe most complex projects using them
> with threading a long tail of nasty
> but hard-to-diagnose threadsafety bugs.
Indeed, my assumption was always
On Apr 12, 2013, at 10:26 PM, Filip Pizlo wrote:
>
> You have all of the same problems as with threads and locks. The two are
> logically equivalent. You can imagine a lock as being a message queue that
> always has a token in it when the lock is unlocked, and the token is read out
> to "l
ject: Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray
> types
>
> Same difference. I think this is overly harsh. Nobody will hold a gun to your
> head and force you to use threads. The bumbling fools will probably ignore it.
Experience from desktop development tells
Things are not that bad. (See Shadow DOM for instance where people begged
for it to become a standard)
You should definitely write something up and have a working prototype that
demonstrates how your solution improves performance, cleaner
implementations, etc. You will also have to prove that this
On Apr 13, 2013, at 12:35 PM, Dirk Pranke wrote:
>
> On Fri, Apr 12, 2013 at 10:44 PM, Filip Pizlo wrote:
>
> On Apr 12, 2013, at 10:43 PM, Ryosuke Niwa wrote:
>> Perhaps we can come up with some JS API for shared memory & lock and propose
>> it in TC39 or WebApps WG?
>
> I think that woul
On Fri, Apr 12, 2013 at 10:44 PM, Filip Pizlo wrote:
>
> On Apr 12, 2013, at 10:43 PM, Ryosuke Niwa wrote:
>
> Perhaps we can come up with some JS API for shared memory & lock and
> propose it in TC39 or WebApps WG?
>
>
> I think that would be wonderful. Anyone else interested?
>
>
Feel free to
On Apr 13, 2013, at 10:01 AM, Ian Hickson wrote:
> On Sat, 13 Apr 2013, Filip Pizlo wrote:
>>>
>>> It doesn't imply you can't have locks, it implies you can't have
>>> unprotected shared state.
>>
>> Same difference. I think this is overly harsh. Nobody will hold a gun to
>> your head and fo
On Sat, 13 Apr 2013, Filip Pizlo wrote:
> >
> > It doesn't imply you can't have locks, it implies you can't have
> > unprotected shared state.
>
> Same difference. I think this is overly harsh. Nobody will hold a gun to
> your head and force you to use threads. The bumbling fools will probably
On Apr 13, 2013, at 8:37 AM, Ian Hickson wrote:
> On Sat, 13 Apr 2013, Filip Pizlo wrote:
>>>
>>> Actually, you can't. We very specifically designed workers (and even
>>> more importantly the API on the main thread) so that you cannot block
>>> on waiting for a message.
>>
>> You can also de
On Sat, 13 Apr 2013, Filip Pizlo wrote:
> >
> > Actually, you can't. We very specifically designed workers (and even
> > more importantly the API on the main thread) so that you cannot block
> > on waiting for a message.
>
> You can also design lock APIs this way:
Sure. Lots of APIs do it this
On Sat, Apr 13, 2013 at 8:26 AM, Filip Pizlo wrote:
>
> Also, you could do a libdispatch style, where there is no "lock" per se
> but instead you just have queues that you put tasks on. I like that, too.
> It's also formally equivalent to both locks and message queues, but much
> more similar t
On Sat, Apr 13, 2013 at 12:25 AM, Filip Pizlo wrote:
> You can also design lock APIs this way:
>
> lock.acquireAsynchronously(function() { … do things … });
>
> It's less attractive to me, but I think that this is similar to other
> programming models already out there.
>
Maybe a stupid question
On Fri, Apr 12, 2013 at 11:07 PM, Ryosuke Niwa wrote:
> Do you think it's possible to come up with an API/semantics that would
> allow us to seamlessly switch between single-threaded, SIMD/GPU
> accelerated, and GPU accelerations? Or would be too cumbersome / too hard
> to implement?
>
> It woul
On Apr 12, 2013, at 11:56 PM, Ian Hickson wrote:
> On Fri, 12 Apr 2013, Filip Pizlo wrote:
>>
>> There is a possibility of deadlock. You can have one task waiting for a
>> message from another, and that other waiting for a message from the
>> first.
>
> Actually, you can't. We very specific
>> Perhaps we can come up with some JS API for shared memory & lock and
>> propose it in TC39 or WebApps WG?
>
> I think that would be wonderful. Anyone else interested?
We proposed a shared memory concept a long time ago:
https://bugs.webkit.org/show_bug.cgi?id=53485
Although it helps to reduce
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
On Fri, 12 Apr 2013, Filip Pizlo wrote:
>
> There is a possibility of deadlock. You can have one task waiting for a
> message from another, and that other waiting for a message from the
> first.
Actually, you can't. We very specifically designed workers (and even more
importantly the API on th
On Fri, Apr 12, 2013 at 10:34 PM, Filip Pizlo wrote:
>
> On Apr 12, 2013, at 9:46 PM, Rik Cabanier wrote:
>
>
>
> On Fri, Apr 12, 2013 at 9:39 PM, Zoltan Herczeg
> wrote:
>
>> > A message passing model a la Web Workers has some advantages compared to
>> > threads with shared mutable state and l
On Apr 12, 2013, at 11:07 PM, Ryosuke Niwa wrote:
> On Fri, Apr 12, 2013 at 10:44 PM, Filip Pizlo wrote:
>
> On Apr 12, 2013, at 10:43 PM, Ryosuke Niwa wrote:
>
>> On Fri, Apr 12, 2013 at 2:13 PM, Filip Pizlo wrote:
>>
>> On Apr 12, 2013, at 1:59 PM, Ryosuke Niwa wrote:
>>
>>> On Fri, Ap
On Fri, Apr 12, 2013 at 10:44 PM, Filip Pizlo wrote:
>
> On Apr 12, 2013, at 10:43 PM, Ryosuke Niwa wrote:
>
> On Fri, Apr 12, 2013 at 2:13 PM, Filip Pizlo wrote:
>
>>
>> On Apr 12, 2013, at 1:59 PM, Ryosuke Niwa wrote:
>>
>> On Fri, Apr 12, 2013 at 1:50 PM, Filip Pizlo wrote:
>>
>>>
>>> On A
On Apr 12, 2013, at 7:03 PM, Dirk Pranke wrote:
> On Fri, Apr 12, 2013 at 1:50 PM, Filip Pizlo 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 l
On Apr 12, 2013, at 10:43 PM, Ryosuke Niwa wrote:
> On Fri, Apr 12, 2013 at 2:13 PM, Filip Pizlo wrote:
>
> On Apr 12, 2013, at 1:59 PM, Ryosuke Niwa wrote:
>
>> On Fri, Apr 12, 2013 at 1:50 PM, Filip Pizlo wrote:
>>
>> On Apr 12, 2013, at 1:39 PM, Jarred Nicholls
>> wrote:
>>
>>> On Fr
On Fri, Apr 12, 2013 at 2:13 PM, Filip Pizlo wrote:
>
> On Apr 12, 2013, at 1:59 PM, Ryosuke Niwa wrote:
>
> On Fri, Apr 12, 2013 at 1:50 PM, Filip Pizlo wrote:
>
>>
>> On Apr 12, 2013, at 1:39 PM, Jarred Nicholls
>> wrote:
>>
>> On Fri, Apr 12, 2013 at 2:54 PM, Filip Pizlo wrote:
>>
>>
>> Fo
On Apr 12, 2013, at 9:46 PM, Rik Cabanier wrote:
>
>
> On Fri, Apr 12, 2013 at 9:39 PM, Zoltan Herczeg 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
On Apr 12, 2013, at 6:35 PM, Maciej Stachowiak wrote:
>
> On Apr 12, 2013, at 2:13 PM, Filip Pizlo wrote:
>
>>
>> On Apr 12, 2013, at 1:59 PM, Ryosuke Niwa wrote:
>>
>>> On Fri, Apr 12, 2013 at 1:50 PM, Filip Pizlo wrote:
>>>
>>> On Apr 12, 2013, at 1:39 PM, Jarred Nicholls
>>> wrote:
On Fri, Apr 12, 2013 at 9:39 PM, Zoltan Herczeg 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 performanc
> 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
> acces
On Fri, Apr 12, 2013 at 1:50 PM, Filip Pizlo 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 o
On Apr 12, 2013, at 2:13 PM, Filip Pizlo wrote:
>
> On Apr 12, 2013, at 1:59 PM, Ryosuke Niwa wrote:
>
>> On Fri, Apr 12, 2013 at 1:50 PM, Filip Pizlo wrote:
>>
>> On Apr 12, 2013, at 1:39 PM, Jarred Nicholls
>> wrote:
>>
>>> On Fri, Apr 12, 2013 at 2:54 PM, Filip Pizlo wrote:
>>>
>>>
On Apr 12, 2013, at 1:59 PM, Ryosuke Niwa wrote:
> On Fri, Apr 12, 2013 at 1:50 PM, Filip Pizlo wrote:
>
> On Apr 12, 2013, at 1:39 PM, Jarred Nicholls
> wrote:
>
>> On Fri, Apr 12, 2013 at 2:54 PM, Filip Pizlo wrote:
>>
>> For as little worth as it is, I agree with you Filip that providi
On Fri, Apr 12, 2013 at 1:50 PM, Filip Pizlo wrote:
>
> On Apr 12, 2013, at 1:39 PM, Jarred Nicholls
> wrote:
>
> On Fri, Apr 12, 2013 at 2:54 PM, Filip Pizlo wrote:
>
>
> For as little worth as it is, I agree with you Filip that providing
> low-level primitives would be best in terms of a foun
On Apr 12, 2013, at 1:39 PM, Jarred Nicholls wrote:
> On Fri, Apr 12, 2013 at 2:54 PM, Filip Pizlo wrote:
>
> On Apr 12, 2013, at 8:36 AM, "Hudson, Rick" wrote:
>
> > I'm assuming that we agree that JavaScript must evolve to leverage the
> > hardware's power stingy parallelism.
>
> True, b
Argh, sending from the right address this time.
On Fri, Apr 12, 2013 at 4:39 PM, Jarred Nicholls
wrote:
> On Fri, Apr 12, 2013 at 2:54 PM, Filip Pizlo wrote:
>
>>
>> On Apr 12, 2013, at 8:36 AM, "Hudson, Rick"
>> wrote:
>>
>> > I'm assuming that we agree that JavaScript must evolve to leverage
On Apr 12, 2013, at 8:36 AM, "Hudson, Rick" wrote:
> I'm assuming that we agree that JavaScript must evolve to leverage the
> hardware's power stingy parallelism.
True, but there is also the question of how high of a priority we should give
to this relative to other project goals, and also wh
I'm assuming that we agree that JavaScript must evolve to leverage the
hardware's power stingy parallelism. For completeness there seems to be the
following approaches.
1) Add nothing to the language and rely on increasingly sophisticated
compilers to detect opportunities to safely paral
35 matches
Mail list logo
