Native Client is Widely Misunderstood (And What Google Should Do About It)

Wow. My recent post about why Mozilla should adopt Native Client stirred up quite a storm. Some folks don’t believe the web needs high-performance applications. Some are happy with whatever APIs browsers expose. I disagree with these points, but I can respect them.

Most surprisingly, several respondents had simply untrue objections to Native Client, so I’d like to clear up their misconceptions. Then I will make recommendations to the Native Client team on how to fix their perception problems.

If you want to spend some minutes and learn about Native Client and LLVM from the horse’s mouth, watch this video.

Misconceptions about Native Client

Native Client implies x86

False. Originally, Native Client was positioned as an x86 sandbox technology, but now it has a clear LLVM story, with x86-32, x86-64, and partially-implemented ARM backends. Portability is a key benefit of the web, and Google understands this.

Native Client is complicated

True, it’s certainly not a trivial amount of code. But compare the amount of code in NativeClient vs. Mozilla’s JavaScript engine:

$ wc -l native_client/src/**/*.{c,h,cc}
...
155082 total
$ find mozilla-central/js/src -path '*tests*' -prune -o \( -iname '*.c' -o -iname '*.cc' -o -iname '*.h' -o -iname '*.cpp' \) -print0 | wc -l --files0-from=-
...
363471 total

NativeClient is at least on the same order of complexity as a modern JavaScript engine, and since it already provides performance within 5% of native code, I’d guess it’s less susceptible to change.

Native Client / LLVM is not an open standard

I empathize with this concern, but Flash isn’t an open standard and it sees wide adoption. The difference between Flash and Native Client is that Native Client / LLVM is open source and could easily become an open standard.

Native Client is insecure

Native Client was designed to be a secure x86 sandbox. Under the assumption that its basic security model is sound, the question then becomes “how large is the attack surface and how likely is it to be broken?” Given the amount of code in a modern web browser and JavaScript JIT, I don’t see how Native Client is any worse.

With a little more work, JavaScript will perform at the same level as native code

I’m not informed or involved enough to claim JavaScript can never be as fast as native code. However, I have my doubts. A friend was working on a Monte Carlo Go AI, and he initially wrote his algorithm in JavaScript. Monte Carlo requires simulating a large number of game states, and a naïve port of his JavaScript to C++ gave a 100x performance improvement.

Check out my skeletal animation benchmark, where the JavaScript JITs need another 10x to compete with native code.

Even if JITs can match native code in some benchmarks (and I hope they do), performance across browsers will depend on the particulars of the JIT implementation. Native Client, at least for pure computation, would perform the same in every browser.

We can simply compile languages like Haskell, Python, and C to optimized JavaScript and let the JIT sort it out.

There are some attempts to use JavaScript as a backend for other language implementations, but they rarely perform well. For example, a CPython compiled to JavaScript via LLVM/Emscripten runs about 30x slower than a native build in Chrome, and 200x slower in Firefox 4 beta 8.

I’ve heard the argument for an RPython-like statically-analyzable subset of JavaScript that browsers could run very efficiently. This subset could operate as a defacto bytecode, and Emscripten could compile LLVM to it with minimal performance loss. It’s possible this could work, but directly exposing LLVM seems more fruitful.

Red Herring Arguments

JavaScript is easier to develop with than native languages

Sure, but that doesn’t mean native languages don’t have a purpose. My hypothesis is that there are problems for which JavaScript is not and will not be suited, and that exposing the native power of the machine is better for application developers, and thus the web.

Binaries are obscure

Minified JS isn’t human-readable either, but machines can reconstruct both. Drdaemon nails it in his comment

.

“If you want native performance, just download software or install a plug-in!”

While this sentiment reflects today’s reality, it doesn’t reflect trends on the web. Web applications continue to supplant desktop applications. Google Docs, Creately, Pivotal Tracker, Gmail, Mockingbird, and all of the games on Facebook are examples where I would have used a desktop application in the past. It seems that, whenever browsers provide new capabilities, applications consume them. Why would that trend stop now?

