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

On Asm.js

acko.net

Post reply on HN
Print view View original

131–140 of 185 posts

Re: On Asm.js

#131

Post by jfbastien »

pcwalton wrote: post #70
safetydank wrote: post #12

I feel like PNaCl is the technically superior approach - define a stable set of LLVM bytecode and build an interface to run it in the browser. But the uptake is a problem, no other browser maker wants to adopt a big chunk of code controlled by Google, tailored to run optimally in Chrome. So asm.js took a beeline - leveraging existing Javascript machinery for security/JIT and shoehorning a way to run executable LLVM o…

> I feel like PNaCl is the technically superior approach - define a stable set of LLVM bytecode and build an interface to run it in the browser. I don't agree. I think that LLVM bitcode was not really designed for this either [1]. Google has not succeeded in eliminating all of the undefined behavior from LLVM [2]. At least asm.js has a fully defined semantics as specified by ECMA-262. For any hope of interoperability…

I think quoting Dan's email repeatedly is entirely unhelpful, I'd appreciate it if you wouldn't to that. We've actually addressed every single point in Dan's email, talked to Dan repeatedly, and gone beyond what he originally wrote. Sure it has a catchy title, but if you actually read it (and the replies it generated back then), and then compare to what PNaCl does (including discussions on the LLVM mailing list) you'll see that I'm not making things up here. Our IR subset was designed to be portable and stable.

Undefined behavior: it's mostly gone by the time the pexe is created, and our intent is to remove all that's left (e.g. shift by larger than bit width is trivial to fix). I think what's left is mostly non-issues that can't be easily fixed without breakage, so honestly I don't think undefined behavior is any kind of a deal breaker at this point. asm.js still doesn't have canonical NaNs so it's not fully defined ;-)

Note for other readers here: yes C/C++ have undefined behavior, but both PNaCl and asm.js settle on actual behavior before something gets shipped to the browser.

On compile speed: agreed, but I'll take the "it's getting better" approach here (hey, asm.js can do it for runtime!).

I'm not quite sure why having a non-SSA representation would be a requirement. I agree that there are advantages, but I think that's true of both approaches.

Extra bindings and non-Pepper: agreed.

Re: On Asm.js

#132

Post by vanderZwan »

> "And this is really the biggest contradiction of them all. Tons of people have invested countless hours to build these VMs, these new languages, these compilers, these optimizations. Yet somehow, they all seem to agree that it is impossible for them to sit down and define the most basic glue that binds their platforms, and implement a shared baseline for their many innovations. We really should aim higher than a language frozen after 10 days, thawing slowly over 20 years."

It's kind of hard to redesign an airplane in flight, and because of the way the web works, that's a problem that applies to browsers a lot more than some other pieces of software.

Re: On Asm.js

#133

Post by iso-8859-1 »

billforsternz wrote: post #128
adamtj wrote: post #83

Earlier quoted context omitted.

Asm.js is not Javascript. It's native code! It's not a VM bytecode. It's assembly language, and the target machine is your native CPU. It is sandboxed by the browser. It is present on any computer with a browser and Javascript, which is more computers than have a browser and Java plugin, or any other plugin for that matter. Asm.js is less mature that Java, but it will grow up. It is currently supported by more browse…

Outstanding explanation, +1 and thanks for blowing my mind. I find myself sorely tempted to drop everything and throw myself into this exciting new world. One thing that always bothers me with these xyz.js technologies; Is there an explicit or implicit implication that they are actually implemented wholly or partially in an actual file called xyz.js ? In the particular rather than the general; Is there actually an im…

No, asm.js is a subset of JavaScript. So it makes no sense to imagine a single file.

Re: On Asm.js

#134

Post by mraleph »

pcwalton wrote: post #78
diek wrote: post #73

Earlier quoted context omitted.

Just out of curiosity, what is the rationale for a non-SSA bytecode? Is the idea that each implementation will have a platform-optimized SSA format?

SSA tends to result in a larger on-the-wire format since you have more values and phi nodes. Interpretation is slower because you end up with a lot of values unless you do some sort of register allocation, and you have to interpret phi nodes. If and when you need SSA, the dominance frontiers algorithm is fast in practice (as IonMonkey/Crankshaft show).

> the dominance frontiers algorithm

AFAIK V8 does not use dominance frontier based algorithm for SSA construction. It just inserts phis eagerly at loops headers and on forward edges it inserts phis when merge is needed.

Re: On Asm.js

#135

Post by soapdog »

m0a0t0 wrote: post #108
soapdog wrote: post #34

Earlier quoted context omitted.

pwang, there are some people who actually enjoy coding in JS, believe me I am one of them. One cool thing about JS is that you have runtimes for it in computers, tablets, phones, TVs and most current videogames so you can experiment and build stuff for a variety of hardware that no other language can reach as easily (of course you can reach anything with C but it is not easier). Remember all that could be done in JS…

I (not pwang) think it's an abortion of a language because the syntax, scoping and the language as are a whole is a pain to use. Sure, it runs on pretty much everything but that doesn't mean it's suddenly enjoyable to use. The only outstanding feature of JS is that it runs on lots of stuff but it need not be the only one. As you say getting other languages to run is a good thing because those who don't like JS don't…

