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

Bringing Asm.js to Chakra and Microsoft Edge

blogs.windows.com

Post reply on HN
Print view View original

51–60 of 88 posts

Re: Bringing Asm.js to Chakra and Microsoft Edge

#51

Post by TazeTSchnitzel »

Sephr wrote: post #47
TazeTSchnitzel wrote: post #16

Earlier quoted context omitted.

> asm.js represents LLVM bytecode No, emscripten compiles asm.js from LLVM IR, but asm.js itself is more like a portable bytecode for a 32-bit register machine. > The programmer sees errors when generating the asm.js, not when executing it. Why would that be the case? The point of asm.js is so browsers can optimise it. It doesn't matter what your tooling thinks, in the end what matters is whether browsers accept it.…

> Actually, some people do [write asm.js code by hand] Who?

People wanting high performance. For example, Grant Galitz's IodineGBA had some portions in asm.js https://github.com/taisel/IodineGBA

Re: Bringing Asm.js to Chakra and Microsoft Edge

#52

Post by vesinisa »

JoshTriplett wrote: post #50
dicroce wrote: post #2

Come on Google! Support asm.js in Chrome.... Give up on Native Client.... Even Microsoft is doing Asm.js now....

While I'd like to see asm.js implemented for compatibility, I greatly prefer native code over compiling to a JavaScript subset in the hopes of getting something vaguely resembling the original code back. I understand why other browsers don't implement the Pepper API, because it's highly Chrome-specific; however, I'd like to see other browsers implementing the native-code sandbox, at least.

Asm.js has several benefits over NaCl. It's readily compatible with just about every browser in the market, and manufacturers just need to add some asm.js-specific optimizations to their JS runtime to fully unleash its execution power (but Chrome too already runs asm.js code very fast with just its generic JIT optimisations).

Secondly, it's based on a self-contained open source spec that constitutes a logical subset of another widely-supported open spec (ECMAScript) - no convoluted, versioned APIs coordinated by large, possibly competing and mutually incompatible engineering efforts. The asm.js spec is actually so simple it fits on a single web page: http://asmjs.org/spec/latest/

