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

71–80 of 185 posts

Re: On Asm.js

#71

Post by ozten »

ma2rten wrote: post #40

I agree, an Unreal Engine compiled to javascript doesn't make sense. It would make much more sense if it were compiled to some kind of bytecode (like NaCl). That will ultimately give you better performance, less loading time, etc. However, maybe there are some libaries which compiled to asm.js are small enough that they can still run in a browser without asm.js support, e.g. an compression or an encryption algorithm…

> I agree, an Unreal Engine compiled to javascript doesn't make sense.

That demo runs at 60 FPS in my browser, allowing me to casually spend more money on more video games. Your objections seem ideological, as opposed to perf benchmarks, distribution improvements or other quantifiable terms.

Can you expand on why it doesn't make sense?

Re: On Asm.js

#72

Post by jerf »

ma2rten wrote: post #40

I agree, an Unreal Engine compiled to javascript doesn't make sense. It would make much more sense if it were compiled to some kind of bytecode (like NaCl). That will ultimately give you better performance, less loading time, etc. However, maybe there are some libaries which compiled to asm.js are small enough that they can still run in a browser without asm.js support, e.g. an compression or an encryption algorithm…

"It would make much more sense if it were compiled to some kind of bytecode (like NaCl)."

asm.js is a bytecode. The ".js" is misleading; it's not wrong, but it's misleading. asm.js is actually a bytecode specification that has a syntax that overlaps (but is not a superset of) Javascript, and the semantics of the bytecode overlaps (but is not a superset of) Javascript, but it is not Javascript. It's a bytecode that happens to have a serialization to a Javascript-compatible syntax.

Do not be fooled by the surface appearance and the name. Look at what it does. It is a bytecode, just one with a bizarre serialization. (And as a result of that serialization, the most literal interpretation of "bytecode" admittedly doesn't quite work, but it's a bytecode in every way except for a literal fixed-length code of bytes.)

Re: On Asm.js

#73

Post by diek »

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…

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?

Re: On Asm.js

#74

Post by acdha »

pwang wrote: post #23
flohofwoe wrote: post #17

What I miss in all those discussions regarding JS, asm.js and PNaCl is that the web is the best software distribution platform we have by a huge margin, this is really its overwhelming killer-feature. All the user needs is an URL. No "downloading", no installation, no special user permissions, no app shops, no gate keepers, no walled gardens, and everything is automatically multi-OS and multi-CPU-architecture. The we…

Have you actually shipped a complex codebase to the web? There are a TON of major issues which are just as bad: Old problem: Downloading New problem: Downloading. Large JS apps have to asynchronously load potentially very large codebases, every time the app is loaded Old problem: Installation New problem: Installation. What if the user has NoScript? AdBlock? Mobile Opera vs. Mobile Safari vs. Chromium vs. IE. Old pro…

Having worked on both traditional and web projects, I disagree with “just as bad”. In every case, what you're talking about is easier to solve on the web than off-line.

Downloading: easily solved with browser caching. This is still faster than trying to, say, walk a very non-technical user through downloading and opening an installer.

Installation: not an issue for most users. NoScript/AdBlock are a small percentage of users for most sites and since most of the web breaks that way, many of them have learned to recognize when their local system broke something.

Permissions: the problem in both cases are the gatekeepers and every single “new problem” you listed was also an old problem of equal or greater impact. If the gatekeepers are determined and unaccountable, they'll block everything either way. The difference is that the web side has a better security model and is more likely to be open because you're following a known precedent – Google, Amazon, Facebook, etc. have created enough demand that even the most fascist IT departments allow HTTPS. This is not the case for the traditional desktop model where every local software install is considered independently.

Re: On Asm.js

#75

Post by phaker »

jfbastien wrote: post #52
phaker wrote: post #47

Earlier quoted context omitted.

> So asm.js took a beeline - leveraging existing Javascript machinery for security/JIT and shoehorning a way to run executable LLVM on top of it. A big advantage of asm.js over PNaCl is that it's not LLVM. On the other hand PNaCl is very tightly coupled to LLVM. Any time I find myself checking if a some $feature is available in PNaCl, the discussion revolves around what LLVM can or can't do and how LLVM does it, see…

I think you're conflating frontend and back end. As they currently exist both asm.js and PNaCl frontends are LLVM, if just because it's a good C/C++ solution to parse and optimize. The backend is indeed an LLVM subset as of today for PNaCl and not asm.js, but it's a very restricted subset because the complex bitcode definition LLVM has was pruned a lot for PNaCl, both to distance it from LLVM churn and to make it imp…

