Google removes SIMD.js support from Chromium

https://bugs.chromium.org/p/v8/issues/detail?id=4124&can=2&start=0&num=100&q=&colspec=ID%20Type%20Status%20Priority%20Owner%20Summary%20HW%20OS%20Component%20Stars&groupby=&sort=

by chroem- • 9 years ago

92 56 9 years ago

bugs.chromium.org

tlb• 9 years ago

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

sowbug2• 9 years ago

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

rashkov• 9 years ago

Thanks. The links don't work unfortunately -- no need to format them, but that is a fun detail to know about

sowbug2• 9 years ago

Oops, bad habit. Thanks. Too late to edit, so for posterity: https://en.wikipedia.org/wiki/Raster_Blaster and https://en.wikipedia.org/wiki/Pinball_Construction_Set

smacktoward• 9 years 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.

millstone• 9 years 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.

sillysaurus32• 9 years ago

I think this highlights the absurdity of writing vector code in higher-level constructs rather than the direct ASM. Writing in ASM is not that hard, and the gains can be enormous. I've seen graphics operations sped up by 5x or more, just by writing hand-optimized vector ops in assembly.

This is one of Visual Studio's core strengths vs GCC. Writing an __asm { } block is much more pleasant than the syntax GCC forces on you. Unfortunately this inertia is one reason games tend to be windows-only, even in the post-Apple era.

In other words, phrases like "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" invokes a feeling of "What? Why does the compiler get any say in what the vector code looks like? Oh, right, everybody shies away from writing ASM by hand nowadays." Which is valid, but sometimes having ultra control is extremely nice. It just feels cool to get a 2x speedup by being persistent and clever. (Those speedups come with future technical debt, though, so there are good arguments against it.)

slededit• 9 years ago

it was nicer until support for __asm was removed in the 64-bit compiler. Now if you want assembly you need to write the whole function in it.

zvrba4• 9 years ago

Writing an __asm { } block is much more pleasant than the syntax GCC forces on you.

Or just use intrinsics and let the compiler arrange register allocation, scheduling, etc. for you.

sddfd3• 9 years ago

The compiler should vectorize functions automatically, without user intervention.

Writing assembly code to use SIMD instructions is a vote of no confidence on your compiler.

If your compiler of choice can't do automatic vectorization switch to one that can, or get people to implement that feature in your compiler of choice.

vanderZwan• 9 years ago

(Those speedups come with future technical debt, though, so there are good arguments against it.)

Have you seen Halide? Might be a way to have your cake and eat it too.

http://halide-lang.org/

asveikau2• 9 years ago

Last I knew __asm doesn't work on amd64 or arm. Still the case?

pcwalton2• 9 years 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).

marmaduke5• 9 years 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.

z3t4• 9 years ago

what about __wasm {} in JS !? you can sort of already do that.

coldtea2• 9 years ago

"Just rely on autovectorization" is what people have wanted to do for over a decade. We have yet to see satisfactory results for C.

That's because C is crap in that aspect and doesn't give enough guarantees and intents.

With a better language you could have great autovectorization in ever higher level code than C.

rurban2• 9 years ago

Yes, their explanation is here: https://bugs.chromium.org/p/v8/issues/detail?id=6020&desc=2

Supporting it in WebAssembly transparently is a much better way to go forward.

markdog12• 9 years ago

A generic SIMD API on a high-level language like JavaScript is as bad as it gets.

Dart VM SIMD API seems pretty nice to me: https://www.dartlang.org/articles/dart-vm/simd

  double computeAverage(Float32x4List list) {
    Float32x4 sum = new Float32x4.zero();
    for (int i = 0; i < list.length; i++) {
      sum += list[i];
    }
    // Perform horizontal operations once.
    double average = sum.x + sum.y + sum.z + sum.w;
    return average / (list.length*4);
  }

You may not be able to squeeze out the same perf, but seems worth having to me.

JS engines to provide OpenCL-like GPGPU-targeted API

This is an interesting project, deep neural nets running on WebGPU: https://mil-tokyo.github.io/webdnn/

ndesaulniers• 9 years ago

Comment #145 back on Feb 13 actually has the commit: 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

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

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

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• 9 years 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/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

Google removes SIMD.js support from Chromium

Related Stories