just to be clear, I don't think that JS reason to be enjoyable is that it runs everywhere. I do enjoy the prototypical inheritance, I like the scope and the language in general. I don't like coffeescript but not due to a technical reason, its about personal taste, I'd rather work in JS. To each their own, the fact that we have a non-proprietary language that is available everywhere is a very good thing.

IMHO most people that do not enjoy JS is because they approach it from a mindset of an OOP programmer. People try to treat it like Java or approach it like a toy language to cook quick jQuery script then they feel frustrated. I am not saying that JS is everyones cup of tea but some people like me enjoy it.

Re: On Asm.js

#136

Post by iso-8859-1 »

derefr wrote: post #115
captainmuon wrote: post #51

Imagine there would be a language that would compile to proper bytecode (not JS), that would run on a standardized platform which is present on almost every computer, that is mature, sandboxed, and actually pretty fast. Oh, wait, that already exists and is called Java. Java has gotten a bad rep lately due to some high-profile drive-by-malware bugs. But if the java codebase would have gotten the same intensive care th…

Instead of the JVM-as-moral-equivalent-to-an-embedded-iframe architecture we ended up with, we certainly could have had . Or , for that matter, with a JVM "engine" sitting sibling to the position Javascript "engines" have in the browser, in terms of access to the DOM and sandboxing provided by the browser-as-platform. That would have made JVM bytecode a wonderful target.

There actually is a Java DOM API that could have been used in applets. It was never widely supported though, AFAIK.

http://www.w3.org/TR/DOM-Level-3-Core/java-binding.html

Re: On Asm.js

#137

Post by iso-8859-1 »

protomyth wrote: post #99
captainmuon wrote: post #51

Imagine there would be a language that would compile to proper bytecode (not JS), that would run on a standardized platform which is present on almost every computer, that is mature, sandboxed, and actually pretty fast. Oh, wait, that already exists and is called Java. Java has gotten a bad rep lately due to some high-profile drive-by-malware bugs. But if the java codebase would have gotten the same intensive care th…

Java's greatest sin for the web was not having the JVM have access to the DOM like javascript.

They tried: http://www-archive.mozilla.org/projects/blackwood/dom/index....

Re: On Asm.js

#138

Post by iso-8859-1 »

adamtj wrote: post #83
captainmuon wrote: post #51

Imagine there would be a language that would compile to proper bytecode (not JS), that would run on a standardized platform which is present on almost every computer, that is mature, sandboxed, and actually pretty fast. Oh, wait, that already exists and is called Java. Java has gotten a bad rep lately due to some high-profile drive-by-malware bugs. But if the java codebase would have gotten the same intensive care th…

Asm.js is not Javascript. It's native code! It's not a VM bytecode. It's assembly language, and the target machine is your native CPU. It is sandboxed by the browser. It is present on any computer with a browser and Javascript, which is more computers than have a browser and Java plugin, or any other plugin for that matter. Asm.js is less mature that Java, but it will grow up. It is currently supported by more browse…

It's assembly language the same way LLVM bitcode is assembly langauge, which means IT ISN'T. It is also represented in text, which means that it is several times larger than it needs to be.

Another problem with Asm.js in practice is that it's used with Emscripten which doesn't define the syscalls you talk about. All the DOM/WebAudio/WebRTC/etc API's have to be redone in Emscripten's headers. GL was easy, because WebGL is so close to EGL and friends. But what about DOM manipulation? Emscripten can't really do this yet.

These two disadvantages happen to be problems solved in PNaCl, which has a compact bitcode (which doesn't pretend to be JavaScript) and a proper API (Pepper).

Re: On Asm.js

#139

Post by iso-8859-1 »

flohofwoe wrote: post #22
safetydank wrote: post #12

I feel like PNaCl is the technically superior approach - define a stable set of LLVM bytecode and build an interface to run it in the browser. But the uptake is a problem, no other browser maker wants to adopt a big chunk of code controlled by Google, tailored to run optimally in Chrome. So asm.js took a beeline - leveraging existing Javascript machinery for security/JIT and shoehorning a way to run executable LLVM o…

From a developer's perspective PNaCl and emscripten is almost the same to work with, the difference is just a couple of hundred lines of wrapper code (less then the differences betwenn iOS and Android wrapper code) and you need to find a higher abstraction layer for threaded code. And if the differences on the surface are so small, and the performance difference is acceptable as well (it is IMHO), I don't really care…

You're just considering the game-perspective, where you don't need anything but GL and sound. What about WebRTC? What about DOM manipulation? You can't do this from Emscripten very well.

Re: On Asm.js

#140

Post by dgregd »

vanderZwan wrote: post #132

> "And this is really the biggest contradiction of them all. Tons of people have invested countless hours to build these VMs, these new languages, these compilers, these optimizations. Yet somehow, they all seem to agree that it is impossible for them to sit down and define the most basic glue that binds their platforms, and implement a shared baseline for their many innovations. We really should aim higher than a la…

> It's kind of hard to redesign an airplane in flight

It is true that IE6 was 5 years in flight. However that has changed. Google replaces Chrome plane each 6 weeks.

JavaScript it is new IE6.

I really would like to see Dart in Chrome stable release. Sometime ago I thought that pure VM, like JVM, would be better. Now I think it is safer to leave scripts loaded as plain text. Just like HTML, CSS. It is hard to guess how whole web ecosystem would work with scripts loaded as bytecode.

Post reply on HN