Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Saying goodbye to asm.js

spidermonkey.dev

Post reply on HN
Print view View original

51–60 of 164 posts

Re: Saying goodbye to asm.js

#51

Post by mikece »

muvlon wrote: post #24
futune wrote: post #15

So the death of asm.js is upon us? We are drifting away from the timeline of the prophecy: https://www.destroyallsoftware.com/talks/the-birth-and-death... (And to those who haven't encountered this before, I strongly recommend a watch. It may be the greatest tech talk of all time, for certain values of greatest.)

With this technology's death, the thread of prophecy is severed. Restore a saved game to restore the weave of fate, or persist in the doomed world you have created.

Not really: ASM.js became WASM. What killed the possibility of WASM being The One Way to run everything is AI... the one wildcard that Gard Bernhardt didn't predict.

Re: Saying goodbye to asm.js

#52

Post by flohofwoe »

oneshtein wrote: post #23

asm.js is faster than WASM, and it can do everything that JS can do.

Congratulations, two spectacularly wrong 'facts' in one short sentence is quite an achievement ;)

It's true that in the beginning (around 2017), WASM wasn't much faster than asm.js, but meanwhile WASM has seen real performance improvements.

Featurewise, asm.js is much closer to WASM than to regular JS, it definitely cannot do everything that regular JS can do (mainly because asm.js is limited to the Number type, it cannot deal with JS strings or objects).

Re: Saying goodbye to asm.js

#54

Post by mikece »

metmac wrote: post #12

I’ll never forget watching Gary Bernhardt give his talk on JavaScript.[0] Was my introduction to asm.js, and the rabbithole associated with compiling code to run in the browser. 12 years on, it’s shocking how much of his fiction became reality. [0] https://www.destroyallsoftware.com/talks/the-birth-and-death...

And if not for the rise of AI it's possible that WASM as a machine-level compilation target for all languages might have happened. As much as Gary predicted he didn't see AI coming.

Re: Saying goodbye to asm.js

#55

Post by lmkg »

pjmlp wrote: post #27

> asm.js was Mozilla’s response to the question posed by NaCl and PNaCl: how can the web run code at native speeds? Had it been today, Chrome would have just pushed NaCl and PNaCl no matter what, and then everyone would complain why Safari and Firefox aren't keeping up with "Web" standards.

I mean that's still basically what they tried to do at the time. They were trying to get them through web standards committees and everything.

IIRC a big reason it didn't end up working was because NaCl was such a "big" technology and asm.js such a "small" one that asm.js was able to reach production-ready first despite starting work several years later.

Re: Saying goodbye to asm.js

#56

Post by Rohansi »

chilmers wrote: post #35
looneysquash wrote: post #19

I personally think this is a mistake. But I'm not sure how much it matters. It's not like a lot of people were using asm.js still AFAIK. But wasm is too isolated from javascript. From my limited use of it, I was considering trying to compile to asmjs instead. But I wasn't sure that emscripten still fully supported it. You can't call most web apis from wasm. But more important for what i was trying to do, you can't ze…

Perhaps I'm misunderstanding, but doesn't asm.js have the same restrictions? I.e. you can't call web APIs directly from asm.js code, you still need special handling for "foreign" functions.

Depends how you want to look at it. On one side asm.js is just JavaScript with special JIT handling, so you should be able to mix them. On the other side you have C/C++/Rust/whatever compiled to asm.js which needs to go through hoops to call normal JavaScript code

Re: Saying goodbye to asm.js

#57

Post by flohofwoe »

tardedmeme wrote: post #50
xyzzy_plugh wrote: post #41

Earlier quoted context omitted.

I still maintain the notion we're in the wrong timeline, one where PNaCl died and instead of a worthy, timely successor we end up being boiled alive in a soup of Electron apps. I really thought, for a time, that we'd be doing everything in the browser . And in a way that's increasingly true, but it all just feels worse than ever. I like WASM and I want to like WASM but the rate of maturity within the ecosystem is inc…

What are the key differences between PNaCl and WASM?

There were 3 systems, all with interesting differences.

The original NaCl was a 'validated subset' of native CPU machine code (e.g. actual x86 machine code with some instructions and instruction sequences disallowed which would allow to escape the sandbox).

The next iteration was P(ortable)-NaCl which replaced the native machine code with a subset of LLVM bitcode, which was then compiled at load time. Unfortunately with this step NaCl lost most of its advantages. Startup time was atrocious because it was basically the second half of the LLVM compilation pipeline (from LLVM-IR to machine code). LLVM-IR also isn't actually great as CPU-agnostic bytecode.

WASM was designed from the ground up as CPU agnostic bytecode that's also much easier and faster to validate.

The only major advantage of PNaCl vs early WASM was that PNaCl supported shared-memory threading right from the start (this is still knee-capped in WASM because of the COOP/COEP response header requirement).

...apart from Emscripten => asm.js => WASM, and Google's NaCl/PNaCl there was also a system by Adobe (Flascc/Alchemy(?) I forgot all the names this went through) to compile C and C++ code into Adobe Flash bytecode.

I have an ancient blogpost from 2012 which compares the three (and where I have been flabbergasted by how well Emscripten actually worked - and this was even before asm.js - the linked demo is unfortunately no longer up):

https://floooh.github.io/2012/10/23/mea-culpa.html

Re: Saying goodbye to asm.js

#58

Post by wren6991 »

dist-epoch wrote: post #47
theultdev wrote: post #2

Sad day. I have a sha256 hasher in asm.js that's faster than any wasm solution.

what's wrong with the built in one? https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...

Requires a secure origin. If you serve a local (but non-localhost) SPA over HTTP then you're blocked from using crypto.subtle.digest. At least, that is one reason I have seen a hand-rolled SHA-256 deployed.

Edit: oh, and it forces async.

Re: Saying goodbye to asm.js

#59

Post by bawolff »

flohofwoe wrote: post #57
tardedmeme wrote: post #50

Earlier quoted context omitted.

What are the key differences between PNaCl and WASM?

There were 3 systems, all with interesting differences. The original NaCl was a 'validated subset' of native CPU machine code (e.g. actual x86 machine code with some instructions and instruction sequences disallowed which would allow to escape the sandbox). The next iteration was P(ortable)-NaCl which replaced the native machine code with a subset of LLVM bitcode, which was then compiled at load time. Unfortunately w…

> The only major advantage of PNaCl vs early WASM was that PNaCl supported shared-memory threading right from the start (this is still knee-capped in WASM because of the COOP/COEP response header requirement).

Presumably that is because PNaCl predated spectre (?)

Re: Saying goodbye to asm.js

#60

Post by ksec »

futune wrote: post #15

So the death of asm.js is upon us? We are drifting away from the timeline of the prophecy: https://www.destroyallsoftware.com/talks/the-birth-and-death... (And to those who haven't encountered this before, I strongly recommend a watch. It may be the greatest tech talk of all time, for certain values of greatest.)

If we substituted war with COVID we aren't that far off as both happened in 2020. We still have to wait till 2035 to see if true.
Post reply on HN