Thanks Mounir! :) *LGTM to experiment* M84-M86
+Jason Chase <cha...@chromium.org> on the subject of "indirect" Origin Trials. That's something we've seen as a hurdle on other fronts as well (e.g. third party vendors who want to experiment, but need their customers to sign up). On Wed, Apr 8, 2020 at 8:36 PM Deepti Gandluri <gdee...@chromium.org> wrote: > Thanks Mounir, adjusting the experimental timeline to the recommended > 3-release trial, and then optionally extending based on feedback sounds > reasonable to me. > > On Tuesday, April 7, 2020 at 4:40:18 PM UTC-7, Mounir Lamouri wrote: >> >> Thank you for the details, Deepti. I'm not an owner but I would recommend >> going for a 3-release Origin Trial and assess the situation then and decide >> whether extending makes sense. If there isn't enough usage by then, >> extending would probably be an easy call. It seems better to me to assess >> it then than preemptively set the experiment length to 5 releases assuming >> the usage and feedback will take some time to ramp up. >> >> -- Mounir >> >> On Fri, 3 Apr 2020 at 13:21, Deepti Gandluri <gdee...@chromium.org> >> wrote: >> >>> The partners we have lined up, currently have a (mostly) full SIMD >>> version of their applications ready. So they would be able to enable this >>> right away. >>> >>> There are a couple of issues I was hoping to address with a longer >>> trial, for the partners that currently have an in progress implementation, >>> as well as for partners where to get feedback, there is a level of >>> indirection involved when it comes to how users can take advantage of this. >>> To clarify what I mean by the second use case - for partners like Halide >>> <https://github.com/halide/Halide>, and Tensorflow.js >>> <https://blog.tensorflow.org/2020/03/introducing-webassembly-backend-for-tensorflow-js.html>, >>> which have WebAssembly backends with experimental SIMD support, to get >>> feedback their users will have to sign up for an origin trial, as they >>> serve as backends/libraries and are not end users themselves. So some of >>> that buffer was to ensure we can reach a larger number of users - I'm >>> somewhat unsure how to account for that type of indirection as I haven't >>> found many other examples where this is the case, so feedback here is >>> welcome. >>> >>> With respect to "ongoing standardization effort", I should have been >>> clearer there. The proposal is currently at Phase 3 >>> <https://github.com/WebAssembly/meetings/blob/master/process/phases.md#3-implementation-phase-community--working-group>, >>> and the standardization effort here refers to moving to Phase 4 >>> <https://github.com/WebAssembly/meetings/blob/master/process/phases.md#4-standardize-the-feature-working-group>, >>> the requirement for which is that there needs to be one other Web VM that >>> implements this. At this point, the shape of the API is quite stable, we >>> have an implementation in both V8, as well as the WebAssembly LLVM >>> toolchain, and we are waiting on more engine implementations to move the >>> proposal forward. >>> >>> On Friday, April 3, 2020 at 11:05:32 AM UTC-7, Mounir Lamouri wrote: >>>> >>>> Deepti, what did you mean by "ongoing standardization effort"? Is the >>>> API shape still being discussed? >>>> >>>> On Thu, 2 Apr 2020 at 14:12, Yoav Weiss <y...@yoav.ws> wrote: >>>> >>>>> I'm wondering if there's something preventing partners from >>>>> implementing SIMD versions of their applications with the behind-the-flag >>>>> implementation? >>>>> >>>>> I'm assuming you already have some partners lined up for the >>>>> experiment. Would they be able to develop using the flagged >>>>> implementation? >>>>> That would enable us to start the origin trial when they're ready, and as >>>>> a >>>>> result, have a shorter trial which purpose is to gather real life usage >>>>> metrics. >>>>> >>>>> On Fri, Mar 27, 2020 at 11:02 PM Deepti Gandluri <gdee...@chromium.org> >>>>> wrote: >>>>> >>>>>> Hi Mounir, >>>>>> >>>>>> The reason for a longer trial here is that this proposal is somewhat >>>>>> large, and while enabling auto-vectorization can give some performance >>>>>> benefits, to really experiment with this applications may have to rewrite >>>>>> their existing code that uses native SIMD intrinsics to use portable Wasm >>>>>> intrinsics (example: Emscripten SIMD intrinsics header >>>>>> <https://github.com/emscripten-core/emscripten/blob/master/system/include/wasm_simd128.h>), >>>>>> or builtins that map to Wasm operations. >>>>>> >>>>>> The intent is to build in enough time for new applications to >>>>>> experiment with this in parallel to ongoing standardization effort in the >>>>>> WebAssembly CG. The ballpark estimate I've used here is from previous >>>>>> applications experimenting with SIMD, with some buffer to gather data. >>>>>> That >>>>>> said, I do understand that this is a longer trial than is usual, so would >>>>>> be open to adjusting the timeline based on concerns. >>>>>> >>>>>> Thanks, >>>>>> Deepti >>>>>> >>>>>> On Friday, March 27, 2020 at 1:29:09 PM UTC-7, Mounir Lamouri wrote: >>>>>>> >>>>>>> Hi Deepti, >>>>>>> >>>>>>> This Intent to Experiment looks good, though, I'm wondering why this >>>>>>> is expected to run for 5 releases, which is roughly 6 months. Is there >>>>>>> something specific we are concerned about and that this timeline aims to >>>>>>> solve? >>>>>>> >>>>>>> -- Mounir >>>>>>> >>>>>>> On Fri, 27 Mar 2020 at 07:22, Deepti Gandluri <gdee...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> Contact emails >>>>>>>> >>>>>>>> gdee...@chromium.org, nattes...@chromium.org, z...@chromium.org >>>>>>>> >>>>>>>> >>>>>>>> Spec >>>>>>>> >>>>>>>> Overview document: >>>>>>>> https://github.com/WebAssembly/simd/blob/master/proposals/simd/SIMD.md >>>>>>>> >>>>>>>> Proposal directory: >>>>>>>> https://github.com/WebAssembly/simd/tree/master/proposals/simd >>>>>>>> >>>>>>>> Tag review: https://github.com/w3ctag/design-reviews/issues/487 >>>>>>>> >>>>>>>> >>>>>>>> Summary >>>>>>>> >>>>>>>> The WebAssembly SIMD proposal defines a portable, performant subset >>>>>>>> of SIMD operations that map to vector instructions that are available >>>>>>>> across most modern hardware platforms. >>>>>>>> >>>>>>>> >>>>>>>> This is purely a WebAssembly performance feature that adds >>>>>>>> WebAssembly operations and does not affect web API behavior, but is >>>>>>>> still >>>>>>>> useful for developers to be aware of as it can change performance >>>>>>>> characteristics of applications using WebAssembly. >>>>>>>> >>>>>>>> >>>>>>>> Link to “Intent to Prototype” blink-dev discussion: >>>>>>>> >>>>>>>> This links to the Intent to Implement discussion for Simd.js >>>>>>>> <https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/Simd.js%7Csort:date/blink-dev/rhPPSQVodq0/zr4HRxXjBgAJ>, >>>>>>>> which was the basis for the WebAssembly SIMD. The Spec section above >>>>>>>> has >>>>>>>> updated links for WebAssembly SIMD, as well as the Tag review. >>>>>>>> >>>>>>>> >>>>>>>> Goals for experimentation >>>>>>>> >>>>>>>> Performance: >>>>>>>> >>>>>>>> The goal for this experiment is to determine the performance >>>>>>>> benefit of having WebAssembly SIMD enabled applications in production >>>>>>>> code, >>>>>>>> and determine real world performance numbers. We currently have data >>>>>>>> from >>>>>>>> isolated benchmarks, and demos, but these do not always reflect real >>>>>>>> world >>>>>>>> usage. >>>>>>>> >>>>>>>> >>>>>>>> API Shape: >>>>>>>> >>>>>>>> The SIMD proposal currently consists of a set of operations that >>>>>>>> are well supported across most modern hardware platforms. The set of >>>>>>>> instructions available on hardware is large and varied, and we are >>>>>>>> looking >>>>>>>> for feedback on whether this portable subset is sufficient for a cross >>>>>>>> section of applications. >>>>>>>> >>>>>>>> >>>>>>>> Experimental timeline >>>>>>>> >>>>>>>> M84-M89 >>>>>>>> >>>>>>>> >>>>>>>> Any risks when the experiment finishes? >>>>>>>> >>>>>>>> The risk is a drop in performance for sites that were enhancing >>>>>>>> performance using WebAssembly SIMD operations. >>>>>>>> >>>>>>>> >>>>>>>> Ongoing technical constraints >>>>>>>> >>>>>>>> None. >>>>>>>> >>>>>>>> >>>>>>>> Debuggability >>>>>>>> >>>>>>>> WebAssembly SIMD needs debugging support in devtools for 128-bit >>>>>>>> values, as well as baseline compiler support in V8. Both of these >>>>>>>> efforts >>>>>>>> are ongoing. (Tracking bugs: crbug.com/v8/10347, crbug.com/v8/9909) >>>>>>>> >>>>>>>> >>>>>>>> Will this feature be supported on all five Blink platforms >>>>>>>> supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and >>>>>>>> Android)? >>>>>>>> >>>>>>>> Yes. >>>>>>>> >>>>>>>> >>>>>>>> Link to entry on the feature dashboard >>>>>>>> <https://www.chromestatus.com/> >>>>>>>> >>>>>>>> https://www.chromestatus.com/feature/6533147810332672 >>>>>>>> >>>>>>>> -- >>>>>>>> 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+unsubscr...@chromium.org. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e4010247-bb4c-47a4-9b82-ea8188c3b232%40chromium.org >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e4010247-bb4c-47a4-9b82-ea8188c3b232%40chromium.org?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 blink-dev+unsubscr...@chromium.org. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e9f7ebf3-495e-46b7-82bd-a0f963f1625d%40chromium.org >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e9f7ebf3-495e-46b7-82bd-a0f963f1625d%40chromium.org?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 blink-dev+unsubscr...@chromium.org. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEh8BicQHAygqbS0icM4R_%2B9qgzWmOS%2BmqtAicWiqZmRkA%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEh8BicQHAygqbS0icM4R_%2B9qgzWmOS%2BmqtAicWiqZmRkA%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 blink-dev+unsubscr...@chromium.org. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/722401d6-1424-47c5-913f-33092ae4b6d0%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/722401d6-1424-47c5-913f-33092ae4b6d0%40chromium.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CACj%3DBEi1TWMLZL8hug8WG%3DOpG-W9RrEFO8-RUjUB2L9c%2BcOKgA%40mail.gmail.com.
