LGTM3 On Fri, Mar 17, 2023 at 2:47 AM Yoav Weiss <[email protected]> wrote:
> 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUXocyEzokDtbP5V6rw7Fzy8yOqyvWEZbx0Sqy%3DqC4-7A%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/CAOMQ%2Bw_9dm8%2Bapp6t6e4WHk_x9xkNzEQ62v3YZPyU%2BiniKgMUA%40mail.gmail.com.
