web: Enable the bulk-memory WebAssembly extension

[torokati44]

This should improve all around performance on web, to a varying degree.
I'll gladly provide benchmark numbers upon request; but so far I've seen that at least while decoding videos, this should save anywhere between 10% and 20% of processing time, "for free".

There are still quite a few calls to the naive memcpy and memset functions (explicit loop and load/store in WASM), mostly from core and std.
To get rid of these as well, the build-std cargo feature would be needed (which does something similar to what Xargo was for), but that is a nightly-only flag as of now, because there are still some issues with it.

This raises the minimum browser version requirements to:

• Chrome 75 (released on 2019-06-05): https://v8.dev/blog/v8-release-75#bulk-memory-operations, https://www.chromestatus.com/feature/4590306448113664
  Chrome 87 is already required
• Firefox 79 (released on 2020-06-28): https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/79#webassembly
  Firefox 84 is already required
• Safari 15.0 (EDIT: released on 2021-09-20 - finally!): https://developer.apple.com/safari/technology-preview/release-notes/#r121

I know basically nothing about the habits of 🍎 ecosystem users, but based on past data, Safari 15.0 is supposed to be the most used version by November, and is supposed to reach near its top market share by about January or February:

Source: https://gs.statcounter.com/browser-version-market-share

So, I don't think this should be merged for at least a couple weeks, but we can still talk about it here until then. :)

[adrian17]

Can you mark it as either draft or smth like "[DO NOT MERGE YET]"? Just in case :)

Also, when the time comes, let's also test AVM-heavy code. I did find cases where extremely AVM-heavy code was slightly slower as bulk-memory has actually higher overhead than wasm memcpy for extremely small arrays. Since then rustc improved a bit and generates less memcpys, but let's see in several months.

[torokati44]

I switched from setting RUSTFLAGS to adding .cargo/config.toml, both for the new flag, and for the static CRT flag on windows, for consistency's sake; and to make sure the value set for the envvar in the two separate places don't conflict.

[relrelb]

Great! LGTM

[torokati44]

I'd appreciate it if someone on Windows could check if the new condition for the crt-static target-feature indeed works as intended!

[Herschel]

Unfortunately the windows setting in config.toml doesn't work because of rust-lang/cargo#6858. I think we'll have to stick with setting RUSTFLAGS on CI for that.

[torokati44]

Oh... :/ Thanks for checking!

How about the original, less ideal version?

[target.i686-pc-windows-msvc]
rustflags = ["-C", "target-feature=+crt-static"]

[target.x86_64-pc-windows-msvc]
rustflags = ["-C", "target-feature=+crt-static"]

[torokati44]

I'm just worried about the potential conflict where the CI setup (including the action building the nightly releases) sets the RUSTFLAGS envvar unconditionally (it's just empty on non-windows targets), and it always takes priority over what's in .cargo/config.toml.

[adrian17]

Considering this is bound to wait for a couple more months, maybe for now we could just wait and see if toolchains figure out something nicer? I think long-term, rustc itself will be switching some of wasm features on by default.

[Herschel]

[target.i686-pc-windows-msvc]
rustflags = ["-C", "target-feature=+crt-static"]

[target.x86_64-pc-windows-msvc]
rustflags = ["-C", "target-feature=+crt-static"]

This should be fine -- I also tried using desktop/build.rs but unfortunately error: Only -land-Lflags are allowed in build script ofruffle_desktop v0.1.0 (D:\projects\ruffle\desktop): -C target-feature=+crt-static``.

Should we think about shipping multiple WASM modules with features enabled/disabled, and loading the appropriate module based on browser capabilities? Maybe bulk extensions will be ubiquitous enough that it's not a big deal, but there will be other features that we may want to selectively enable as well (webgpu, SIMD, interface types, ...). This might allow us to keep running on slightly older browsers while these features roll out.

[torokati44]

Partly I'm also hoping for what @adrian17 wrote: That over (hopefully not too long) time, rustc/cargo itself will enable the "most important" extensions by default, so we won't have to deal with them, and can delegate the responsibility for the effects of this decision to the Rust team.

But I can also imagine building even just two WASM modules: one for the "happy path" (when support is detected for all the extensions we want), and one for compatibility (which enables no extensions at all, like now).