> As they currently exist both asm.js and PNaCl frontends are LLVM (...)

I don't think it's fair to call LLVM a frontend for asm.js just because LLVM can compile to asm.js. By that logic LLVM is also a frontend for x86. That doesn't mean anything. Asm.js is a platform, LLVM is a compiler, it's expected that LLVM can target it asm.js, so can other compilers. Hopefully both asm.js and PNaCl will be targeted by multiple compilers not using LLVM.

> It is definitely possible to implement a non LLVM back end for PNaCl.

Anything's possible. Reimplementing PNaCl from scratch (custom everything) obviously will take much more work than implementing it on top of LLVM. However i honestly think that there would be a large chasm between PNaCl on top of LLVM and PNaCl on top of any other virtual machine. And this is a problem.

EDIT:

I think i'm too focused on LLVM, sorry about that. What I should have written but didn't: PNaCl is hard to reimplement, and not only because it's a large project. For example iirc Chrome doesn't explicitly support the asm.js pragma and doesn't try to be compliant, but it already performs many of the optimizations from the its spec and the Chrome team appears receptive of changes that make this sorta support better. If things continue that way, soon it won't matter if Chrome supports the pragma or not. I.e. right now Chrome supports (say) 10% asm.js and eventually it could support up to 90% with no problems. On the other hand can Firefox implement PNaCl piecemally? What would a 10% reimplementation of PNaCl look like? I think even a 90% or anything else short of a full implementation will not be interoperable.

Re: On Asm.js

#76

Post by CmonDev »

kayoone wrote: post #42
fidotron wrote: post #26

This discussion is missing the simple point that the web is rapidly gaining all the flaws that Flash used to have, without the nice (for some) editing environment. The web really isn't suited for app development at all, as the native mobile markets have demonstrated, while the viability of it as a document delivery platform diminishes every time the content gets hidden behind a massive layer of scripts.

> The web really isn't suited for app development at all, as the native mobile markets have demonstrated Mobile markets have also demonstrated tightly controlled walled gardens, where fast iteration, platform independence and openness have been replaced with strict rules and controls by the market controlling entities. Is that really a direction you want to move in? The web as a platform is still lacking in terms of…

"openness" - I want to use my favourite language and familiar environment to produce high-performance apps with good UX. The only advice I have heard from "open web" guys so far is to use transpilers (thanks very much). Xamarin and Mono seem to be the only organization that tries to give developers what they are asking for. It's a shame that they have to charge, but it's a reality.

Re: On Asm.js

#77

Post by CmonDev »

Touche wrote: post #56
calt wrote: post #55

Earlier quoted context omitted.

But what the poster is really thinking of is the JVM. We now have Scala, Clojure, and others that target the JVM as a platform.

The JVM doesn't run on Android or iOS, and never will. That's a huge chunk of users they can't touch, but the web can.

Surely there is a Scala for it? Alternatively use Mono and C#/F#.

Re: On Asm.js

#78

Post by pcwalton »

diek wrote: post #73
pcwalton wrote: post #70

Earlier quoted context omitted.

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

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

Re: On Asm.js

#79

Post by CmonDev »

endemic wrote: post #49

This article neatly sums up my thoughts on asm.js. On the one hand, I really like the fact that Mozilla is doing a lot to promote Javascript (which I usually enjoy programming in). On the other, asm.js basically destroys any reason to write Javascript. For someone interested in web-based gaming, it really discourages me from investing in Javascript-based tools, since the future _won't_ be hand-written Javascript. It'…

Pick a language you like (on its merits), not the one that is ubiquitous.

Re: On Asm.js

#80

Post by CmonDev »

jerf wrote: post #72
ma2rten wrote: post #40

I agree, an Unreal Engine compiled to javascript doesn't make sense. It would make much more sense if it were compiled to some kind of bytecode (like NaCl). That will ultimately give you better performance, less loading time, etc. However, maybe there are some libaries which compiled to asm.js are small enough that they can still run in a browser without asm.js support, e.g. an compression or an encryption algorithm…

"It would make much more sense if it were compiled to some kind of bytecode (like NaCl)." asm.js is a bytecode. The ".js" is misleading; it's not wrong, but it's misleading. asm.js is actually a bytecode specification that has a syntax that overlaps (but is not a superset of) Javascript, and the semantics of the bytecode overlaps (but is not a superset of) Javascript, but it is not Javascript. It's a bytecode that ha…

How many CPU cores can said "bytecode" utilize at a time? Does it make a difference between value and reference types for optimal performance?
Post reply on HN