LGTM2 On Thu, Mar 16, 2023 at 8:01 PM Deepti Gandluri <[email protected]> wrote:
> Thanks Alex! > > On Wed, Mar 15, 2023 at 9:06 AM Alex Russell <[email protected]> > wrote: > >> Hey Deepti, >> >> LGTM1 >> >> I'm excited by the performance this intent will unlock. >> >> The explainer sort of hints at it, but what do you expect the impact to >> be on binary sizes based on compilers building in workarounds for missing >> relaxed instructions? How do you anticipate that developers will adopt to >> the presence/absence of these ops while balancing WASM binary size concerns? >> > > We don't expect that this will result in significant binary size > increases. For the majority of the operations that are introduced here, > they map 1:1 to non-relaxed fallbacks in the existing SIMD proposal. For > code-gen, we would generate fewer instructions overall because the existing > operations generate extra code for consistent handling of values across > processors (NaNs, +-infinity, and some other cases where the masks/bounds > vary), this in fact is the value add for the proposal that generating fewer > (machine) instructions gives us more performance for benchmarks that are > sensitive to it. The only two that don't have a fallback are the Dot > product, and the FMA operations. These don't have a direct fallback, and > would be comparatively expensive to emulate (mul+add in place of FMA, and a > more involved lowering > <https://github.com/WebAssembly/relaxed-simd/issues/52> for dot, dotAdd > operations of ~5 SIMD operations). > > The absence of these ops should not be visible, or affect developers that > don't want to use these operations. For developers that are writing new > applications, they wouldn't run into them unless they need them as the > usage model is that they would have to explicitly invoke them using > compiler intrinsics, or special toolchain flags. Wasm tools would not be > generating relaxed SIMD ops by default, so these operations require users > to know about them or opt-in by using intrinsics. The trickier case is when > libraries already use them, and developers are using libraries pre-compiled > to Wasm in their applications, in that case the recommended option would be > to have a SIMD/Scalar fallback for the code that uses these operations. > >> >> On TAG review, this *is* a web-visible change, so it would be helpful to >> keep that in mind in the future. Would encourage you to send the TAG an FYI >> about new language additions to help them stay informed and consider those >> capabilities when reviewing other features. >> > > Thanks for the clarification, is the right way to send an FYI through the > issue > tracker <https://github.com/w3ctag/design-reviews/issues>? > >> >> Thanks. >> >> Alex >> >> On Thursday, March 9, 2023 at 11:42:18 PM UTC-8 Deepti Gandluri wrote: >> >>> On Thu, Mar 9, 2023 at 2:38 PM Mike Taylor <[email protected]> >>> wrote: >>> >>>> On 3/9/23 3:42 PM, Deepti Gandluri wrote: >>>> >>>> Quick note that I realized my title was accidentally cropped, it should >>>> be: >>>> >>>> "Intent to Implement and Ship: WebAssembly Relaxed SIMD". >>>> >>>> On Wed, Mar 8, 2023 at 4:11 PM Deepti Gandluri <[email protected]> >>>> wrote: >>>> >>>>> Contact emails [email protected], [email protected], >>>>> [email protected] >>>>> >>>>> Explainer >>>>> https://github.com/WebAssembly/relaxed-simd/blob/main/proposals/relaxed-simd/Overview.md >>>>> >>>>> Specification >>>>> https://github.com/WebAssembly/relaxed-simd/tree/main/document >>>>> >>>>> Summary >>>>> >>>>> Relaxed SIMD extends the existing SIMD proposal to introduce vector >>>>> instructions that relax the strict determinism constraints of portable >>>>> SIMD >>>>> to take better advantage of the underlying hardware. The operations >>>>> introduced in this proposal take advantage of widely available instruction >>>>> sets to accelerate compute workloads. >>>>> >>>>> Blink component Blink>JavaScript>WebAssembly >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EJavaScript%3EWebAssembly> >>>>> >>>>> TAG review Not required as per: >>>>> https://v8.dev/docs/feature-launch-process. This introduces an >>>>> additional set of vector operations to WebAssembly, and makes no API >>>>> changes. >>>>> Risks >>>>> >>>>> >>>>> Interoperability and Compatibility >>>>> >>>>> *Gecko*: In development, enabled in nightly >>>>> >>>>> *WebKit*: No signal as per request for position: >>>>> mail-archive.com/[email protected]/msg30574.html >>>>> >>>> This should be updated to neutral, with concerns around potential >>>> compat issues (it was manually moved to the new standards-position repo: >>>> https://github.com/WebKit/standards-positions/issues/4#issuecomment-1170364495 >>>> ). >>>> >>> >>> Thanks for the pointer, I missed the issue being moved over. >>> >>>> >>>>> *Web developers*: Strongly positive, Proposal in Phase 3 in the >>>>> WebAssembly CG the proposal was incubated to address some of the >>>>> developer/user requests from the previous SIMD proposal. >>>>> >>>>> *Other signals*: Proposal voted to a provisional phase 4 as per >>>>> meeting notes in the February 14th CG meeting (notes: >>>>> https://github.com/WebAssembly/meetings/blob/main/main/2023/CG-02-14.md). >>>>> The feature has consensus in the CG, but the vote is provisional till the >>>>> formal spec is up to date (Tracking issue: >>>>> https://github.com/WebAssembly/relaxed-simd/issues/134, PRs also in >>>>> flight). >>>>> >>>>> WebView application risks >>>>> >>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>> that it has potentially high risk for Android WebView-based applications? >>>>> No >>>>> >>>>> >>>>> Debuggability >>>>> >>>>> Supported instructions are enabled in Liftoff, and are visible to >>>>> DevTools for debuggability. >>>>> >>>>> >>>>> 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 >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>> ? Not applicable, tested by WebAssembly spec tests >>>>> >>>>> Flag name V8: --wasm-relaxed-simd Chrome: >>>>> Features::kWebAssemblyRelaxedSimd >>>>> >>>>> Requires code in //chrome? False >>>>> >>>>> Tracking bug https://bugs.chromium.org/p/v8/issues/detail?id=12284 >>>>> >>>>> Estimated milestones >>>>> >>>>> 114 >>>>> >>>>> Anticipated spec changes >>>>> >>>>> No anticipated spec changes, but some potential for compat issues >>>>> based on hardware, more details in this Entropy.md >>>>> <https://github.com/WebAssembly/relaxed-simd/blob/main/proposals/relaxed-simd/Entropy.md>, >>>>> and the linked issues. >>>>> >>>> Thanks for the Entropy.md doc - it's incredibly helpful. >>>> >>>> For most of the exposed entropy, we already expose this via the >>>> User-Agent string, or the Arch UA Client Hint. Can you say more about >>>> "Differences between hardware that has native FMA support, and hardware >>>> that does not." and "whether the Dot product extension is supported in the >>>> most optimal codegen" - any idea what the distributions would look there >>>> there? >>>> >>>> As to compat, "code compiled for one browser works differently on a >>>> different browser" - this sounds a little bit scary! Do we have any ideas >>>> on how to minimize (I assume preventing isn't a reality) this outcome? >>>> >>> >>> I re-posted this thread to fix the title, and have pasted+responded to >>> this in the newer thread. Sorry for the churn! >>> >>>> Link to entry on the Chrome Platform Status >>>>> https://chromestatus.com/feature/5082417973952512 >>>>> >>>> -- >>>> 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 [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALi9WK_SOE5jAVCPydhY0Xn4S6P2rr_W9qhQhN5tA0Ew9vJEdg%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALi9WK_SOE5jAVCPydhY0Xn4S6P2rr_W9qhQhN5tA0Ew9vJEdg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALi9WK9pxdZX21u95VTRS_d9bA8HwRO1adCy9Q2NaWeb2UCanw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALi9WK9pxdZX21u95VTRS_d9bA8HwRO1adCy9Q2NaWeb2UCanw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUXocyEzokDtbP5V6rw7Fzy8yOqyvWEZbx0Sqy%3DqC4-7A%40mail.gmail.com.
