Re: [whatwg] Real-time thread support for workers

Le 09/08/2012 09:59, Jussi Kalliokoski a écrit :
> Hello David,
Hi Jussi,

> On Thu, Aug 9, 2012 at 3:54 PM, David Bruant <bruant.d@gmail.com 
> <mailto:bruant.d@gmail.com>> wrote:
>
>     * The last source is your own content competing with itself for CPU.
>
>
> *snip*
>
>     One question I have is whether different parts of your own content
>     (like different workers) should declare which priority should be
>     given or whether the application should be written in a way that
>     is resistant to high CPU stress (e.g. doing few work besides audio
>     work).
>
>
> I'm sorry, not entirely sure I follow... :)
No worries, it wasn't really clear, I admit :-)
Your proposal draws an API between the developer and the system that is 
based on assigning a priority and letting the system judge what to do 
with that. I was suggesting that more (not all, but more) should be put 
on the developer shoulders rather than letting the computer guess.

>     Since the only relevant case for priorities is the third one, I'd
>     like to question the relevance of the use case.
>     Is implementing per-browsing-content web worker priority worth the
>     result? Will we be able to really notice an improvement in the
>     audio quality that often?
>
>
> Yes. Especially in mobile devices it makes a world of difference when 
> for example on a single-core phone you have an audio app in the 
> foreground, and a Twitter client in the background. If the Twitter 
> client decides to update its content, the audio is most likely to 
> glitch and this is most likely not the way the user wanted it to go.
We're back to the case of 2 competing content. An API shouldn't be able 
to influence that for the reason cited in the previous message (which 
you said you were worried about)
I know Firefox is doing work currently to reduce the work done by 
background tabs (short setTimeouts are clamped to 1s when in background 
for instance. There is other work going on).

Prioritizing between background and foreground tasks is an 
implementation issue, not an issue that should requires a web content 
API IMHO.

Once again, the only use case being discussed here is likely content 
competing against itself for CPU.


> Here's the discussion thread on AudioWG [1] and a good article 
> exploring the subject of interaction between audio and the rest of the 
> system [2].
I haven't fully read the AudioWG thread (I will. Meanwhile, if the 
thread addresses my point, can you link to specific messages?), but I 
have read the article.
Most points either don't apply to the web or are on the developer 
shoulders already.
* Blocking
=> Except for a couple of pathological exceptions (alert, prompt, sync 
xhr), JavaScript has a non-blocking model

* Poor worst-case complexity algorithms
=> That's almost fully on developer shoulders. The web platform 
implementers try to avoid such algorithms already (which is a dilemma in 
text-layout algorithms I heard)

* Locking
=> The message passing model has no notion of locking.

* Memory allocation
=> On developer shoulders mostly.

* Invisible things: garbage collection
=> GC could be "controlled" by a priority actually, but this needs to be 
discussed with the JS engine folks.

* page faults
=> You can't do anything against that on the web.

One thing that isn't explicitely written is that when doing audio in C, 
you have shared-memory in threads (hence locking) and my guess is that 
it's a good source of. You however don't have shared memory in JS with 
web workers. Transferables are a good step forward, maybe a better thing 
to discuss would be to move further in that direction.

According to this article, it seems that the web platform is well-suited 
(no lock, no blocking) for audio actually, isn't it?

> The gain for audio is so significant
Did someone do research on that? Do we have benchmarks, numbers? Or is 
the "significant" hypothetical?

> that a lot of the working group seems to think it's a good idea to 
> have a whole lot of (not very modular to be honest) native DSP nodes 
> that can run in a priority thread just to get the audio running in a 
> priority thread, and I think priority thread workers is a way better idea.
>
>     I would be more in favor of browsers sharing with content how busy
>     the CPU is (in a way or another) so that the content shuts down
>     things itself and decides programmatically what is worth running
>     and what isn't.
>
>
> Yes, that would be ideal. However I fear it's not good enough for audio.
Purely based on the article, it seems that the web platform does a good 
job at helping developers write good real-time code (no blocking, no 
locking, no built-in poor worst-case complexity algorithms). The other 
points (memory allocation, page faults) are either on the developer 
shoulders or at the system level and priority would unlikely help with 
that (if it does, I would be interested in reading the related research 
on the topic). Priority could help with GC (not doing it under 
pressure), but at the same time, GC are undergoing tremedous 
improvements (incremental GC in Chrome and now in Firefox, Generational 
GC in Chrome and soon in FF) lately, so it would need to be proven too 
that the difference would be that substancial.
Not having shared memory may be a bottleneck. Transferable helps.

All in all, the article you linked to makes me more confident that the 
web is close to be ready for real-time code.
It would be nice (a requirement?) to see actual research on every 
assumption on how a web worker priority mechanism would improve audio 
quality.

David

Received on Thursday, 9 August 2012 15:09:34 UTC