Intent to Experiment: WebAssembly Dynamic Tiering

164 views
Skip to first unread message

Andreas Haas

unread,
Oct 4, 2021, 4:04:19 AMOct 4
to blink-dev

Contact emails

ah...@chromium.org

Explainer

At the moment, V8 compiles WebAssembly modules by first compiling all functions with the baseline compiler Liftoff, and then immediately compiling all functions with the optimizing compiler TurboFan, see https://v8.dev/docs/wasm-compilation-pipeline. On some websites we see that TurboFan compilation can block JavaScript workers from execution. With WebAssembly dynamic tiering we want to reduce the CPU time of TurboFan compilation by only optimizing functions which were already executed a few times.

Specification

This feature is just a new implementation of an already implemented specification.

Summary

With WebAssembly Dynamic Tiering, an heuristic decides which functions of a WebAssembly module get optimized, and when the optimization is triggered. This is an improvement to the existing eager optimization approach, where all functions get optimized immediately after baseline compilation is finished. WebAssembly Dynamic Tiering reduces the resource consumption of the optimizing compiler, and prevents the compiler from competing with the web application for resources.



Blink component

Blink>JavaScript>WebAssembly

TAG review

Not applicable

TAG review status

Not applicable

Risks

WebAssembly dynamic tiering may lead to unexpected performance regressions. 

Interoperability and Compatibility



Gecko: No signal

WebKit: No signal

Web developers: No signals


Goals for experimentation

The goal of the experiment is to allow important partners to experiment with the performance impact of WebAssembly dynamic tiering. This feature may change the startup behavior of WebAssembly code significantly, which is why we would like to experiment in the guarded environment of an origin trial first.

Reason this experiment is being extended



Ongoing technical constraints



Debuggability

Debugging behavior does not change

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

Flag name

WebAssemblyDynamicTiering

Requires code in //chrome?

False

Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5685307493056512

This intent message was generated by Chrome Platform Status.

Mike West

unread,
Oct 4, 2021, 11:39:32 AMOct 4
to Andreas Haas, blink-dev
On Mon, Oct 4, 2021 at 10:04 AM 'Andreas Haas' via blink-dev <blin...@chromium.org> wrote:

Contact emails

ah...@chromium.org

Explainer

At the moment, V8 compiles WebAssembly modules by first compiling all functions with the baseline compiler Liftoff, and then immediately compiling all functions with the optimizing compiler TurboFan, see https://v8.dev/docs/wasm-compilation-pipeline. On some websites we see that TurboFan compilation can block JavaScript workers from execution. With WebAssembly dynamic tiering we want to reduce the CPU time of TurboFan compilation by only optimizing functions which were already executed a few times.

Specification

This feature is just a new implementation of an already implemented specification.

Summary

With WebAssembly Dynamic Tiering, an heuristic decides which functions of a WebAssembly module get optimized, and when the optimization is triggered. This is an improvement to the existing eager optimization approach, where all functions get optimized immediately after baseline compilation is finished. WebAssembly Dynamic Tiering reduces the resource consumption of the optimizing compiler, and prevents the compiler from competing with the web application for resources.



Blink component

Blink>JavaScript>WebAssembly

TAG review

Not applicable

TAG review status

Not applicable

Risks

WebAssembly dynamic tiering may lead to unexpected performance regressions. 

Interoperability and Compatibility



Gecko: No signal

WebKit: No signal

Web developers: No signals

My understanding is that this doesn't create any web-facing change in behavior, but only a potential change in performance?

In that case, then signals and TAG review and etc. all seem quite reasonable to skip. :)
 


Goals for experimentation

The goal of the experiment is to allow important partners to experiment with the performance impact of WebAssembly dynamic tiering. This feature may change the startup behavior of WebAssembly code significantly, which is why we would like to experiment in the guarded environment of an origin trial first.

Reason this experiment is being extended



Ongoing technical constraints



Debuggability

Debugging behavior does not change

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

Flag name

WebAssemblyDynamicTiering

Requires code in //chrome?

False

Estimated milestones

No milestones specified


Can you specify milestones? :) How many releases do you need in order to evaluate the impact?

-mike
 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5685307493056512

This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTveTudJkMbuBMyZ%2BZTv334audVik78gEJTzmjym4X6wJTg%40mail.gmail.com.

Andreas Haas

unread,
Oct 4, 2021, 12:08:53 PMOct 4
to Mike West, blink-dev
We would like to do the experiment from M96 until M102. We would like to improve the heuristics for when to optimize over time, which requires the longer time span.  

Mike West

unread,
Oct 4, 2021, 12:58:26 PMOct 4
to Andreas Haas, blink-dev
If this doesn’t have web-visible behavioral impact, I don’t think you generally need API owner approval. In this case, I think it’s reasonable to ask for such approval, as you want to use Origin Trials to more clearly involve partners in the experimentation process, do their own A/B testing, etc.

I think a marginally-longer-than-usual experiment lifetime is fine here, since there’s zero burn-in risk (again, because there’s no behavioral change).

I am, though, a little concerned about the validity of any data you obtain via this self-selected mechanism. Will you be running a more-typical percentage trial at the same time to evaluate the impact of the change more broadly?

-mike
--
-mike

Andreas Haas

unread,
Oct 5, 2021, 3:51:55 AMOct 5
to Mike West, blink-dev
Hi Mike,

We want to use the Origin Trial to get some early information from partners, but then plan to ship with a finch trial and roll it out step by step while observing the impact on webpages we are not directly aware of.

Cheers,
Andreas

Mike West

unread,
Oct 5, 2021, 3:54:25 AMOct 5
to Andreas Haas, blink-dev
Thanks! In that case, LGTM to use origin trials for this otherwise web-invisible experiment. :)

-mike
--
-mike

Andreas Haas

unread,
Oct 5, 2021, 4:04:01 AMOct 5
to Mike West, blink-dev
Thanks!
Reply all
Reply to author
Forward
0 new messages