Intent to Experiment: WebAssembly Dynamic Tiering

[Andreas Haas]

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]

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]

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]

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]

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]

Thanks! In that case, LGTM to use origin trials for this otherwise web-invisible experiment. :)

-mike

--

-mike

[Andreas Haas]

Thanks!