61–70 of 185 posts
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.
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…
> asm.js's compatibility with existing Javascript engines gives it the best chance of adoption. This is the key. With asm.js the worst case is slow, not totally broken.
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…
Bytecode doesn't mean smaller download or faster startup, or necessarily better performance. It might, but you need numbers to show that.
In practice, right now startup is faster on asm.js than PNaCl, and vice versa for execution speed, but in both cases the differences are not large. Compare for yourself:
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'…
Each of those is good for some use cases, but none is good enough for everything. Just like we have many languages for native development and web servers and so forth.
Earlier quoted context omitted.
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.
Aren't all Android apps running the JVM?
AFAIK (I'm not a java developer), any language that can target the JVM can target Dalvik.
Earlier quoted context omitted.
> asm.js's compatibility with existing Javascript engines gives it the best chance of adoption. This is the key. With asm.js the worst case is slow, not totally broken.
Which is why Google should have a PNaCl javascript implementation, so that it degrades gracefully like asm.js but the fast case is faster.
Earlier quoted context omitted.
Usually I'm debugging a native "desktop build" of the code in VStudio or XCode since 99% of the bugs are not emscripten specific. But having said that: browsers are becoming a really good debugging platform as well. emscripten can emit source maps, which kinda lets you directly debug the C++ code in the browser (not as fluent as in a native debugger yet, since only code lines are mapped, not variables, but the potent…
Thanks! I was thinking specifically of bugs that occur in the browser target but not the native build. Given your experience that "99% of the bugs are not emscripten specific", I'm very impressed with how emscripten can retain the semantics of the native code across the conversion and optimisation process. Obviously thats what any compiler does, but in this case the target environment seems to me to be much more comp…
It compiles for a restricted subset of javascript. There are no threads (there are no threads in javascript itself in the first place), and it works around memory management (it sets up big typed arrays, and memory allocations are slices of that)
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…
Additionally, the JVM security model has a much larger surface area than JS, allowing for all kinds of things JS doesn't, which, I'm going to guess is why security has been worse.
Earlier quoted context omitted.
Aren't all Android apps running the JVM?
They run Dalvik, which is Googles proprietary VM. Its similar to the JVM in purpose, but it is supposed to avoid Oracle's patents and has a few specializations for mobile. AFAIK (I'm not a java developer), any language that can target the JVM can target Dalvik.
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 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 between browsers, that's critical. Things like order of iteration of properties were once left undefined by ECMA-262, but pages began to rely on Netscape's behavior and other browsers had to reverse engineer what Netscape did. Eventually they were added to the standard. Likewise, without all the undefined behavior removed from PNaCl, anyone who wanted a separate implementation of PNaCl would have to reverse engineer what Chrome did.
There is also the issue of compilation speed: asm.js was designed to compile quickly by a backend that doesn't do much optimization. LLVM, on the other hand, was optimized for -O2, which compiles much less quickly. PNaCl at -O0 is far worse than either V8 or OdinMonkey. On the Web, compilation speed matters a lot.
I think an actually technically superior approach, if backwards compatibility were not a concern, would involve:
1. A from-scratch, untyped, non-SSA bytecode, basically an isomorphism to asm.js. All operations would have fully defined semantics. This would yield fast compilation without the JavaScript syntax and would be amenable to multiple backends, like LLVM or V8.
2. A mechanism for providing a C binding to WebIDL-based Web APIs. This would eliminate the necessity of Pepper and would mean that any new Web APIs would instantly be available to native code.
PNaCl, unfortunately, is neither of these. asm.js isn't either, but I think it's closer to this ideal than PNaCl is.
[1]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437...
[2]: http://www.chromium.org/nativeclient/pnacl/stability-of-the-...