This would complicate the build process and the loader code, result in slightly larger releases and hosted package, and might even bring difficulties when debugging user issues... - for perhaps too slight a benefit. (Let it be some extra performance now, or legacy compatibility later...) Whether it's worth it or not, is of course not an easy question.

(Well, I, for one, am silently rooting that something like this can be made to work, but I understand that it's not trivial and not without downsides, so...)

[torokati44]

Safari 15 is now out!!!! Everyone, update right away!!

[torokati44]

With Safari 14.1 already starting to slowly fade out in favor of 15.0, I'll leave the judgement to merge this at any time to someone else.

Here is the download link for the CSV data for these charts.

[kmeisthax]

I'm going to point out that, unlike prior versions, Apple's decided to keep iOS 14 installable for an additional year. This may hamper adoption.

[torokati44]

Oh no... :/
And can Safari not be updated to 15.0 on iOS 14?

[kmeisthax]

Safari and iOS are one single thing - you can't update them independently. Also, Apple doesn't allow shipping third-party browser engines, so all alternate browsers on iOS are using the same version of Safari that ships with the OS.

[torokati44]

Yeah, I knew about the web engine restriction, but not about last-gen iOS being stuck with the same version it came with... That's a bummer. Anyway, I can wait!

[Herschel]

Getting a panic on VP6BR::parse_header in this file:
vp6.zip

[torokati44]

I think the panic in VP6BR::parse_header is not related to this PR.
Just tested your file with this commit on top of the now-fixed #5369, and got no panic.

[torokati44]

Gratuitous Safari market share update:
14.1 just dipped below 2%, and 15.0 is really close to 1%!

(Sorry for the transparent background...)

[Herschel]

I guess we should decide when to pull the trigger on this -- possibly when 15.0 becomes majority, or wait even longer? Can iOS 15.0 run on every device that 14.0 can? We should also have a "you need bulk memory/update your browser" error message in place.

I think the panic in VP6BR::parse_header is not related to this PR.

Sorry, this comment was supposed to be on the VP6 PR!

[torokati44]

I guess we should decide when to pull the trigger on this -- possibly when 15.0 becomes majority, or wait even longer?

Here's yet another fancy graph, this time with linear extrapolations based on the last 1, 2, and 3 weeks.
Squinting at the lines hard enough, from far enough, I'd say 14.1 might dip below 1.0% right around Christmas. Based on this, my suggestion for an arbitrary point in time to merge this would be around New Year's Day, just to leave some slack.

Can iOS 15.0 run on every device that 14.0 can?

I, for one, have no idea. However, at least according to this and this list, looks like it should be the case. The latter includes the iPhone 13 variants, but no other difference.

We should also have a "you need bulk memory/update your browser" error message in place.

Would we want something like https://github.com/GoogleChromeLabs/wasm-feature-detect for this, or just another rung in the if-ladder in ruffle-player.ts that maps an error message to a PanicError?

[Herschel]

If we can deduce this specific error from the panic, it'd be nice if we can avoid the dependency. But if this is difficult, we can rely on wasm-feature-detect.

[torokati44]

Oh no, what is happening?

EDIT:
So, it looks like, by the end of this year, Safari 15.0 is expected to have a -0.5% market share. :|

Are people reverting en masse, or was the initial bump just a little post-release hype?

[torokati44]

OOooohhh, Safari 15.1 has already been out for a while now, that's what's been happening!

Looks much better! :) How did I not think about this until now...

[torokati44]

BTW, just today, for the first time ever, Safari 15.x market share surpassed that of Safari 14.x!

EDIT: Hmm, but what about browsers on iWhatevers, whose engine is that of Safari? Do they advertise themselves as not-Safari, despite not being better than it in this regard? 🤔

[yakagami]

@torokati44 assuming the same website is correct, here is the iOS market share by version which also tells us the Safari version as they are updated together.
15.x seems to be sitting at 48% and is rising.

Link:
https://gs.statcounter.com/ios-version-market-share/mobile-tablet/worldwide/#monthly-202112-202112-bar

And here is the last 3 months

Link:
https://gs.statcounter.com/ios-version-market-share/mobile-tablet/worldwide/#monthly-202109-202112

[torokati44]

Superseded by #5834! Take that, Safari! 😃