Live data from Hacker News

Bringing Asm.js to Chakra and Microsoft Edge

blogs.windows.com

11–20 of 88 posts

Re: Bringing Asm.js to Chakra and Microsoft Edge

#11

Earlier quoted context omitted.

Why? Last I heard, Chrome is going long on their JIT and trying to get it to automatically squeeze the same performance out of asm.js code as the others, without special shortcuts. These "real" optimizations can then seamlessly be applied outside of asm.js code. Isn't that something that benefits us all? I'm happy they're trying, at least.

While you are correct that the actual runtime speed in theory should be able to be achieved with the JIT, there are other advantages to officially supporting asm.js. One of the main things is ahead-of-time (AOT) compilation which compiles the asm.js code directly to assembly immediately after it's parsed. This gives you predictability (you literally get warnings in the console if it couldn't compile), which is really…

asm.js represents LLVM bytecode, which is already behind the compilation step. The programmer sees errors when generating the asm.js, not when executing it. Whether it is then executed by a JIT or not is, in this case, irrelevant.

I absolutely agree there are advantages to taking the asm.js -> LLVM bytecode shortcut (cue every single benchmark showing FF on top). But compiler warnings are not one of them.

EDIT: To clarify: my point is that this is not classical compilation, but rather "interpretation of the generated code". Nobody writes asm.js by hand, no matter how it is executed. If there are errors in there, there is something seriously wrong with the tooling, and when the errors show up will be the least of your worries. Comparable to errors in a .jar file or a .pyc---this is just not something we need to be generally concerned with.

EDIT2: I don't mind the downvotes but if I'm wrong, please explain so at least I understand. Otherwise I won't learn.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#12
post #5
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.

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 real difference is whether a pthreads-style threading model is supported or not (PNaCl does, asm.js does not, but work is underway at Mozilla to implement a true pthreads-style model via SharedArrayBuffer).

Re: Bringing Asm.js to Chakra and Microsoft Edge

#13
post #7

So, will they add Opus support for audio tag too?

Speaking of which, wasn't Microsoft supposed to add WebRTC/ORTC support in its new browser, too? I don't think I've heard anything about it in the recent official announcements other than last year's rumors.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#14
post #2

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

I want less things emulated via Javascript and more stuff done directly via native code. Everything that is built on top of HTML/JS/CSS is basically a hack that is trying to emulate much better native platforms and it sucks. Why advocate to stay there? Let's go in the other direction in my opinion.

On the other hand, for the first time in history, you have true "write once run everywhere". I can take my native C/C++ GL demos that normally run on the desktop, compile them to asm.js, distribute them via a simple URL, and users just click on a link and run the demo on every OS. No download and installation, no browser warnings about dangerous executables, no virus scanner scare popups. Compare this with iOS, where I need to be a certified Apple developer, need to sign my all my code, and can only distribute through the app store (and since it's only small graphics demos without real use, the gatekeepers would never let them through).

Re: Bringing Asm.js to Chakra and Microsoft Edge

#15
post #2

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

Why? Last I heard, Chrome is going long on their JIT and trying to get it to automatically squeeze the same performance out of asm.js code as the others, without special shortcuts. These "real" optimizations can then seamlessly be applied outside of asm.js code. Isn't that something that benefits us all? I'm happy they're trying, at least.

Why does it have to be mutually exclusive? It's more work, but Google has more $$$ to spend than say Mozilla.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#16

Earlier quoted context omitted.

While you are correct that the actual runtime speed in theory should be able to be achieved with the JIT, there are other advantages to officially supporting asm.js. One of the main things is ahead-of-time (AOT) compilation which compiles the asm.js code directly to assembly immediately after it's parsed. This gives you predictability (you literally get warnings in the console if it couldn't compile), which is really…

asm.js represents LLVM bytecode, which is already behind the compilation step. The programmer sees errors when generating the asm.js, not when executing it. Whether it is then executed by a JIT or not is, in this case, irrelevant. I absolutely agree there are advantages to taking the asm.js -> LLVM bytecode shortcut (cue every single benchmark showing FF on top). But compiler warnings are not one of them. EDIT: To cl…

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

> Whether it is then executed by a JIT or not is, in this case, irrelevant.

No, whether it is executed by a JIT is quite important. asm.js is a subset that browsers can validate and then compile ahead-of-time. If your code is failing validation and falling back to the usual JavaScript mode, there's a big performance penalty, and your code isn't asm.js-compliant!

> Nobody writes asm.js by hand, no matter how it is executed.

Actually, some people do. It's not the nicest of languages, but there are some people who do.

But even if you don't, what if you're using buggy or outdated tooling producing incorrect output? What if you're targeting a browser that doesn't support some new asm.js feature? You need to know if your code didn't validate!

Re: Bringing Asm.js to Chakra and Microsoft Edge

#17
post #2

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

I want less things emulated via Javascript and more stuff done directly via native code. Everything that is built on top of HTML/JS/CSS is basically a hack that is trying to emulate much better native platforms and it sucks. Why advocate to stay there? Let's go in the other direction in my opinion.

Why does this sentiment always get downvoted? (Not just here on HN, but on other forums and in the real world as well)

Edit: to those downvoting me (classic), when I left this comment the parent was at -2 or -3 votes and at the bottom of the page.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#18
post #5

Earlier quoted context omitted.

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

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…

There's a very big difference. NaCl and PNaCl don't use the standard, multi-vendor web APIs. They use a proprietary single-vendor (Google) API, Pepper. This not only makes implementation by competitors difficult, it's needless duplication of effort (why maintain multiple APIs for the same thing?).

Also, both are based on single-vendor, single-implementation technology. NaCl used actual native code, so if you're not using x86-64 or ARM, too bad! And PNaCl uses LLVM, so there's only one implementation.

Compare this to asm.js. It's a strict subset of ECMAScript/JavaScript, which has several high-quality implementations, and is portable across platforms. It uses the existing standard web APIs, which also have several high-quality implementations.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#19
post #5
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.

This kind of remark is getting pretty childish. On some level, all technology is black magic or "hacks". With a little bit of understanding, you learn all "hacks" are petty card tricks.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#20

Earlier quoted context omitted.

While you are correct that the actual runtime speed in theory should be able to be achieved with the JIT, there are other advantages to officially supporting asm.js. One of the main things is ahead-of-time (AOT) compilation which compiles the asm.js code directly to assembly immediately after it's parsed. This gives you predictability (you literally get warnings in the console if it couldn't compile), which is really…

asm.js represents LLVM bytecode, which is already behind the compilation step. The programmer sees errors when generating the asm.js, not when executing it. Whether it is then executed by a JIT or not is, in this case, irrelevant. I absolutely agree there are advantages to taking the asm.js -> LLVM bytecode shortcut (cue every single benchmark showing FF on top). But compiler warnings are not one of them. EDIT: To cl…

You're misunderstanding jlongster's point, or putting too much emphasis on the compiler warning part.

When you load some asm.js code in Firefox and it compiles without errors or warnings, you then know for sure your code was fully compiled and you will not see parsing/compilation happening half-way through a game frame. This means it's slightly easier to reason about the performance of your code.

AFAIK, with the Chrome strategy, you have to think about JIT compilation kicking in at any point, which is unpredictable and completely out of your control.

Post reply on HN