8 ms·

Google removes SIMD.js support from Chromium

92 points by chroem- 9y ago

earngurus 9y ago
Know more here http://bit.do/Google-removes-SIMD-js http://bit.do/Google-removes-SIMD-js
sowbug 9y ago
Interesting fact: the owner of that bug wrote Raster Blaster <https://en.wikipedia.org/wiki/Raster_Blaster> https://en.wikipedia.org/wiki/Raster_Blaster> and Pinball Construction Set <https://en.wikipedia.org/wiki/Pinball_Construction_Set> https://en.wikipedia.org/wiki/Pinball_Construction_Set>.
- rashkov 9y ago
  Thanks. The links don't work unfortunately -- no need to format them, but that is a fun detail to know about
  - sowbug 9y ago
    Oops, bad habit. Thanks. Too late to edit, so for posterity: https://en.wikipedia.org/wiki/Raster_Blaster https://en.wikipedia.org/wiki/Raster_Blaster and https://en.wikipedia.org/wiki/Pinball_Construction_Set https://en.wikipedia.org/wiki/Pinball_Construction_Set
- smacktoward 9y ago
  It's that Bill Budge?!? Oh, man, I lost way too much of my youth to Pinball Construction Set. Glad to see he's still cutting code.
tlb 9y ago
Better explanation at https://bugs.chromium.org/p/v8/issues/detail?id=6020&desc=2 https://bugs.chromium.org/p/v8/issues/detail?id=6020&desc=2
millstone 9y ago
This is a good decision. SIMD.js never made sense to me. Writing vector code that outperforms scalar code requires not only fine-grained control over issues like alignment, but also requires targeting specific SIMD instruction sets. You must write your vector code with the emitted assembly in mind, because if you fall off the fast path and the compiler switches to scalar code or does a library call or something, you've lost any performance gain and then some. A generic SIMD API on a high-level language like JavaScript is as bad as it gets. I looked at what it would take to port some of my vector code to SIMD.js and it wasn't remotely plausible. Also saving 10% of the v8 code size is enormous. The right path forwards is for JITs to emit SIMD code when possible, and for JS engines to provide OpenCL-like GPGPU-targeted APIs, following the trail that WebGL blazed with JS shaders.
- pcwalton 9y ago
  > The right path forwards is for JITs to emit SIMD code when possible "Just rely on autovectorization" is what people have wanted to do for over a decade. We have yet to see satisfactory results for C. Why would JS be any easier? > and for JS engines to provide OpenCL-like GPGPU-targeted APIs, following the trail that WebGL blazed with JS shaders. Please don't! Nobody wants more APIs that rely on passing a string for a driver blob to compile. Standardize an IR (Web Assembly makes the most sense here).
  - marmaduke 9y ago
    > We have yet to see satisfactory results for C... That's not a fair assessment. Major compilers (LLVM, GCC, Intel) are able to vectorize real world code to a useful extent. No, they won't reorganize data to be more SIMD friendly but they can take the hard work out of writing ISA specific assemmbly.
    - dagss 9y ago
      I think the parent with "satisfactory" meant "possible to achieve the maximum performance the hardware will support" (after all why settle for less?) You are answering another question. Also, the point where you have reorganized your whole computation to be AVX-friendly it is just extra obfuscation to try to wrtie regular C and then check that the compiler outputs what you meant. Just using SIMD instructions is WYSIWYG; writing pure C is like competing in an obfuscated C contest. Keep in mind it is not only SIMD, one might use shuffles and permutations in registers etc to communicate between the SIMD "threads". I think the SSE/AVX intrinsics are nice to work with; they do what they say, but GCC will also turn them into something else if not supported, and perhaps apply some extra optimizations.
