Linked by Thom Holwerda on Fri 14th May 2010 18:28 UTC
Google "Today, we're happy to make available a developer preview of the Native Client SDK - an important first step in making Native Client more accessible as a tool for developing real web applications. When we released the research version of Native Client a year ago, we offered a snapshot of our source tree that developers could download and tinker with, but the download was big and cumbersome to use. The Native Client SDK preview, in contrast, includes just the basics you need to get started writing an app in minutes."
Thread beginning with comment 424695
To view parent comment, click here.
To read all comments associated with this story, please click here.
Neolander
Member since:
2010-03-08

Oh, okay ! I thought that the whole thing was about using native code, but if it's just some glorified interpreter then why not ^^

Reply Parent Score: 1

umccullough Member since:
2006-01-26

but if it's just some glorified interpreter then why not ^^


It's not really an interpreter... not really.

Basically, it's a sandboxed environment that inspects the machine code of the NaCl app before allowing it to run, making sure it doesn't make any "dangerous" x86 calls that would allow it to affect other code or resources outside the sandbox. It is then allowed to run natively on the processor once it passes all the checks. It is allowed to link and call other NaCl libs, and is allowed to access host OS resources that the NaCl environment provides.

Reply Parent Score: 2

Neolander Member since:
2010-03-08

Yes, but since NaCl takes care of the loading job and since NaCl and its libraries take care of the system calls, we end up using an interpreter-like behavior : code cannot run directly on the computer and must be analyzed and translated to native code by an external program.

PNaCl code cannot just be loaded by the OS and handed to the processor with a "good luck !". It's some kind of bytecode that must be translated to something the local architecture and the local OS understand prior execution, just like in Java apps.

However, we all know about Java's startup performance. It's an inherent drawback of AOT compilation. So I suppose Google have something behind their back if they want to put this sodium chloride thing everywhere on the web. Maybe some kind of cloud compilation services ?

Edited 2010-05-16 07:28 UTC

Reply Parent Score: 1