- From: Marc Fawzi <marc.fawzi@gmail.com>
- Date: Thu, 2 Apr 2015 08:22:18 -0700
- To: Brendan Eich <brendan@secure.meer.net>
- Cc: Travis Leithead <travis.leithead@microsoft.com>, Boris Zbarsky <bzbarsky@mit.edu>, "public-webapps@w3.org" <public-webapps@w3.org>, Jonas Sicking <jonas@sicking.cc>, Michaela Merz <michaela.merz@hermetos.com>, Florian Bösch <pyalot@gmail.com>, Glenn Adams <glenn@skynav.com>, Ashley Gullen <ashley@scirra.com>, George Calvert <george.calvert@loudthink.com>
- Message-ID: <CACioZivsd1+5Qyck09aGYty+enfma6pzP2Npa7Z4bLp8YD41Hw@mail.gmail.com>
Boom! http://pixelscommander.com/en/web-applications-performance/render-html-css-in-webgl-to-get-highest-performance-possibl/ This looks pretty amazing. On Sat, Feb 14, 2015 at 4:01 PM, Brendan Eich <brendan@secure.meer.net> wrote: > Hang on a sec before going off to a private or single-vendor thread > because you think I sent you packing on topics that are of interest (as > opposed to "Thread-Safe DOM"). > > I'm sorry I missed Travis's mail in my Inbox, but I see it now in the > archives. The topics listed at the link he cites *are* interesting to many > folks here, even if public-webapps may not always be the best list: > > ----- > > IRC log: http://www.w3.org/2014/10/29-parallel-irc > > See also: Mohammad (Moh) Reza Haghighat's presentation on parallelism in > the 29 October 2014 Anniversary Symposium talks > > We covered three main potential areas for parallelism: > > 1. Find additional isolated areas of the web platform to enable > parallelism. We noted Canvas Contexts that can migrate to workers to enable > parallelism. Initial thoughts around UIWorkers are brewing for handling > scrolling effects. Audio Workers are already being developed with specific > real-time requirements. What additional features can be made faster by > moving them off to workers? > > 2. "Shared memory" models. This seems to require an investment in the > JavaScript object primitives to enable multiple threaded access to object > dictionaries that offer robust protections around multi-write scenarios for > properties. > > 3. Isolation boundaries for DOM access. We realized we needed to find an > appropriate place to provide isolation such that DOM accesses could be > "assigned" to a parallelizable JS engine. Based on discussion it sounded > like element sub-trees wouldn't be possible to isolate, but that documents > might be. Iframes of different origins may already be parallelized in some > browsers. > > > ----- > > Mozilla people have done work in all three areas, collaborating with Intel > and Google people at least. Ongoing work continues as far as I know. Again, > some of it may be better done in groups other than public-webapps. I cited > roc's blog post about custom view scrolling, which seems to fall under > Travis's (1) above. > > Please don't feel rejected about any of these work items. > > /be > > > > Marc Fawzi <mailto:marc.fawzi@gmail.com> >> February 13, 2015 at 12:45 PM >> Travis, >> >> That would be awesome. >> >> I will go over that link and hopefully have starting points for the >> discussion. >> >> My day job actually allows me to dedicate time to experimentation (hence >> the ClojureScript stuff), so if you have any private branches of IE with >> latest DOM experiments, I'd be very happy to explore any new potential or >> new efficiency that your ideas may give us! I'm very keen on that, too. >> >> Off list seems to be best here.. >> >> Thank you Travis. I really appreciate being able to communicate freely >> about ideas. >> >> Marc >> >> >> Boris Zbarsky <mailto:bzbarsky@mit.edu> >> February 11, 2015 at 12:33 PM >> On 2/11/15 3:04 PM, Brendan Eich wrote: >> >>> If you want multi-threaded DOM access, then again based on all that I >>> know about the three open source browser engines in the field, I do not >>> see any implementor taking the huge bug-risk and opportunity-cost and >>> (mainly) performance-regression hit of adding barriers and other >>> synchronization devices all over their DOM code. Only the Servo project, >>> which is all about safety with maximal hardware parallelism, might get >>> to the promised land you seek (even that's not clear yet). >>> >> >> A good start is defining terms. What do we mean by "multi-threaded DOM >> access"? >> >> If we mean "concurrent access to the same DOM objects from both a window >> and a worker, or multiple workers", then I think that's a no-go in Servo as >> well, and not worth trying to design for: it would introduce a lot of spec >> and implementation complexity that I don't think is warranted by the use >> cases I've seen. >> >> If we mean the much more modest "have a DOM implementation available in >> workers" then that might be viable. Even _that_ is pretty hard to do in >> Gecko, at least, because there is various global state (caches of various >> sorts) that the DOM uses that would need to either move into TLS or become >> threadsafe in some form or something... Again, various specs (mostly DOM >> and HTML) would need to be gone over very carefully to make sure they're >> not making assumptions about the availability of such global shared state. >> >> We should add lighter-weight workers and immutable data structures >>> >> >> I should note that even some things that could be immutable might >> involved a shared cache in current implementations (e.g. to speed up >> sequential indexed access into a child list implemented as a linked >> list)... Obviously that sort of thing can be changed, but your bigger >> point that there is a lot of risk to doing that in existing implementations >> remains. >> >> -Boris >> >> Brendan Eich <mailto:brendan@secure.meer.net> >> February 11, 2015 at 12:04 PM >> >> >> Sorry, I was too grumpy -- my apologies. >> >> I don't see much ground for progress in this whole thread or the >> sub-thread you started. >> >> If we're talking about sync XHR, I gave my informed opinion that >> deprecating it is empty talk if actually obsoleting by whichever browser >> takes the first hit inevitably leads to market share loss or (before that) >> developers screaming enough to get the CEO's attention. We will simply >> waste a lot of time and energy (we already are) arguing and hollering for >> and against deprecation, without any definite hope of obsolescence. >> >> If you want multi-threaded DOM access, then again based on all that I >> know about the three open source browser engines in the field, I do not see >> any implementor taking the huge bug-risk and opportunity-cost and (mainly) >> performance-regression hit of adding barriers and other synchronization >> devices all over their DOM code. Only the Servo project, which is all about >> safety with maximal hardware parallelism, might get to the promised land >> you seek (even that's not clear yet). >> >> Doing "over the top" JS libraries/toolchains such as React is excellent, >> I support it. But it does not share mutable or immutable state across >> threads. JS is still single-threaded, event loop concurrency with mutable >> state, in its execution model. This execution model was born and co-evolved >> with the DOM 20 years ago (I'm to blame). It can't be changed >> backward-compatibly and no one will break the Web. >> >> We should add lighter-weight workers and immutable data structures and >> other such things, and these are on the "Harmony" agenda with the JS >> standards body. We might even find race-confined ways to run asm.js code on >> multiple workers with shared memory in an ArrayBuffer -- that's an area of >> active research. But none of these things is anything near to what you >> described in the forked subject line: "Thread-Safe DOM". >> >> I'll leave it at this.I invite others from Mozilla, Google, Apple, and MS >> to speak up if they disagree. >> >> /be >> >>
Received on Thursday, 2 April 2015 15:23:27 UTC