11 ms·
Google launches Portable Native Client
- bdfh42 13y agoSo sort of .NET for Chrome? Cool. I like the language agnostic approaches we are seeing these days.
- pritambaral 13y agoDoes this abstraction of native OS environments mean lesser supported platforms like Linux will see more apps? Of course, only if the app dev decides to port it to PNaCl. One thing I am concerned about is, since PNaCl is essentially yet another platform, how Google (or anyone) is going to manage the host of supporting tools required. Tools like dependency management, libraries, process control etc. By the way, Google has already proven their "platform-creation" skills with Android.
- geofft 13y agoI think NaCl is already portable across different OSes on the same architecture, since it exposes its own API. The new part of PNaCl is that you don't have to recompile for each target architecture. Among other things, if they push hard for this for desktop developers on the Chrome App Store, then suddenly they have a large number of things that work on Chromebooks without demanding that developers recompile.
- pritambaral 13y agoYou are right. But even with NaCl, the original question remained: would a game dev compile an NaCl app for Linux (even though code changes weren't required.) PNaCl eliminates a dev's actions to recompile.
- dragonwriter 13y agoNaCl -- even the non-portable form -- doesn't require recompiling for different OS's. It only requires recompilation for different machine architecture (x86 vs. ARM.) PNaCl removes the need to compile different x86 vs. ARM binaries for NaCl.
- eliben 13y agoThis is correct. A more significant difference is, however, that NaCl is restricted to the Chrome web store, while PNaCl is available on the open web. You can have a PNaCl module your web app, on your website/domain today, and Chrome 31 (and later) will run it.
- dragonwriter 13y agoThe two are tied -- the reason Google didn't enable NaCl outside of the Web Store is to avoid architecture-tied NaCl code from becoming common on the web when PNaCl was in the pipeline.
- knotty66 13y agoI did not realise this. That is awesome.
- cbhl 13y agoI'm under the impression that once a game dev compiled for NaCl x86/x86_64 at all, it ran on all of the Chrome binaries on x86/x86_64, i.e. Mac, Windows, Linux, and Chromebook. There are already a few games on NaCl, like Don't Starve[0] that work on x86/x86_64-based chromebooks. They just don't run on ARM-based chromebooks -- which is one of the incentives for PNaCl. IIRC, NaCl could only run in Chrome Web Apps precisely because it was platform-dependent. It looks like PNaCl will also allow ActiveX/Flash-style embedding. [0] http://www.dontstarvegame.com/ http://www.dontstarvegame.com/
- jmpe 13y agoThis could also be a fertile pasture for distributed computing on the fly. Suppose you have a website that attracts 1k visitors per day on chrome, how many MIPS could you harvest? Could you let them mine bitcoins or fold proteins in the background without attracting attention?
- eliben 13y agoHow is this different from existing client-side JavaScript code? PNaCl is significantly faster than JS, but conceptually it's similar - you can run code on the user's machine.
- jmpe 13y agoThe "significantly faster" is your answer. A 10 second visit on JS vs PNaCl is a whole new game. Edit: to elaborate: do a simple simulated annealing on a 200x200 array in JS - it's measured in seconds on my laptop. I wrote a program in JS that did this (image segmentation, fg/bg seperation for recognition) and abandoned it because of speed issues.
- azakai 13y agoJS should not be that slow in my experience. Do you still have the code to your benchmark somewhere? Perhaps you ran into a performance bug that we can file for the relevant browser(s).
- jmpe 13y agoI have it somewhere, also still have that laptop. It wasn't a benchmark but a poc for an algorithm. I did some serious optimization when I wrote it. There was a "best practices" for V8 that shedded some light on the background of JS variable allocation, I followed it and got a serious boost. Also did lookup tables instead of runtime math with exp/log functions. But in the end: hit several worst case images that took more than 12s, which was a gap that couldn't further be reduced through optimization. But you're absolutely right, I should redo it in PNaCl.
- Procrastes 13y agoMy guess is this gives Google a clear migration path away from Java to a unified Chrome OS for phone, tablet, notebook etc. PNaCl could coexist with Android apps until Google finally phases Java out.
- efuquen 13y agoAm I missing something here, when was this about Java and phasing it out of Android? I don't think that's a likely plan but if you have any evidence to the contrary I would love to see it. Java is pretty pretty central to Android to think that it's somehow going to be "phased out", that would be more like destroying the entire platform. I know everyone loves to hate on Java, but I'm always amazed by some of the wacky things people say ...
- _random_ 13y agoMaybe a new virtual machine along with a high-level language will magically materialize out of thin air? GoVM perhaps, that was secretly being developed all this time?
- munificent 13y ago> Maybe a new virtual machine along with a high-level language will magically materialize out of thin air? Dart[1] is high-level, and has a clean, fast VM implementation. Also, ARM support[2]. [1] https://www.dartlang.org/ https://www.dartlang.org/ [2] https://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/runtime/vm/assembler_arm.h https://code.google.com/p/dart/source/browse/branches/bleedi...
- Procrastes 13y agoI really don't hate Java at all. It's had a generally beneficial impact in all sorts of places. But I wonder with the change-over in leadership for Android[1] if we aren't seeing signals that Google wants to consolidate all of its apps under Chrome. One possible motivation is that they may not want to leave a core technology under the control of Oracle forever. 1. http://thenextweb.com/google/2013/07/17/google-is-holding-a-press-event-with-android-and-chrome-chief-sundar-pichai-on-july-24/ http://thenextweb.com/google/2013/07/17/google-is-holding-a-...
- egeozcan 13y agoOne day, I will be able to compile my golang apps to work on browsers without losing considerable performance, multiple threads and concurrency. That day, I'll be very happy.
- eliben 13y agoYou'll be interested in this project, then: http://blog.awilkins.id.au/2012/12/go-in-browser-llgo-does-pnacl.html http://blog.awilkins.id.au/2012/12/go-in-browser-llgo-does-p... It's important to emphasize that PNaCl is a platform. We currently provide front-ends for C and C++, but nothing prevents you from writing your own, for your own language (or an existing one). As long as you emit PNaCl bitcode, Chrome will run it for you. The PNaCl bitcode has a definition here - https://developers.google.com/native-client/dev/reference/pnacl-bitcode-abi https://developers.google.com/native-client/dev/reference/pn... - and we're working on making it more precise.
- Touche 13y agoWorking on a PNaCl spec or did I miss it and that was released too?
- eliben 13y agoCan you clarify what you mean by "spec"? The bitcode ABI document I pointed to is the spec of the IR used by PNaCl. The official documentation covers the Pepper APIs which are PNaCl's interface with the browser and DOM.
- adamb_ 13y agoIs this how Google plans to bridge the JS performance gap to get web apps running at "native" speeds?
- dragonwriter 13y agoIt's one of several approaches in that direction. Google's not particularly shy about pursuing multiple approaches in parallel for important priorities.
- mtgx 13y agoThey sure took their sweet time. Didn't say they it was supposed to arrive like a year ago? NaCl should've worked on ARM from day one.
- Refefer 13y agoHow does PNaCl differ beyond intermediate representation from asm.js? They both seem to focus on providing cross compiling into a browser environment with the latter already having compatibility across the entire set of javascript interpreters. What does it offer that hasn't somewhat been solved?
- Filligree 13y agoUsing the LLVM toolchain, thus probably better performance and language support? I'd like to see the benchmarks before assuming that, but if this leads to letting me use Haskell in the browser, I'll be all over it.
- mccr8 13y agoMost asm.js is generated using Emscripten, which is also based on LLVM. I guess the backend optimizations will be different.
- eliben 13y agoThe PNaCl bitcode can serve as the output of any compiler. Google currently provides toolchains for C and C++, but folks have been working on Go ports, Lua, Python etc. Haskell, in fact, already has a LLVM backend so porting that to emit PNaCl bitcode should not, in theory, be overly hard.
- sanxiyn 13y agoDoesn't Haskell's LLVM backend depend on custom LLVM calling convention to do tail call? Does PNaCl bitcode support tail call?
- mccr8 13y agoAt the moment, PNaCl supports pthreads-style threads and asm.js does not. Also, Native Client, but apparently not PNaCl, supports SIMD, while asm.js does not. Of course, both PNaCl and asm.js are evolving, so asm.js may be able to eventually support those features somehow, and PNaCl may get additional features. Some information about features PNaCl supports are here: https://developers.google.com/native-client/dev/faq https://developers.google.com/native-client/dev/faq
- josteink 13y agoI'm so glad to see Google finally make a mobile version of Active X. Seriously though. Stuff like this is what made me quit Chrome. Too much non-standard Google nonsense in what is supposed to be a standards-compliant web-browser. It just feel wrong.
- eliben 13y agoAs opposed to Active X, PNaCl runs on all major OSes (desktop and ChromeOS so far, not mobile yet) and on all major CPU architectures. Active X, AFAIR, was portable in true Henry Ford manner - running everywhere as long as it's a Wintel box with Internet Explorer.
- igreulich 13y agoMarginally off topic, but calling a A Windows box a Wintel box implies that there is functional, if not fundamental, difference between Windows/Intel machines and Windows/AMD machines. There isn't. I ran all the same Active X controls on my WAMD box you did on your Wintel. Or am I missing something about the Windows/Intel combination? Anecdote: I switched to Mac (Mintel? Mactel?) in 2007. Prior to that, my 486DX4 100 (circa 1995) was the last Intel I used. </offtopic>
- drdaeman 13y agoI believe the term was coined this way because x86 was originally invented by Intel. Although, indeed, Intel lost the control when AMD introduced AMD64. :) But this is really getting offtopic.
- rsanders 13y agoFor a while there were non-x86 Windows NT boxes. In fact, there are again with Windows RT. Wintel versus WinDEC or Wintanium or WinMIPS, for example, though there was never enough market shire for any of those to justify a neologism.
- apetrovic 13y agoFrom Wikipedia: Wintel is a portmanteau of Windows and Intel, referring to personal computers using Intel x86 compatible processors running Microsoft Windows. http://en.wikipedia.org/wiki/Wintel http://en.wikipedia.org/wiki/Wintel
- eliteraspberrie 13y agoI can't be the only one who doesn't think this is cool. From an application security point of view, PNaCl -- and the general trend of packing everything into browsers -- is not good. The first rule of security is to keep things small and simple. A browser with a built-in compiler is no longer a browser. If Google had its way, phones would just be dumb bootloaders for operating systems downloaded on the fly from their cloud.
- eliben 13y agoDo note that PNaCl uses Native Client as a base. Native Client is a very secure sandbox that's been out in the wild for some time, had security contests run against it and has in general proven itself to be very secure. The PNaCl translator (backend of the compiler) runs within a NaCl sandbox itself, so nothing in the Native Client security model is compromised.
- _random_ 13y agoSo JS shouldn't be JIT-ed as well?
- enneff 13y agoYou have it backwards. The PNaCl thing actually makes it more realistic to actually install a "Web App" inside Chrome and use it independent of an internet connection. The browser is lagging well behind Android and iOS in terms of user experience. Efforts like PNaCl and asm.js help to restore the balance. All browsers include compilers already, by the way.
- _random_ 13y agoVery good news! A lot of developers don't like JavaScript and HTML. Google started to listen. I really hope the rest of big players will follow the suite.
- RRRA 13y agoEmbrace, Extend, Extinguish... now in version 2.0 beta!
- mistercow 13y agoWhat I'm really looking forward to with this is not PNaCl on the web, but PNaCl as a way of writing high performance portable native apps by using a Chromium wrapper. I'm very excited by the idea of being able to write an app that "just works" across a ton of platforms using JS and HTML5, with compiled code sprinkled in for performance-critical portions. Projects like AppJS have been working toward this already, but with PNaCl, a big missing piece can finally be filled in.
- RRRA 13y agoCould we just standardize and complete what is missing from Firefox OS's proposed standard: WebAPI ?
- mistercow 13y agoI am unaware of any part of WebAPI which is geared toward native code performance. And cool as it is, asm.js is never going to have the same potential that PNaCl has. Primarily this falls under one reason: multi-threading. Web Workers are a step in the right direction, but they're incredibly limited by design because of the inability to share memory across threads. The requirement of copying data across threads means that parallelizable tasks involving small operations over large chunks of data often don't benefit from using Web Workers. Unfortunately those tasks make up a large percentage of situations where parallel processing is useful.
- felipe 13y agoHave you considered XULRunner?
- mmastrac 13y agoMy problem with PNaCl is that it's basically defined an a LLVM module (snapshotted as the implementation an LLVM module today), but with a bunch of limitations of what you can't do ("The only calling convention supported by PNaCl bitcode is ccc - the C calling convention", "PNaCl bitcode does not support visibility styles."[1]). I understand not wanting to re-invent the wheel, but I don't think we should bake a bunch of LLVM-isms into something that should be designed to run on browsers for the next 20 years. Basically, the whole PNaCl spec feels way too half-baked for something that should be a standard -- sort of how I felt about embedded SQLite into web standards as the spec and reference implementation (WebDatabases, shiver). I prefer asm.js's approach over PNaCl. I'd also be happy if the browser vendors came up with a new bytecode from scratch as well, designed for the web. [1] https://developers.google.com/native-client/dev/reference/pnacl-bitcode-abi https://developers.google.com/native-client/dev/reference/pn...
- lambda 13y agoAnd the Web SQL initiative failed, for just this reason; SQL itself does not define enough to write portable SQL, so they just had to say "well, SQL as implemented by SQLite as of this particular version", and that was pretty much a non-starter. Web SQL had even got a little more buy in from multiple vendors (Safari, Chrome, and Opera), but due to the problems with it Mozilla and Microsoft refused to implement it. The same is likely to happen to PNaCL. It will probably survive for a while in Chrome, as it may be useful for writing ChomeOS specific apps, but it will never be adopted by any of the other browser vendors. ASM.js runs just fine in other browsers, the only difference is that they don't implement the stricter subset and same optimizations as Firefox does, so it's a lot more likely to catch on, as people can write cross-platform ASM.js right now.
- rybosome 13y agoCorrection: you can write cross-platform PNaCl code; there's a project called pepper.js that compiles the PNaCl application using emscripten. To quote the GitHub README: "Native Pepper applications can now be run in Chrome, Firefox, Internet Explorer, Safari, and more." This leaves them in roughly the same place; write code that will be heavily optimized for one of the browsers, then include a compatibility layer that will make it runnable in all of the others. Without making an argument as to which underlying approach is better, I see no clear upper-hand from the perspective of compatibility. What somebody needs to do now is define another language that compiles to both PNaCl and asm.js-suitable languages, and offer a deployment mechanism that correctly uses one or the other when in a browser-optimizable situation. Nothing beats too many standards like adding another standard to unify them. ;)
- haberman 13y agoI think this and asm.js are both extremely cool. I look forward to the competition this will inspire, and the improvement of both approaches as a result. I say this honestly not sure which one I personally think will be better in a year or two. I often think of software as "walking a path." What I mean by this is that there are often different approaches to the same problem, and these start out as just basic, undeveloped ideas. But put smart people on it (and I have high regard for both the Google and Mozilla engineers on these projects) and let them refine these ideas over time and you'll learn more about all of the consequences, the fundamental strengths and limitations, of these approaches. I first had this thought when working at Amazon. I remember hearing an off-hand comment about how S3 and Dynamo, both Amazon projects that started around the same time, started with very different consistency goals (Dynamo: very weak, S3: very strong) but as the details were fleshed out, ended up coming towards each other and both became more moderate. I think that's extremely valuable knowledge, because it can become part of the body of resources that any future designer can look at. Whenever you have an idea, chances are other people have "walked the path" of that idea (or some variant of it) before, and reading about their experience can help you see down the road and anticipate what practical problems you'll run up against. You might have an idea for how to improve on what the previous designers did, but by reading about their experience you can save yourself a lot of the work they already did. For this reason, I look extremely forward to watching these two projects evolve and compete, and in doing so, to learn more about the fundamental properties/tradeoffs of this design space.
- jkn 13y agoThanks for bringing some positivity to the debate. PNaCl and asm.js are timely and they are technically very different. It will be interesting indeed to see how it goes from here.
- BlackAura 13y agoThe introduction of pepper.js is particularly interesting. It's a re-implementation of (some of?) the Pepper API on top of the standard web APIs, so you can write stuff for PNaCl but also compile it using enscripten for other browsers. Which means you could target both PNaCl and asm.js at the same time. That also means it's effectively encouraging asm.js adoption, which might give Apple and Microsoft enough of a kick to optimize that. Google seem to already be planning on it (they added some asm.js tests to their Octane benchmark). It also might be useful if, at some point, other browsers want to implement a PNaCl runtime. One of the main sticking points (aside from the use of LLVM bitcode, which is not something LLVM was designed for) was that it requires the Pepper API, which is huge, and duplicates much of the existing web APIs. Google have the spare engineers to do that, but Mozilla certainly doesn't. A reverse of that would be useful too - an implementation of the standard web APIs on top of Pepper, so you could re-target an asm.js app to PNaCl. Or some kind of tooling that lets you transparently target both. Maybe we'll see some kind of convergence thing going on? Wouldn't surprise me too much if they started evolving slightly towards one another. I think it's probable that asm.js will eventually get some kind of compact bytecode representation, especially if it can be implemented as a shim to allow it to load in existing browsers.
- andyl 13y agoAnother brick in Google's walled garden. I will never use it.
- buremba 13y agoIt seems Atwood was right. http://www.codinghorror.com/blog/2007/07/the-principle-of-least-power.html http://www.codinghorror.com/blog/2007/07/the-principle-of-le...
- eonil 13y agoIf I want to write a portable C++ GUI app, this codebase would be a good free option to fork. Anyway running in Chrome product sandbox is nothing attractive. For the web, I would bet on Emscripten + asm.js which is a lot more portable.
- pjmlp 13y agoQt, wxWidgets, Gtkmm, Juce
- eonil 13y agoGPL requires you to PAY your freedom to choose license for the freedom to access source code. So it's trade of freedoms, not free.
- pjmlp 13y agoWhat has GPL to do with the listed frameworks? Not all of them have GPL licenses, plus it is only fair to pay people for their work.
- eonil 13y agoMaybe here's a miscommunication. I meant no price, no need to trade my copyright, and maybe you're meaning freedom to access source code - strict GPL meaning. Also I haven't argue payment itself is bad. Go back and read carefully my reply. Fair trade is good, and I would gladly pay for good product.
- pjmlp 13y agoI still don't get your point. You mentioned targeting the browser with C++ for portable applications. For me the place of native code is at the OS level, and the browser should be left alone for plain interactive documents, instead of Frankenstein VM. Hence my short reply with a list of native frameworks. It has nothing to do with licenses.
- talles 13y agoNaCl is not new, I remember seeing about it I guess over a year ago? What really happened, they reached a stable version or something?
- frozenport 13y agoDoes Google use this internally? For example are they using it as an optional faster frontend to their apps?