Recommendations to the Native Client team

  1. Get a move on! Enable it by default! More flashy demos!
  2. Reposition Native Client as a portable technology and make sure it’s clear that LLVM is key to its strategy.

Finally, NativeClient is still new. I expect it will be some time before it’s solid enough to rely on for production use. That said, it has the potential to disrupt the desktop operating system and I’m excited for a future where all software is web-based.

5 thoughts on “Native Client is Widely Misunderstood (And What Google Should Do About It)”

  1. I’m very sympathetic to your desire for fast code on the web. We all need that. However, I have a few nits with details in this post:

    1. The reason that Emscripten’s Python demo is slow, is that the code is not optimized, as mentioned on that page. So please do not take this as an example of “There are some attempts to use JavaScript as a backend for other language implementations, but they rarely perform well.”

    Once all LLVM optimizations are enabled, that demo will be much faster. And with additional JS engine speedups, I expect it to eventually reach decent performance.

    Furthermore, if you want examples that *do* show good performance right now (but have other, significant limitations), check out pyjamas.

    2.

    > The difference between Flash and Native Client is that Native Client / LLVM is open source and could easily become an open standard.

    It is open source, but it could *not* easily become a standard. Standards take a lot of time and compromise. It simply isn’t realistic to expect something like NaCl to become a standard in any reasonable timeframe. I suspect Google thinks so as well, as it is not even trying to go that route.

    Furthermore, even if Google got it stamped as a standard, it seems likely it would never be accepted by Microsoft and Apple, which would doom it to never be as universal as the web.

    3. Last comment, I suspect using LLVM for portability in PNaCl was probably for lack of anything better. It isn’t inherently portable, nor easily reworked into something that is, and in the process of making it portable, there may be significant performance losses – many LLVM optimizations generate nonportable code.

  2. Thanks for your response! Despite my arguments in favor of Native Client, I greatly respect and value your work, so keep pushing the boundaries.

    Why not try to compile an optimized Python/LLVM with Emscripten? That would be an interesting exercise and would give Mozilla and the V8 teams realistic data to work with.

    Agreed that standards take time, but I believe it wouldn’t be unreasonable to see Google and Apple push LLVM for standardization, after some experience in the field of course…

  3. > Why not try to compile an optimized Python/LLVM with Emscripten?

    That’s being worked on, but it isn’t easy to do. A big part is what I mentioned before about LLVM not being portable. Unoptimized LLVM isn’t really portable, but with some tricks Emscripten manages to run it. However getting optimized LLVM to run properly is much harder.

    Anyhow currently many of the LLVM optimizations do work in Emscripten (as of last night), but several crucial ones do not. Getting them to work may require changes to LLVM itself, ironically perhaps like those PNaCl is doing ;)

    > Agreed that standards take time, but I believe it wouldn’t be unreasonable to see Google and Apple push LLVM for standardization, after some experience in the field of course…

    Google might, but I strongly doubt Apple would – the two companies have very different motivations and agendas (and I say that despite Apple’s support for and contributions to LLVM). But that’s just my personal guess of course.

  4. If we go the build-on-top-of-the-browser approach, we will endure decades more security holes. If we go the PNaCl route there will be a plausible basis on which to build a browser in which PNaCl is the supervisor and the rest is considered untrusted. The path being followed by the Javascript devotees is going to generate huge amounts of complexity just to get back the basic facility of laying down a bit of machine code. This is idiotic.

  5. I just long for the day that all major browsers support something like NaCl, and web developers can just send their layout code along with their “HTML”, so that we are finally freed from the quirks of CSS, and more importantly internet explorer.

    In fact, I hope that NaCl spawns a whole new industry of layout libraries.

Leave a Reply

Your email address will not be published. Required fields are marked *