Google's Native Client project to accelerate Web applications just got a lot more real--and a lot more ambitious.
Browsers today come with increasingly powerful engines to run programs written in JavaScript, but those programs must be translated laboriously into the native instructions a computer understands, typically making them much slower than the software that runs directly on the operating system. Native Client is an attempt to bridge those worlds, letting code downloaded over the Web run fast and natively.
A year and a half ago, when Google announced Native Client, the open-source project could run only 32-bit software for x86 processors. On Wednesday, Google announced fulfillment of plans to build support for Native Client for 64-bit x86 processors and ARM processors. That was technologically challenging, but significant because those are the chips that are in most of today's PCs and most smartphones, respectively.
But that's not all. The company also disclosed a plan to shield Native Client programmers from the concerns of specific processors altogether, a move that harkens back to Sun Microsystems' "write once, run anywhere" philosophy for Java. Native Client is called NaCl for short, and Google details the new Portable Native Client variation, called PNaCl and pronounced "pinnacle," in a paper (PDF).
"PNaCl should make it easy for developers to write their application once and be confident that it will execute, with identical behavior, on every platform supported by Native Client," the Google researchers said in the paper. In other words, instead of producing different Native Client modules for each different processor, a Web developer could produce a single PNaCl module that would run on any processor for which Google or some other organization provided the necessary support.
PNaCl is still in prototype form, but its processor flexibility means Google is positioning it as the main way programmers can use the technology. "We'd like PNaCl to be the main way people deploy these applications," said Brad Chen, Google's engineering manager of Native Client, in an interview.
That's important because Google wants the technology to work broadly across the whole Web. Lacking that, developers likely would either ignore Native Client or only use it on various islands, "potentially leading to fragmentation of the Web," the researchers said.
But Native Client holds the potential to dramatically change today's perception of Web applications as useful but not very sophisticated or snappy. That could pay big dividends in the move to cloud computing, especially when combined with new Web technology arriving in a new generation of faster browsers.
"We can build applications on the Web that are every bit as good as native applications," said Linus Upson, engineering director for the Chrome browser and Chrome OS, in a December interview, speaking of Google's aspirations for Native Client and a related Google technology called O3D for accelerated 3D graphics on the Web.
And there's evidence to back him up. In a new paper on Native Client's broader processor support (PDF), Google said its technology slows execution times down 10 percent on 64-bit x86 chips and 3 percent on ARM chips. That's not a major hit, especially compared to the execution speed of JavaScript.
Native Client software modules running on a machine have limited abilities--essentially the permissions granted to JavaScript, not to ordinary native applications that run on the operating system. Think of them as a way to bring some new muscle to what Web applications can do.
NaCl software could work in conjunction with other Web application infrastructure to enrich programming possibilities. Scalable Vector Graphics (SVG), Canvas, WebGL, and O3D could provide slicker interfaces. Local storage on the PC will let Web applications work with data that's stored on the computer without having to rely constantly on the network. Other new work will let Web applications deal with Webcams and potentially other hardware attached to a computer.
Google)
Note that Native Client is built into Chrome and the browser-based Chrome OS. Google's operating system for Netbooks is due to arrive later this year, and also remember that Google makes the browser in its Android operating system that typically runs on ARM-based smartphones.
In short, even if nobody else adopts Native Client, Google can make it relevant. Google's position as a significant browser maker, Web application developer, and mobile operating system creator means it has the ability to singlehandedly break much of the chicken-and-egg impasse that often limits adoption of new technology.
For example, Google Spreadsheet is limited today by what can be done with JavaScript. Tapping into native computing power could open the application to heavy-duty statistical calculations or faster sorting, for example.
For Google, though, success will mean others use it, too. To that end, Google is discussing standardization of Native Client and O3D with other browser makers, though not at the expense of actually moving ahead with the work. "We're excited about getting people using the system, but it's quite early still, so there isn't much to say right now about standardization," Chen said.
Making Native Client standard, though, is a tougher matter. There, Google will have to win over allies with their own priorities, and the present Web standards agenda is already jam-packed with work.
But broadly, cloud computing is catching on, and Google has agreement on the vision if not the details. Even though Microsoft--the browser maker whose Windows and Office franchise means it has the most to lose from the migration of applications to the Net--is working on a faster, more relevant Internet Explorer geared for Web applications and on bringing Office to the Web.
PNaCl essentially breaks the Native Client execution process into two parts to attain its portability.
The first part is the conversion of the human-written software into an intermediate state called "bitcode." This represents a low-level version of the program, but not the lowest level, the machine code that a computer actually understands and executes.
This bitcode is the portable part. To actually execute it, the second part of the process, a specific module adapted for each processor architecture translates the bitcode into the machine code that can run. This is where the security checks are run to ensure the software doesn't perform any of the forbidden instructions.
So far, Google plans translators for 32-bit and 64-bit x86 processors and for ARM, and the Google researchers said it should be "straightforward to support other popular general-purpose CPUs in future.
"Part of the point of this design is that we take portability very seriously," Chen said. "The only ISAs [processor instruction set architectures] we're working on now are ARM, x86-32 and x86-64. There are a lot of architectures and architecture variants in the world, and we surely won't be able to support all of them, but we will eagerly support credible outside efforts to support other platforms."
Translation adds overhead, though, Chen said, it's not yet clear how much.
"We think we can make the translation time small compared to download times, and I'm hoping the typical effective delay will very small, much less than a second," Chen said. "Apart from translation, we think the runtime impact of PNaCl will be negligible."
The other paper concerns the move to the other processors. Doing so was tricky, because the initial NaCl technology relied on a feature of 32-bit x86 chips that restricted a computing process to a particular area of memory, making it harder for it to escape its bounds in a way that could be used in a computer attack.
Looking for a substitute for this memory segmentation technique that would work on 64-bit x86 and ARM chips, Google opted to use something called software fault isolation that it initially thought would make the system too sluggish.
"The overhead of fault isolation using these techniques is very low, helping to make SFI a viable approach for isolating performance critical, untrusted code in a Web application," Google researchers said in their paper. However, with Google's approach, one perk of 64-bit x86 software, the ability to use large amounts of memory, isn't available: it's bound by the 32-bit chip limit of 4GB. That's still plenty for most applications today, though.
The upshot, in Google's eyes, is that Native Client is closer to prime time, and not just for PCs.
"These results indicate that a browser running on virtually any modern computer or cell phone could run a fast, performance-sensitive Native Client application," Chen said.
Browsers today come with increasingly powerful engines to run programs written in JavaScript, but those programs must be translated laboriously into the native instructions a computer understands, typically making them much slower than the software that runs directly on the operating system. Native Client is an attempt to bridge those worlds, letting code downloaded over the Web run fast and natively.
A year and a half ago, when Google announced Native Client, the open-source project could run only 32-bit software for x86 processors. On Wednesday, Google announced fulfillment of plans to build support for Native Client for 64-bit x86 processors and ARM processors. That was technologically challenging, but significant because those are the chips that are in most of today's PCs and most smartphones, respectively.
But that's not all. The company also disclosed a plan to shield Native Client programmers from the concerns of specific processors altogether, a move that harkens back to Sun Microsystems' "write once, run anywhere" philosophy for Java. Native Client is called NaCl for short, and Google details the new Portable Native Client variation, called PNaCl and pronounced "pinnacle," in a paper (PDF).
"PNaCl should make it easy for developers to write their application once and be confident that it will execute, with identical behavior, on every platform supported by Native Client," the Google researchers said in the paper. In other words, instead of producing different Native Client modules for each different processor, a Web developer could produce a single PNaCl module that would run on any processor for which Google or some other organization provided the necessary support.
PNaCl is still in prototype form, but its processor flexibility means Google is positioning it as the main way programmers can use the technology. "We'd like PNaCl to be the main way people deploy these applications," said Brad Chen, Google's engineering manager of Native Client, in an interview.
That's important because Google wants the technology to work broadly across the whole Web. Lacking that, developers likely would either ignore Native Client or only use it on various islands, "potentially leading to fragmentation of the Web," the researchers said.
New Web app brains and brawn
Google has a long way to go with NaCl: it must convince the industry that its security mechanism is sound, woo browser users or makers to adopt the technology, and encourage developers to learn and use it.But Native Client holds the potential to dramatically change today's perception of Web applications as useful but not very sophisticated or snappy. That could pay big dividends in the move to cloud computing, especially when combined with new Web technology arriving in a new generation of faster browsers.
"We can build applications on the Web that are every bit as good as native applications," said Linus Upson, engineering director for the Chrome browser and Chrome OS, in a December interview, speaking of Google's aspirations for Native Client and a related Google technology called O3D for accelerated 3D graphics on the Web.
And there's evidence to back him up. In a new paper on Native Client's broader processor support (PDF), Google said its technology slows execution times down 10 percent on 64-bit x86 chips and 3 percent on ARM chips. That's not a major hit, especially compared to the execution speed of JavaScript.
Native Client software modules running on a machine have limited abilities--essentially the permissions granted to JavaScript, not to ordinary native applications that run on the operating system. Think of them as a way to bring some new muscle to what Web applications can do.
NaCl software could work in conjunction with other Web application infrastructure to enrich programming possibilities. Scalable Vector Graphics (SVG), Canvas, WebGL, and O3D could provide slicker interfaces. Local storage on the PC will let Web applications work with data that's stored on the computer without having to rely constantly on the network. Other new work will let Web applications deal with Webcams and potentially other hardware attached to a computer.
Portable Native Client splits the NaCl software execution into two parts to make it work on more processors.
(Credit:Google)
Google's power: Browser, OS, apps
NaCl is academically interesting to those concerned with the best way to get a computer to do work securely in the age of the Internet. But it's got a very direct relationship to Google's priorities, too: the company wants to make the Web the platform for software, and indeed with applications such as Gmail and Google Docs offers some of the most advanced examples to date.Note that Native Client is built into Chrome and the browser-based Chrome OS. Google's operating system for Netbooks is due to arrive later this year, and also remember that Google makes the browser in its Android operating system that typically runs on ARM-based smartphones.
In short, even if nobody else adopts Native Client, Google can make it relevant. Google's position as a significant browser maker, Web application developer, and mobile operating system creator means it has the ability to singlehandedly break much of the chicken-and-egg impasse that often limits adoption of new technology.
For example, Google Spreadsheet is limited today by what can be done with JavaScript. Tapping into native computing power could open the application to heavy-duty statistical calculations or faster sorting, for example.
For Google, though, success will mean others use it, too. To that end, Google is discussing standardization of Native Client and O3D with other browser makers, though not at the expense of actually moving ahead with the work. "We're excited about getting people using the system, but it's quite early still, so there isn't much to say right now about standardization," Chen said.
Making Native Client standard, though, is a tougher matter. There, Google will have to win over allies with their own priorities, and the present Web standards agenda is already jam-packed with work.
But broadly, cloud computing is catching on, and Google has agreement on the vision if not the details. Even though Microsoft--the browser maker whose Windows and Office franchise means it has the most to lose from the migration of applications to the Net--is working on a faster, more relevant Internet Explorer geared for Web applications and on bringing Office to the Web.
Detailing NaCl
In its two new NaCl papers, Google describes what it's been up to recently with the technology.PNaCl essentially breaks the Native Client execution process into two parts to attain its portability.
The first part is the conversion of the human-written software into an intermediate state called "bitcode." This represents a low-level version of the program, but not the lowest level, the machine code that a computer actually understands and executes.
This bitcode is the portable part. To actually execute it, the second part of the process, a specific module adapted for each processor architecture translates the bitcode into the machine code that can run. This is where the security checks are run to ensure the software doesn't perform any of the forbidden instructions.
So far, Google plans translators for 32-bit and 64-bit x86 processors and for ARM, and the Google researchers said it should be "straightforward to support other popular general-purpose CPUs in future.
"Part of the point of this design is that we take portability very seriously," Chen said. "The only ISAs [processor instruction set architectures] we're working on now are ARM, x86-32 and x86-64. There are a lot of architectures and architecture variants in the world, and we surely won't be able to support all of them, but we will eagerly support credible outside efforts to support other platforms."
Translation adds overhead, though, Chen said, it's not yet clear how much.
"We think we can make the translation time small compared to download times, and I'm hoping the typical effective delay will very small, much less than a second," Chen said. "Apart from translation, we think the runtime impact of PNaCl will be negligible."
The other paper concerns the move to the other processors. Doing so was tricky, because the initial NaCl technology relied on a feature of 32-bit x86 chips that restricted a computing process to a particular area of memory, making it harder for it to escape its bounds in a way that could be used in a computer attack.
Looking for a substitute for this memory segmentation technique that would work on 64-bit x86 and ARM chips, Google opted to use something called software fault isolation that it initially thought would make the system too sluggish.
"The overhead of fault isolation using these techniques is very low, helping to make SFI a viable approach for isolating performance critical, untrusted code in a Web application," Google researchers said in their paper. However, with Google's approach, one perk of 64-bit x86 software, the ability to use large amounts of memory, isn't available: it's bound by the 32-bit chip limit of 4GB. That's still plenty for most applications today, though.
The upshot, in Google's eyes, is that Native Client is closer to prime time, and not just for PCs.
"These results indicate that a browser running on virtually any modern computer or cell phone could run a fast, performance-sensitive Native Client application," Chen said.
Comments