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

71–80 of 88 posts

Re: Bringing Asm.js to Chakra and Microsoft Edge

#71

Post by bzbarsky »

Sephr wrote: post #45
TazeTSchnitzel wrote: post #18

Earlier quoted context omitted.

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 u…

Pepper is not proprietary, it's completely open source.

Being open source doesn't help other people to adopt the code if it has hard dependencies on other parts of Chrome.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#72

Post by cwyers »

JoshTriplett wrote: post #56
vesinisa wrote: post #52

Earlier quoted context omitted.

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

But supporting NaCl without Pepper means no existing NaCl apps will work, so you have to somehow hope that NaCl apps without Pepper will be written.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#73

Post by bzbarsky »

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…

> I can't AOT compile, by the nature of JavaScript.

Firefox AOT compiles asm.js. All you have to do is validate it (like you would any other bytecode) and then you can in fact AOT compile it. You don't even need a full JS parser, since asm.js only uses a subset of the syntax allowed in JS.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#74

Post by acqq »

JoshTriplett wrote: post #69
vesinisa wrote: post #61

Earlier quoted context omitted.

The level of "convoluted" depends on which level you want to look at. The asm.js spec is dead-simple, almost purely "mathematical" if you like. But if you require that whatever GCC/clang would have outputted for a specific C file is the exact same binary code that gets executed in the browser, then yes - you are not getting that. But then again, asm.js just - on a high level - specifies the primitive low-level constr…

It's more that I'd like browsers not doing an absurd amount of unnecessary work and overhead. Leaving aside opinions on JavaScript as a scripting language for humans, it's not a sensible intermediate format for compiled binaries. It happens to work as a (very impressive) hack.

Even if it doesn't appear to be for those who don't consider the whole context it's a reasonably effective intermediate format. The current success of it among the vendors proves that.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#75

Post by detrino »

acdha wrote: post #6
teacup50 wrote: post #5

Earlier quoted context omitted.

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

There's no need to be disparaging – NaCL is more ambitious but asm.js has a backwards compatibility path. Both are valid engineering decisions, particularly since it's really easy to imagine a world where if NaCL delivers some major benefits the same toolchain could generate both for a seamless upgrade.

IOW, sometimes a hack can be a valid engineering decision.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#76

Post by JoshTriplett »

cwyers wrote: post #72
JoshTriplett wrote: post #56

Earlier quoted context omitted.

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

But supporting NaCl without Pepper means no existing NaCl apps will work, so you have to somehow hope that NaCl apps without Pepper will be written.

Have to start somewhere. In the interim, people will use it to build compatibility layers for the Pepper APIs, such as a better pepper.js (https://trypepperjs.appspot.com/).

Re: Bringing Asm.js to Chakra and Microsoft Edge

#77

Post by Sephr »

TazeTSchnitzel wrote: post #51
Sephr wrote: post #47

Earlier quoted context omitted.

> 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

No, it doesn't. Where in IodineGBA do you see any hand-written asm.js code?

Here's are some quotes from the author of that very library:

"asm.js requires a style of coding only compilers can output. A person writing actual asm.js code by hand would need to be insane as asm.js code required style of coding is horribly disorganized"[1]

"Unfortunately asm.js requires one giant array to put things on. No one in their right mind codes like that by hand."[2]

1: https://github.com/taisel/IodineGBA/issues/16#issuecomment-2... 2: https://github.com/taisel/IodineGBA/issues/16#issuecomment-2...

Re: Bringing Asm.js to Chakra and Microsoft Edge

#78

Post by pjmlp »

flohofwoe wrote: post #30
dicroce wrote: post #2

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

I would really love to see Native Client on Android as alternative to the dreaded Android NDK, and I really don't understand why this hasn't already happened, it's so incredibly obvious. Just give us the ability to deploy and run a PNaCl executable directly as normal Android application, and without all the Java and JNI shenanigans. The Pepper API has a lot more to offer than what's exposed through the NDK headers, a…

I would just be happy if they offered the same as iOS and WP, access to OS APIs to all languages.

However I bet the Android team only added the NDK forced by upper management, given how little care they give to it.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#79

Post by s-macke »

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?

I did for my emulator jor1k. Take a look:

https://github.com/s-macke/jor1k/blob/master/js/worker/or1k/...

Handwritten asm.js code. Around 10 hours or porting time.

Re: Bringing Asm.js to Chakra and Microsoft Edge

#80

Post by s-macke »

TazeTSchnitzel wrote: post #22
jlongster wrote: post #9

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…

> 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 big for comprehending performance. Related, and you've sort of mentioned this: having your browser be able to validate asm.js is useful for web developers, because…

Exactly. When I ported my software manually, it was the warning messages that helped. After that I can remove the "asm.js" statement and achieve almost the same performance (around 80% of max speed).

asm.js runs currently through an foreign function interface in Firefox, which makes calling the asm.js code slower.

Post reply on HN