Blink, PNaCl, And Standards

http://robert.ocallahan.org/2013/05/blink-pnacl-and-standards.html

by thristian • 13 years ago

94 67 13 years ago

robert.ocallahan.org

pjmlp• 13 years ago

IE is dead, God save Chrome!

tim_hutton2• 13 years ago

Does NaCl/PNaCl have a future now we've seen what Emscripten/ASM.js can do?

dochtman• 13 years ago

It certainly seems unlikely, but I guess it depends on how fast asm.js can get.

tim_hutton2• 13 years ago

Now only 1.3x slower than native on one large-ish benchmark (box2d): http://youtu.be/qrf9ONmtXbM (I love the comparison he makes to evolution at the end. Yes, the process may give ugly creatures sometimes but they work.)

notatoad• 13 years ago

it has a future as long as firefox is the only implementor of asm.js and chrome/ium is the only implementor of PNaCl.

dragonwriter10• 13 years ago

> Does NaCl/PNaCl have a future now we've seen what Emscripten/ASM.js can do?

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.

micro_cam• 13 years ago

Am I the only one who feels like locking into a standard for something like this without first developing and testing an implementation would be a mistake?

wmf3• 13 years ago

There is a process for that: You prototype the feature 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.

dragonwriter10• 13 years ago

> You prototype the feature under an off-by-default feature flag

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.

lucian19003• 13 years ago

Asm.js is no more an open standard than PNaCl. While I'm sure others disagree, PNaCl is much cleaner in design and with more predictable performance. It's the one I'd like to see win.

LamaOfRuin• 13 years ago

Not really the same. Anything that implements standard javascript will be able to run asm.js code just fine, even if they don't implement the possible optimizations. The same isn't true for NaCL.

lucian19003• 13 years ago

But it'll be too slow to be useful for anything, so it's not quite so different.

AndrewDucker• 13 years ago

Asm.js at least has a specification that's not dependent on any particular implementation:

http://asmjs.org/spec/latest/

pcwalton2• 13 years ago

V8 is implementing optimizations for asm.js, as highlighted in Google I/O. (It is ignoring the "use asm" directive, though.) So there is some measure of buy-in from other browser vendors.

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.

wslh3• 13 years ago

But there is a penalty in performance with solutions like asm.js. Am I right?

lucian19003• 13 years ago

V8 is fixing bugs they had that caused asm.js-style JavaScript to be slower than it needs to be. I doubt they'll honour the "use asm" directive in the near future.

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 :(

wslh3• 13 years ago

I have the same hope.

rst• 13 years ago

asm.js is a well-specified subset of things that are already pretty much standardized. PNaCl adds a whole lot of new stuff that has not been subject to community review, like (for instance) the entire input processing and rendering API. And it isn't yet clear which quirks are meant to be standard, as opposed to whatever happen to be accidents of the initial Chrome implementation.

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.

cpleppert2• 13 years ago

PPAPI itself is a Chrome only api at the moment. I'm really concerned about using a plugin api defined by its C/C++ behavior as some kind of standard. So we not only have the DOM apis but also another class of APIs that have their own quirks.

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.

cromwellian6• 13 years ago

NaCL was already part of Chromium prior to Blink, I hardly see the huge difference between NaCL and PNaCl in this regard.

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.

espadrine2• 13 years ago

It is my understanding that you cannot use Blink without V8. I believe it was part of the incentive to fork. Am I wrong?

dragonwriter10• 13 years ago

> It is my understanding that you cannot use Blink without V8. I believe it was part of the incentive to fork. Am I wrong?

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.

pcwalton2• 13 years ago

NaCl was never enabled for Web content, only for the Chrome Web Store. PNaCl is going to be enabled for Web content.

dragonwriter10• 13 years ago

> NaCl was never enabled for Web content, only for the Chrome Web Store. PNaCl is going to be enabled for Web content.

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.

azakai6• 13 years ago

> Chrome extensions, Chrome sync, Chrome packaged apps

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.

VikingCoder• 13 years ago

Do we know for sure that Blink itself needs to support PNaCL / Pepper?

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?

espadrine2• 13 years ago

What matters to me as a developer is this:

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?

cromwellian6• 13 years ago

If you are a game developer, it doesn't much matter. Do you target a market of 500+ million Chrome users, or 2 billion web users, or 900 million Android users, or 500 million iOS users?

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.

kibwen• 13 years ago

I agree with your assessment that "write once, run anywhere" will always be beholden to the lowest common denominator when it comes to games that try to push the limits of performance. However, with regard to your statement "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", it isn't entirely hopeless. Intel's Rivertrail[1] and Mozilla's Parallel JS[2][3] efforts might not pan out as well as they expect, but at no point has either entity thrown up its hands and declared the situation as impossible as you imply.

[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/

neeee• 13 years ago

Support for asm.js in Chrom{e,ium} was announced at Google I/O, though.

azakai6• 13 years ago

I agree that write once run anywhere is never quite so simple, but

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

dragonwriter10• 13 years ago

The key premise of this article is unsubstantiated by the provided link. The article states, "Unfortunately, Google has recently announced that they will expose Portable Native Client (PNaCl) --- and by extension, the Pepper APIs --- to all Web pages"; all the article's complaints are based on this description and the assumption that it will be exposed to all web pages without first being standardized.

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)

azakai6• 13 years ago

Google's announcement says

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

munificent• 13 years ago

In case you're curious, the relevant bit is around here: http://www.youtube.com/watch?v=5RFjOec-TI0&feature=playe....

"It's in Chrome 29 canary now, hopefully dev channel within a few days. We're shooting for Chrome 30 as our launch."

dragonwriter10• 13 years ago

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

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

msbarnett• 13 years ago

> It does not state an intent to transition PNaCl to this "fully released" state at any particular time in the future, or without standardization.

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.

RRRA• 13 years ago

Is it only being developped as the native side for Chrome OS or is it really planned as a all around web binary running thingie?

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

wmf3• 13 years ago

There aren't two competing implementations of Flash or iOS, but some people made millions developing on those platforms.

programminggeek• 13 years ago

How is NaCL support any different than allowing Java Applets on a page, or Flash, or Silverlight?

wmf3• 13 years ago

Java, Flash, and Silverlight were NPAPI plugins that could work in multiple browsers. NaCl uses PPAPI that's only supported in Chrome.

greggman• 13 years ago

Here, Let me fix that for you

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.

zobzu• 13 years ago

We're deep in the extend phase and start to see some extinguish attempts.

PommeDeTerre• 13 years ago

Extinguishing JavaScript would actually be a very beneficial thing to do.

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.

Blink, PNaCl, And Standards

Related Stories