Blink, PNaCl, And Standards
robert.ocallahan.org
robert.ocallahan.org
But this claim is misleading; the closest the announcement page that is linked from the article [1] comes to supporting it is saying "Once PNaCl is fully released, users will be able to run PNaCl modules on any web page". It does not state an intent to transition PNaCl to this "fully released" state at any particular time in the future, or without standardization.
[1] https://developers.google.com/native-client/announcements (the relevant announcement is the May 15, 2013)
> Once PNaCl is fully released, users will be able to run PNaCl modules on any web page – applications will not need to be deployed through the Chrome Web Store in order to run PNaCl modules.
NaCl has always been enabled only in the Store, and not on the web, while the news in that announcement is that it will be enabled on the web.
If you still think that isn't clear, watch the recent Google IO PNaCl talk, where this is stated as well,
http://www.youtube.com/watch?v=5RFjOec-TI0
If somehow there is a misunderstanding of the intent of both announcements, then I hope Google will clarify that.
"It's in Chrome 29 canary now, hopefully dev channel within a few days. We're shooting for Chrome 30 as our launch."
...when PNaCl is fully released. Which is what they've said for years, that they weren't turning any Native Client on for the web until PNaCl was ready to be "fully released". So that wasn't actually the news.
The actual news was the announcement that PNaCl execution is supported (not that PNaCl will be "fully released") from Chrome 29, which was, at the time, the Canary version of Chrome (its since moved to the Dev channel.) Prior to Chrome 29, the only way to run PNaCl code -- or rather, code that had been generated by the PNaCl toolchain -- in the browser was to run it through another tool which generated regular, architecture-specific NaCl code.
There are plenty of Google people reading HN, hopefully they can quickly confirm things one way or the other.
Per the GoogleIO PNaCL talk, their goal is to have this out with Chrome 30. Even ignoring the impossible time horizon, let's not kid ourselves that there's any will to standardize this thing.
There is also a spec for asm.js and a relatively small API footprint, making it an open standard, albeit one not (yet) sanctioned by ECMA.
asm.js is indeed a smaller API. I guess extreme pragmatism is what has been driving the web, but it can be argued whether that's great or terrible :(
They don't need to use the "use asm" directive. There are many ways to optimize the asm.js style of code.
The important part is that it is not something that needs standardizing. It is a subset of JavaScript, nothing more. The output of other compilers like GWT is also a particular subset of JavaScript, and for years now browsers have optimized in varying degrees for many such subsets.
They want the best game that maximizes the bang for their buck. None of the proposed web solutions do that, although NaCL promises access to more system resources than asm.js does.
But yeah, I'm sure it's just because all code-in-the-browser technologies are doomed and asm.js is too, not because Google's execution was completely incompetent.
Actually, it works outside of the Web Store, but turning it on outside of the CWS is behind a defaults-to-off flag in the Chrome's settings, because Google didn't want NaCl code getting deployed widely on the web, because they didn't want code that would be locked to one architecture being widely deployed when they knew the plan was for PNaCl to be the long-term replacement.
Yes, the fact that Google choose to limit it specifically to prevent it from being widespread in the market contributed to its limited use in the market. But then, since its purpose wasn't to be widely used in the market (hence the restrictions imposed) but to validate technology and components for PNaCl, that's not really that surprising.
Why are all code-in-the-browser technologies doomed? I'd really like an explanation, especially since you have a stake in the game (JSIL).
I think PNaCl was announced (as a long-range project) before ChromeOS was, and I'm certain it was announced before there were any actual Chromebooks, muhc less a concrete disconnect between ARM-based and x86-based Chromebooks.
It was created to solve the problem of high-performance software being tied to a particular native platform, which was clearly an issue for Google's long-term vision of web-as-dominant-platform long before there were concrete issues of different platforms for Chromebooks.
Chrome currently crashes because Chrome can't handle enough variables per context. This is a bug with V8 that is allegedly getting fixed.
It wouldn't surprise me if mobile support is currently minimal to none though; but this is something that can and almost surely will change independent of asm.js optimization support.
(And this is the Unreal demo specifically - smaller projects should be supported by virtually any modern browser* as far as I know.)
* Caveats: IE doesn't support WebGL, etc.
If PNaCl were "just" coupling LLVM bytecode with some defined way of invoking existing browser APIs from within the bytecode, this would be a whole lot easier for browsers other than Chrome to support. But that's not what they're doing, or at least, not yet.
I'm not sure there is a great chance that other browser vendors will adopt LLVM, especially Microsoft. It will basically require them to not only reimplement the native compiler but also the frontend that compiles to LLVM bytecode and any additional SDK tools like a debugger.
Asm.js is a lot easier to implement on every level. It will be served compressed so there wont be a lot of size overhead compared to a bytecode format. If you just use asm.js to call into webGL or audio apis there shouldn't be any big performance difference over using something lower level like PNaCL. Additionally, different browsers may use different optimizations when compiling LLVM code, differing implementations will give different performance characteristics. PNacl is no different than asm.js in requiring that the compiler be optimized.
Both NaCl and PNaCl, except for Chrome Web Store content, are under an off-by-default feature flag.
> then standardize it, then turn it on by default. Apparently Chrome follows this process for HTML/CSS features but not for PNaCl or DRM.
Except that there is nothing but speculation, at least nothing cited in the source article, supporting the idea that Google isn't following that path with PNaCl.
Besides that, Blink is the rendering engine, Blink != Chrome. To get Chrome, you have to add in V8, NaCL, codecs, and a bunch of other stuff.
I see the promises to which Blink commits itself as being disjoint from Chrome. After all, there are lots of Chrome-only APIs, like Chrome extensions, Chrome sync, Chrome packaged apps, etc.
All those things are not enabled for web content. They are additional things that Chrome does, but they do not change how websites are built - they do not change the toolkit of things that web content has available to it.
If you add an extension to Chrome as a user, or use Chrome's syncing, that's fine. You're modifying the browser in a way that you want. But if Chrome adds a feature to web content that is nonstandard, then it risks fragmenting the web: Some sites will use it, and they will only work in Chrome. That's what the standards process is meant to avoid.
The plan announced from fairly early in NaCl's lifecycle was that when PNaCl was ready to be "fully released", it would be enabled for all web pages. The announcement this article points to merely restates that. It does not -- contrary to the article's treatment -- announce imminent plans to "fully release" PNaCl, or state that that release will happen without standardization. It simply assumes that that is the case.
It may be true, it may not, but it certainly is incorrect to state that that is what was announced in the announcement which the article links to and bases its entire string of complaints on.
If Google only enables PNaCl on the web if/when it is on track to become an industry-accepted standard, then everything is ok from my perspective - I think you agree to that?
I don't see how I could disagree with your description of what would be okay from your perspective. I'm actually not particularly concerned one way or the other; it certainly isn't as if Google hasn't pivoted to whatever the standard solution is in the past even when they've previously embraced (and enabled-by-default) a solution that ended up failing to become the standard. If Google was trying to push developer-focussed tooling as a business model and so was invested in its proprietary solutions winning, that would be different, but AFAICT there business model around improving web performance is to enable people to do more in the browser without relying on external code for the underlying OS, and if asm.js addresses that problem its just as good for them as it would be if PNaCl did it.
Part of the incentive to fork was to avoid having to maintain support for multiple JS engines in the core project. I don't think that means that Blink requires V8 so much as that Blink's support for JS engines (compared to pre-split WebKit's) no longer includes explicit support for the engine used by Safari (whose name I can't remember) as part of the source tree, and presumably will over time be more tightly adapted to the needs of V8.
This would seem to mean it will progressively become more difficult to build a Blink-based browser using a different JS engine.
will there be more compilers targeting PNaCl, or asm.js?
Otherwise said, as a compiler writer, would you rather write a compiler that works in all browsers, and which needs no tools because of how simple the output is, or a compiler which targets just one browser, with a complex output to target?
You can write a game with fragmented performance, cross your fingers and hope it runs everywhere and try to hit the largest market possible, or, you can develop for a more predictable platform, target a smaller market, but potentially gain more revenue with less development cost.
The idea that someone is going to just cross compile to asm.js and poof, the game will work everywhere is a pipe dream. This attitude is likely to draw public ire and bad reviews as people who happen to have VMs which won't optimize it as good as Firefox, get unpredictably bad performance. It's Android fragmentation made even worse.
The reality is, you are going to either target NaCl on Chrome, asm.js on Firefox, and native C/C++ on Android NDK or iOS, and you're going to have to maintain and certify four different versions in order to get best experience.
Not much different than trying to target a PS3, XB360, and Wii with a multiplatform title.
If you look at modern game platforms, both on mobile, and on console/desktop, they are leveraging not just GPUs, but multi-core CPUs. If you look at Ars's evaluation of asm.js (http://arstechnica.com/information-technology/2013/05/native...) lack of SIMD and multi-threading is a huge performance hit. SIMD can be fixed (e.g. what Dart did), but shared memory model in JS with concurrency primitives would be a radical change to the semantics of JS, so I don't see it happening.
In short, it's a nice dream that you can write once and run everywhere high performance JS, the reality is, it isn't going to help major game developers and they will still need per-browser, per-platform extensive testing and tuning.
End users don't care. When I buy a game from a store, I expect it to run at 30fps with no janks minimally. This is one reason why iOS and consoles extract great performance from platforms that have lower specs than competitors, because a fixed target offers more opportunities for optimization.
I love the idea of write once run anywhere, but I think it's the wrong model for high performance cpu hungry games where you want to maximize overall system performance.
[1] https://github.com/RiverTrail/RiverTrail/wiki
[2] http://smallcultfollowing.com/babysteps/blog/2012/01/09/para...
[3] http://smallcultfollowing.com/babysteps/blog/categories/pjs/
> The reality is, you are going to either target NaCl on Chrome, asm.js on Firefox
is an oversimplification as well. Many asm.js codebases already run well on Chrome, and that will continue to improve, for the same reasons that all browsers are now fast at SunSpider, Octane, Kraken, etc.
But again, sure, if you need full performance everywhere, you may need to target multiple platforms and not just one. Some games might need to do that, but not all.
Possibly not; Google certainly likes the things they come up with, but it wouldn't be the first time that they spent lots of effort behind one approach but switched to back another approach that solved the same problem that others championed because it was better positioned for standardization; Google's interest in native-like performance on the web are more about the functionality than the mechanism.
For example, 1200% slower in Mandelbrot rendering with asm.js vs OpenMP C code.
Or is it possible that PNaCL and Pepper can be implemented on top of Blink?
Do we know for sure that Blink itself is violating any of these principles, to merely expose PNaCL / Pepper in Chrome?
It's quite refreshing to see Google trying to offer a viable alternative that's far more general in nature, and far more technologically-sound than its competitors.
This contrasts heavily with what Mozilla is trying to do with asm.js. Their approach, unfortunately, is nothing more than an atrocious hack. Instead of doing things properly, they just maul JavaScript into a form that isn't as horrible to work with, from an optimization standpoint. However, this is clearly inferior to using a proper instruction set, bytecode, or intermediate representation.
The worst part, though, is that asm.js further entrenches JavaScript. This is going in the opposite direction of where we ought to be going. We need browsers that offer a far more general runtime. JavaScript would merely be one among many other languages targeting such a runtime, rather than being an integral part of it like we see with asm.js.
Java, Flash, and Silverlight were insecure platform specific NPAPI plugins that make it easy to p0wn users machines.
PNaCl uses PPAPI that together are designed from the ground up to be portable and secure. PPAPI provides the only APIs NaCL apps can call. They are cross platform so you write 1 plugin and it runs on Linux/OSX/Windows. Compare to NPAPI where the plugin has to be custom for each platform and calls into the OS directly unrestricted.
Here's how Flash player looks like: [2]
And here's Chrome's track of record: [3] (unfortunately, there's no good way to filter out NaCl defects)
[1] http://www.cvedetails.com/vulnerability-list/vendor_id-26/pr...
[2] http://www.cvedetails.com/vulnerability-list/vendor_id-53/pr...
[3] http://www.cvedetails.com/product/15031/Google-Chrome.html?v...
The issue being, nobody should be developing anything for it publicly until at least 2 competing implementation have been created. But people don't seem to care about that for some reason...