If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Comment

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

Comment

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.

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.

Comment

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).

Comment

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?

Comment

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.

Comment

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.