ndesaulniers 9y ago
Comment #145 back on Feb 13 actually has the commit: https://bugs.chromium.org/p/v8/issues/detail?id=4124#c145 https://bugs.chromium.org/p/v8/issues/detail?id=4124#c145 The bug links to the actual discussion ("The V8 binary has a considerable amount of code that could be trimmed"): https://bugs.chromium.org/p/v8/issues/detail?id=5948 https://bugs.chromium.org/p/v8/issues/detail?id=5948 There's a nice treemap of the size of pieces of v8 in the first comment on that bug. Comment #3 on the bug notes that SIMD.js is large: https://bugs.chromium.org/p/v8/issues/detail?id=5948#c3 https://bugs.chromium.org/p/v8/issues/detail?id=5948#c3 Finally, comment #6 "There's no reason to keep the simd.js stuff around. I'll take it out ASAP.": https://bugs.chromium.org/p/v8/issues/detail?id=5948#c6 https://bugs.chromium.org/p/v8/issues/detail?id=5948#c6 Someone notes that v8 is reduced by 500KB on Android. Looks like it got reverted a few times for breaking Node.js tests, someone notes "can you wait a day until we sort out Node first?" then SIMD.js gets removed again the next day. So I assume they "sorted it out w/ Node" w/e that means? Also, trying to learn how the macroassembler is laid out; seems pretty neat. Kinda baffled that s390 and ppc are supported. Was kinda for mips but I guess that's an Android supported platform... A lot of the code that looks like it's being assembled by the macro assembler has double underscore followed by a space, followed by argument lists, which is curious looking at first glance. Looks like the double underscores are defined as: #define __ ACCESS_MASM(masm)
pluma 9y ago
This seemed shocking as I thought SIMD was still on track for inclusion in the next ECMAScript release as the proposal was on stage 3 the last time I checked (stage 4 means "it's in the spec", so stage 3 generally means "shipping ASAP"). I first thought Google had single-handedly decided to violate the spec. However it turns out the SIMD proposal has been dead since at least April: https://github.com/tc39/ecmascript_simd/commit/c6ca655dcbfc014d82f3ec500c2e41db34a1dee8 https://github.com/tc39/ecmascript_simd/commit/c6ca655dcbfc0... So this isn't really "Google kills SIMD" but "Google kills implementation of dropped proposal". It's still surprising to see proposals get canned this late into the process. The only other example of a late-stage retraction I can think of is Object.observe, which was originally expected to become part of the 2016 edition: https://esdiscuss.org/topic/an-update-on-object-observe https://esdiscuss.org/topic/an-update-on-object-observe

92 points by chroem- 9y ago

Know more here http://bit.do/Google-removes-SIMD-js http://bit.do/Google-removes-SIMD-js

Interesting fact: the owner of that bug wrote Raster Blaster <https://en.wikipedia.org/wiki/Raster_Blaster> https://en.wikipedia.org/wiki/Raster_Blaster> and Pinball Construction Set <https://en.wikipedia.org/wiki/Pinball_Construction_Set> https://en.wikipedia.org/wiki/Pinball_Construction_Set>.

rashkov 9y ago
Thanks. The links don't work unfortunately -- no need to format them, but that is a fun detail to know about
- sowbug 9y ago
  Oops, bad habit. Thanks. Too late to edit, so for posterity: https://en.wikipedia.org/wiki/Raster_Blaster https://en.wikipedia.org/wiki/Raster_Blaster and https://en.wikipedia.org/wiki/Pinball_Construction_Set https://en.wikipedia.org/wiki/Pinball_Construction_Set
smacktoward 9y ago
It's that Bill Budge?!? Oh, man, I lost way too much of my youth to Pinball Construction Set. Glad to see he's still cutting code.

tlb 9y ago

Better explanation at https://bugs.chromium.org/p/v8/issues/detail?id=6020&desc=2 https://bugs.chromium.org/p/v8/issues/detail?id=6020&desc=2

millstone 9y ago

This is a good decision. SIMD.js never made sense to me. Writing vector code that outperforms scalar code requires not only fine-grained control over issues like alignment, but also requires targeting specific SIMD instruction sets. You must write your vector code with the emitted assembly in mind, because if you fall off the fast path and the compiler switches to scalar code or does a library call or something, you've lost any performance gain and then some. A generic SIMD API on a high-level language like JavaScript is as bad as it gets. I looked at what it would take to port some of my vector code to SIMD.js and it wasn't remotely plausible. Also saving 10% of the v8 code size is enormous. The right path forwards is for JITs to emit SIMD code when possible, and for JS engines to provide OpenCL-like GPGPU-targeted APIs, following the trail that WebGL blazed with JS shaders.