Yet it pretty much manages to achieve all that NaCl does by being also forwards-compatible with all the DOM-based extensions like HTML5 without needing any additional APIs (many asm.js demos for example bind to WebGL - this does not require any additional "asm.js API", as the browser's existing WebGL implementation suffices)

Re: Bringing Asm.js to Chakra and Microsoft Edge

#53

Post by azakai »

teacup50 wrote: post #41
pcwalton wrote: post #31

Earlier quoted context omitted.

The choice isn't between "support HTML/CSS/JS" and "don't support HTML/CSS/JS". No Web browser can drop backwards compatibility. We haven't even been able to get rid of backwards compatibility for much worse things than CSS, such as , because sites you need to use (such as Hacker News) won't update their markup to use CSS for layout. asm.js is attractive because it is a small extension to the Web platform, so the ove…

Meanwhile, platforms that don't even try to wedge their technology into the HTML/CSS/JS universe have better applications.

In some ways they do, but they are also nonstandard, with the downsides that that brings. Neither overall approach is perfect, it's good that we have a combination of both in our field.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#54

Post by ygra »

teacup50 wrote: post #40
flohofwoe wrote: post #12

Earlier quoted context omitted.

In the end there's not much difference between PNaCl and asm.js (see for yourself: http://floooh.github.io/oryol/ ). Both compile down to 'immutable' machine code, either via JIT or AOT compilation, both call into the same browser API backends, both are based on LLVM (actually PNaCl and emscripten use the same modified LLVM frontend) both have somewhat similar restrictions what APIs can be called in threads, the only…

If I want to implement NaCL execution, I only need to support a (sane) bytecode and a reasonable "syscall" surface (pepper -- and only if I want to support pepper. I may not want to for things like server-side sandboxing). I can AOT compile a complete binary, and can run on (just about) any target. If I want to implement asm.js, I have to implement a full JavaScript JIT (if I want decent performance). This is Hard. I…

Asm.js bypasses the JIT, using AOT compilation directly to machine code (after verification). You just need a JS parser, not the JIT. At least not if you only want to support asm.js.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#55

Post by pcwalton »

teacup50 wrote: post #41
pcwalton wrote: post #31

Earlier quoted context omitted.

The choice isn't between "support HTML/CSS/JS" and "don't support HTML/CSS/JS". No Web browser can drop backwards compatibility. We haven't even been able to get rid of backwards compatibility for much worse things than CSS, such as , because sites you need to use (such as Hacker News) won't update their markup to use CSS for layout. asm.js is attractive because it is a small extension to the Web platform, so the ove…

Meanwhile, platforms that don't even try to wedge their technology into the HTML/CSS/JS universe have better applications.

We're talking about Web browsers. Technologies that try to integrate into Web browsers specifically but don't have a good compatibility story with the platform haven't had a lot of success.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#56

Post by JoshTriplett »

vesinisa wrote: post #52
JoshTriplett wrote: post #50

Earlier quoted context omitted.

While I'd like to see asm.js implemented for compatibility, I greatly prefer native code over compiling to a JavaScript subset in the hopes of getting something vaguely resembling the original code back. I understand why other browsers don't implement the Pepper API, because it's highly Chrome-specific; however, I'd like to see other browsers implementing the native-code sandbox, at least.

Asm.js has several benefits over NaCl. It's readily compatible with just about every browser in the market, and manufacturers just need to add some asm.js-specific optimizations to their JS runtime to fully unleash its execution power (but Chrome too already runs asm.js code very fast with just its generic JIT optimisations). Secondly, it's based on a self-contained open source spec that constitutes a logical subset…

As mentioned in my previous comment, NaCl and Pepper are not the same thing. Browsers could support NaCl without committing to support Pepper.

> Secondly, it's based on a self-contained open source spec that constitutes a logical subset of another widely-supported open spec (ECMAScript) - no convoluted

I'm going to have to stop right there. asm.js is a lot of things, but "not convoluted" is certainly not one of them. asm.js involves compiling native code to JavaScript in the hopes that browsers will translate it back to some semblance of the same native code.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#57

Post by cpeterso »

pcwalton wrote: post #39
dman wrote: post #37

Earlier quoted context omitted.

Do you think Google could be persuaded to contribute PNaCL as an open standard?

There were beginnings of talks to get cross-vendor consensus on Pepper (which would be a prerequisite to any standardization attempt of PNaCl) in 2010: https://mail.mozilla.org/pipermail/plugin-futures/2010-April... The general consensus among non-Google browser vendors was that just using the existing browser APIs was a more desirable approach than Pepper. Since then, Pepper has remained a Chrome-specific technology…

Could Google add NaCl support to Firefox with an add-on?

Re: Bringing Asm.js to Chakra and Microsoft Edge

#58

Post by cpeterso »

teacup50 wrote: post #5
dicroce wrote: post #2

Come on Google! Support asm.js in Chrome.... Give up on Native Client.... Even Microsoft is doing Asm.js now....

Why? asm.js is a hack relative to NaCL.

Does NaCl have any advantage over asm.js other than implementation aesthetics?

Re: Bringing Asm.js to Chakra and Microsoft Edge

#59

Post by pcwalton »

teacup50 wrote: post #40
flohofwoe wrote: post #12

Earlier quoted context omitted.

In the end there's not much difference between PNaCl and asm.js (see for yourself: http://floooh.github.io/oryol/ ). Both compile down to 'immutable' machine code, either via JIT or AOT compilation, both call into the same browser API backends, both are based on LLVM (actually PNaCl and emscripten use the same modified LLVM frontend) both have somewhat similar restrictions what APIs can be called in threads, the only…

If I want to implement NaCL execution, I only need to support a (sane) bytecode and a reasonable "syscall" surface (pepper -- and only if I want to support pepper. I may not want to for things like server-side sandboxing). I can AOT compile a complete binary, and can run on (just about) any target. If I want to implement asm.js, I have to implement a full JavaScript JIT (if I want decent performance). This is Hard. I…

> If I want to implement NaCL execution, I only need to support a (sane) bytecode

What makes asm.js "insane" by comparison? The syntax?

There's a bytecode for asm.js too if you want it. https://github.com/kripken/emscripten/wiki/Emterpreter

> If I want to implement asm.js, I have to implement a full JavaScript JIT (if I want decent performance). This is Hard.

Writing a compiler that gets decent performance for LLVM is also Hard. (Go look at the size of the x86 backend alone in LLVM.) If you were writing an asm.js engine from scratch with no support for any JS other than Emterpreter bytecode, asm.js is probably even a bit easier than supporting PNaCl, due to the lack of types and no SSA. But honestly, the amount of work you need to parse a different bytecode doesn't matter much compared to the amount of work you need to do to write a good compiler, which you would have to do either way.

> One of these technologies brings the entire bloated browser technology stack along with it, and one finally cleans up that bloat.

Except that, as I mentioned above, you're never going to "clean up" the stack. HN, which you're using to post this comment, hasn't even moved beyond the and tags; what chance is there for browsers to drop all that technology when many sites haven't even adopted CSS1? The difference isn't between "HTML + CSS + JS" and "alternative stack", it's "HTML + CSS + JS + asm.js" and "HTML + CSS + JS + alternative-stack-that-duplicates-the-features-of-the-previous-three". You have to take that into account when talking about the complexity calculus.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#60

Post by TazeTSchnitzel »

cpeterso wrote: post #57
pcwalton wrote: post #39

Earlier quoted context omitted.

There were beginnings of talks to get cross-vendor consensus on Pepper (which would be a prerequisite to any standardization attempt of PNaCl) in 2010: https://mail.mozilla.org/pipermail/plugin-futures/2010-April... The general consensus among non-Google browser vendors was that just using the existing browser APIs was a more desirable approach than Pepper. Since then, Pepper has remained a Chrome-specific technology…

Could Google add NaCl support to Firefox with an add-on?

They could, but why would they?
Post reply on HN