SIMD JavaScript Support Added To Firefox, Under Review For Chrome

[codedivine]

This work is a direct port of SIMD types I did for Dart in 2013. Exact same types and operations. If you're interested in seeing what the API looks like, I maintain the ECMAScript proposal as a polyfill library. If you want to experience the full speed of these types today, you can use Dart (the SIMD types are fully accelerated on SSE and NEON in the Dart VM).

More information:

Talk I gave last year
Programming guide

John McCutchan

This is definitely interesting and thanks for the great work! Is there an email list or similar, where I should post for more discussion?

I was wondering why you didn't include any float64 SIMD types. I have been meaning to port some scientific computing code to Javascript that would greatly benefit from float64 SIMD types. After all, SSE and AVX both include float64 SIMD instructions and ARMv8 includes SIMD float64 as well. For architectures that lack float64 SIMD instructions (such as ARMv7 NEON) you could probably just compile to sequence of scalar instructions anyway so that shouldn't be an issue?

[Luke_Wolf]

Except the other options defeat the purpose of using JavaScript... so they're portable.

"So they're portable"?... Are you daft?

Most languages are portable (however libraries you use may not be, but that's on you to choose platform independent libraries and frameworks such as Qt), the only advantage that javascript provides due to a freak of nature is that it's the only language native to web browsers (native in the sense it doesn't need a plugin), and if you really want to go with the browser I can use Flash, Java, Silverlight, or NaCl, however if I'm not so insane that I desire such a thing I can write an application targeting the JVM or Mono, or any of the widely ported scripting languages and run applications natively on the device outside of a browser , even making use of the internet as opposed to the web, or I can even use C++ and Qt to write once and compile independent binaries for all of the architectures or if I decide to use LLVM I can even make a JITed version.

Simply put, Portability is not and never was a reason to use Javascript.

the "reason" to use javascript is because it's a language that lets you do quick and dirty things easily for situations (particularly UI) where the best engineering in the world doesn't really matter. For anything else you want at a bare minimum a strict and statically typed language, and I would say preferably one that is explicitly typed, and on top of that JS has a lot of weird stuff going on.

[brad0]

Higher complexity games that need this kind of performance, emulators, and media processing should not be written in javascript. At most you can argue that the game scripts can be written in javascript but even then there's better options. It's the wrong tool for the job. Typescript and friends improve the situation but even then you're still in a horrible situation.

Javascript is fine for simple games and things that aren't all that complex, animations, UI stuff, things like that. That said I really don't want to imagine the eye-burning horror that an emulator or encoder written in JS will look like in terms of the codebase.

Except the other options defeat the purpose of using JavaScript... so they're portable.

[Luke_Wolf]

There is no good reason not to improve the performance of JavaScript for apps that can benefit from it such as games, emulators or forms of media processing. You're just being narrow minded.

Higher complexity games that need this kind of performance, emulators, and media processing should not be written in javascript. At most you can argue that the game scripts can be written in javascript but even then there's better options. It's the wrong tool for the job. Typescript and friends improve the situation but even then you're still in a horrible situation.

Javascript is fine for simple games and things that aren't all that complex, animations, UI stuff, things like that. That said I really don't want to imagine the eye-burning horror that an emulator or encoder written in JS will look like in terms of the codebase.

[brad0]

As much as it might improve performance, it feels just so wrong to me that we're at the point in the modern web where we need SIMD instructions. Seriously... if you need that kind of performance client side maybe you shouldn't be writing a web application?

There is no good reason not to improve the performance of JavaScript for apps that can benefit from it such as games, emulators or forms of media processing. You're just being narrow minded.

[Luke_Wolf]

As much as it might improve performance, it feels just so wrong to me that we're at the point in the modern web where we need SIMD instructions. Seriously... if you need that kind of performance client side maybe you shouldn't be writing a web application?

[johnmccutchan]

Ported from Dart

This work is a direct port of SIMD types I did for Dart in 2013. Exact same types and operations. If you're interested in seeing what the API looks like, I maintain the ECMAScript proposal as a polyfill library. If you want to experience the full speed of these types today, you can use Dart (the SIMD types are fully accelerated on SSE and NEON in the Dart VM).

More information:

Talk I gave last year
Programming guide

John McCutchan

[brad0]

People not obsessed with FOSS who continue in the face of FOSS self-righteous condesencion to make computing better for everyone.

Without FOSS this and a lot of other software would not exist.

P.S. I expect everyone to thank Google for ARM64, LLVM and everything that goes with it for they are so ``Do No Evil'' in today's youth's eyes.

What? The ARM64 backend is from Apple. The original roots for LLVM were from Chris Lattner and Vikram Adve while at the University of Illinois.

Where would the world be without Google creating WebKit?

Google did not create WebKit. Apple did.

Why we better thank KDE because we know Apple owes WebKit to KDE

Of course the KDE project deserves some credit. Without KHTML / KJS WebKit would not exist.

the same folks who never used WebKit until the entire industry did.

They had no choice but to wait until KDE 5 to switch the default rendering / JavaScript engine as it would have broken backwards compatibility. WebKit was not a 100% compatible drop in replacement for all of the API KHTML / KJS provided.

[AJenbo]

WebKit was actually pretty bad (safari3 would consistantly crash on undo) prior to when Google started contributing. Apple also did a realy bad job of sharing patches with khtml pretty much killing it. Though i will agree that Apple deserves much credit for there part in WebKit's development.

[Marc Driftmeyer]

Dear Apple,

Thanks for being such a huge backer of LLVM and creating Clang, for without this investment [and later Google, SONY, Cray, IBM, Intel, etc] these advances don't create Emscripten, and dozens of other recently projects making commercial and foss software that much better.

Sincerely,

People not obsessed with FOSS who continue in the face of FOSS self-righteous condesencion to make computing better for everyone.

P.S. I expect everyone to thank Google for ARM64, LLVM and everything that goes with it for they are so ``Do No Evil'' in today's youth's eyes.

Where would the world be without Google creating WebKit? Why we better thank KDE because we know Apple owes WebKit to KDE, the same folks who never used WebKit until the entire industry did. /s