pcwalton 9y ago
> The right path forwards is for JITs to emit SIMD code when possible "Just rely on autovectorization" is what people have wanted to do for over a decade. We have yet to see satisfactory results for C. Why would JS be any easier? > and for JS engines to provide OpenCL-like GPGPU-targeted APIs, following the trail that WebGL blazed with JS shaders. Please don't! Nobody wants more APIs that rely on passing a string for a driver blob to compile. Standardize an IR (Web Assembly makes the most sense here).
- marmaduke 9y ago
  > We have yet to see satisfactory results for C... That's not a fair assessment. Major compilers (LLVM, GCC, Intel) are able to vectorize real world code to a useful extent. No, they won't reorganize data to be more SIMD friendly but they can take the hard work out of writing ISA specific assemmbly.
  - dagss 9y ago
    I think the parent with "satisfactory" meant "possible to achieve the maximum performance the hardware will support" (after all why settle for less?) You are answering another question. Also, the point where you have reorganized your whole computation to be AVX-friendly it is just extra obfuscation to try to wrtie regular C and then check that the compiler outputs what you meant. Just using SIMD instructions is WYSIWYG; writing pure C is like competing in an obfuscated C contest. Keep in mind it is not only SIMD, one might use shuffles and permutations in registers etc to communicate between the SIMD "threads". I think the SSE/AVX intrinsics are nice to work with; they do what they say, but GCC will also turn them into something else if not supported, and perhaps apply some extra optimizations.

ndesaulniers 9y ago

Comment #145 back on Feb 13 actually has the commit: https://bugs.chromium.org/p/v8/issues/detail?id=4124#c145 https://bugs.chromium.org/p/v8/issues/detail?id=4124#c145 The bug links to the actual discussion ("The V8 binary has a considerable amount of code that could be trimmed"): https://bugs.chromium.org/p/v8/issues/detail?id=5948 https://bugs.chromium.org/p/v8/issues/detail?id=5948 There's a nice treemap of the size of pieces of v8 in the first comment on that bug. Comment #3 on the bug notes that SIMD.js is large: https://bugs.chromium.org/p/v8/issues/detail?id=5948#c3 https://bugs.chromium.org/p/v8/issues/detail?id=5948#c3 Finally, comment #6 "There's no reason to keep the simd.js stuff around. I'll take it out ASAP.": https://bugs.chromium.org/p/v8/issues/detail?id=5948#c6 https://bugs.chromium.org/p/v8/issues/detail?id=5948#c6 Someone notes that v8 is reduced by 500KB on Android. Looks like it got reverted a few times for breaking Node.js tests, someone notes "can you wait a day until we sort out Node first?" then SIMD.js gets removed again the next day. So I assume they "sorted it out w/ Node" w/e that means? Also, trying to learn how the macroassembler is laid out; seems pretty neat. Kinda baffled that s390 and ppc are supported. Was kinda for mips but I guess that's an Android supported platform... A lot of the code that looks like it's being assembled by the macro assembler has double underscore followed by a space, followed by argument lists, which is curious looking at first glance. Looks like the double underscores are defined as: #define __ ACCESS_MASM(masm)

pluma 9y ago

This seemed shocking as I thought SIMD was still on track for inclusion in the next ECMAScript release as the proposal was on stage 3 the last time I checked (stage 4 means "it's in the spec", so stage 3 generally means "shipping ASAP"). I first thought Google had single-handedly decided to violate the spec. However it turns out the SIMD proposal has been dead since at least April: https://github.com/tc39/ecmascript_simd/commit/c6ca655dcbfc014d82f3ec500c2e41db34a1dee8 https://github.com/tc39/ecmascript_simd/commit/c6ca655dcbfc0... So this isn't really "Google kills SIMD" but "Google kills implementation of dropped proposal". It's still surprising to see proposals get canned this late into the process. The only other example of a late-stage retraction I can think of is Object.observe, which was originally expected to become part of the 2016 edition: https://esdiscuss.org/topic/an-update-on-object-observe https://esdiscuss.org/topic/an-update-on-object-observe