A wild idea to parallelize the main thread

[Xiaocheng Hu]

Hi platform-architecture-dev,

I'll made a talk at BlinkOn19 on an idea of splitting the main thread into two threads, one running page state mutator tasks (parser, JS, ...) and the other running page lifecycle updates (layout etc). Since this is the most relevant group, I think it will help to also have some discussion here.

Here's the deck: https://groups.google.com/a/chromium.org/g/platform-architecture-dev/c/AhKMedu6lJI/m/xKJAD5jNBAAJ

Please note that I'm no longer at Google, so this should be considered as input from external developers.

Regards,

Xiaocheng

[Chris Harrelson]

Hi Xiaocheng,

On Fri, Sep 27, 2024 at 3:07 PM Xiaocheng Hu <xiaoc...@chromium.org> wrote:

Hi platform-architecture-dev,

I'll made a talk at BlinkOn19 on an idea of splitting the main thread into two threads, one running page state mutator tasks (parser, JS, ...) and the other running page lifecycle updates (layout etc). Since this is the most relevant group, I think it will help to also have some discussion here.

Here's the deck: https://groups.google.com/a/chromium.org/g/platform-architecture-dev/c/AhKMedu6lJI/m/xKJAD5jNBAAJ

I think that might be the wrong link, this is a groups discussion?

 

Please note that I'm no longer at Google, so this should be considered as input from external developers.

Regards,

Xiaocheng

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/89661d42-7119-4da5-836b-6ba839be2780n%40chromium.org.

[Xiaocheng Hu]

My bad... Here's the correct link:

https://docs.google.com/presentation/d/1iqAZ1xKHzs8gqdqCP78aOhHVf2lixCtGg8-yy1ARTkY/edit?usp=sharing

[Stefan Zager]

Hi Xiaocheng,

I've spent a lot of time (probably too much time) trying to do more or less exactly this. I have many thoughts, docs, and slide decks that are available upon request (or if you want to really dig into it, feel free to put something on my calendar). But here are the bullet points:

1.  It's really super incredibly hard. I did a project in this area called Non-Blocking Commit which was absolutely the tiniest incremental piece I could shave off of this problem, and it took me about 18 months to ship it.

2. We would need to add new API's to unlock some of the biggest benefits. It's not a change that will immediately benefit the entire web.

3. There is likely a low ceiling as to the potential benefit to be unlocked, mostly because a) there is just a massive amount of long-running javascript on the web, and b) javascript has run-to-completion semantics. The upshot is that you may have a rendering thread that is pumped and ready to work; but there's no work for that thread to do while an uninterruptible javascript task is running. If we're *very* clever, we could maybe eliminate one or two frames of jank out of a sequence of hundreds of missed frame deadlines while a 3-second javascript task runs.

I hate to be a wet blanket, and I don't want to discourage anyone from taking a look into this area with fresh eyes. I just want to hopefully give you a head start and help you avoid going down some of the deepest rabbit holes.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABDsFEbiUMdfcPhXR4Q4AmmaXTpWCPiDOnLeD_p_kdvzKUdX3w%40mail.gmail.com.

[Stefan Zager]

Also:

4. Parallelism won't help on under-powered mobile devices that don't have extra cores available; and even on desktop, additional parallelism will negatively affect the performance of existing threads due to additional context switching and competition for hardware resources. We observed this with Non-Blocking Commit.

[Xiaocheng Hu]

Hi Stefan,

Please do share more details of the investigations you've made.

Like the saying goes, every genius idea has been thoroughly investigated. Let me see if I really get anything new here.

[Kentaro Hara]

Thanks Xiaocheng for the idea!

Generally speaking, I love the idea of moving more things off the main thread. However, I guess there are things we can do before moving the layout step off the main thread.

cc runs on a dedicated thread. The next thing we should try is to move the paint step off the main thread maybe? I think @Philip Rogers @Kent Tamura @Koji Ishii are looking into 1) making LayoutObjects generational and 2) implementing the off-thread painting. What's the status of the investigation / are there any lessons we learned so far?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABDsFEbsU71UJjtZvkTU4pKyoz0LoLr7rZrBcA33zGVwepf7hw%40mail.gmail.com.

--

Kentaro Hara, Tokyo

[Stefan Zager]

Here are a few artifacts...

The first slide deck I made on the topic, for BlinkOn 10. Some of the details have evolved since then -- most importantly, Composite After Paint and LayoutNG have shipped -- but the main ideas mostly hold. The last few slides touch briefly on what new API's might be necessary to take full advantage, and introduce the idea of "generational DOM", which I still think is likely the best approach.

Here's a more detailed deck about generational DOM. It's also a bit dated -- I made this before we started garbage collecting most of the rendering types -- but at a high level it could still work.

A more recent slide deck about threaded rendering and Non-Blocking Commit as the first step in a strategy of taking slices off the end of the main thread rendering pipeline. To Kentaro's point: the next logical step in this strategy would be to move composited layer allocation off the main thread. There's pretty clear line of sight to doing this, but it's not at clear that it would be worth the effort. After that would be moving paint off the main thread, which would likely be harder by an order of magnitude.

Here's a retrospective of Non-Blocking Commit, which details some of the limitations to threaded rendering it revealed.

I'm happy to discuss any of this, either on this thread or off (not sure how interesting it is to the full recipient list).

[Stefan Zager]

Here's maybe the best tl;dr from the Non-Blocking Commit retrospective doc:

"NBC is based on a larger strategy of incrementally moving the main/compositor thread boundary earlier in the rendering pipeline, by taking chunks of work off the end of the main thread’s rendering task and moving them to another thread. The results of NBC do not necessarily invalidate the strategy – the data is mixed, and it’s likely that existing metrics do not fully capture the effect. NBC represents the minimum possible pursuit of this strategy: Commit is a tiny slice of the time spent in rendering updates, so the effect of NBC was expected to be modest. Nevertheless, the evidence from NBC suggests that future projects along these lines should consider whether the costs of concurrency will mitigate the benefit of parallelism."

[TAMURA, Kent]

On Mon, Sep 30, 2024 at 11:20 AM Kentaro Hara <har...@chromium.org> wrote:

Thanks Xiaocheng for the idea!

Generally speaking, I love the idea of moving more things off the main thread. However, I guess there are things we can do before moving the layout step off the main thread.

cc runs on a dedicated thread. The next thing we should try is to move the paint step off the main thread maybe? I think @Philip Rogers @Kent Tamura @Koji Ishii are looking into 1) making LayoutObjects generational and 2) implementing the off-thread painting. What's the status of the investigation / are there any lessons we learned so far?

 We decided to cancel our project after seeing the results of the Non-Blocking Commit project Stefan mentioned,

--

TAMURA Kent
Software Engineer, Google