JavaScript’s new Operator (or: How to Read ECMA-262)

by Chad Austin
Dec 10 12

Before we dig in, I must briefly describe the state of JavaScript, aka ECMAScript, aka ECMA-262.

Two versions of JavaScript are in wide use today. ECMA-262, 3rd edition (commonly known as ES3) was standardized in 1999 and is supported by pretty much anything that claims to support JavaScript. ECMA-262, 5th edition (commonly known as ES5) is a slightly more modern language that, while common among the latest web browsers, is not ubiquitous. Note that ECMA-262, 5.1 edition, is a bugfix release of the ES5 standard.

The ECMA-262 standards are quite approachable and freely available online.

(This is a tangent but it’s cool. You should know the test262 project provides an ES5.1 conformance suite, and it appears that IE10 is the most compliant implementation at this time.)

On to the topic at hand, which is the behavior of JavaScript’s new operator and why you might want a JavaScript implementation of it.

Open the ES5 spec and examine section 11.2.2. You can disregard the fact that there are two versions of the new operator: the specification distinguishes between new X and new X.Y(Z).

The key point is that new evaluates its argument expression, which must result in an Object, and calls said object’s internal [[Construct]] method. Only Function objects have a [[Construct]] method, and its behavior is precisely defined in section 13.2.2.

I will demonstrate a JavaScript function that implements new. The first argument is the constructor.

function new_(T) {
    if (!(T instanceof Function)) {
        throw new TypeError(T + ' is not a constructor');
    }
    var proto = T.prototype;
    if (!(proto instanceof Object)) {
        proto = Object.prototype;
    }
    var obj = Object.create(proto);
    var result = T.apply(obj, [].slice.call(arguments, 1));
    return (result instanceof Object) ? result : obj;
}

Why is such a function useful?

First, and primarily, new_ can take a variable list of arguments, via new_.apply. That can’t be done with the traditional new operator.

Secondly, new_ can be bound to produce factory functions. Let’s say you have a constructor SomeClass. You can create a SomeClass factory as such:

var SomeClassFactory = new_.bind(undefined, SomeClass);
var instance = SomeClassFactory();
(instance instanceof SomeClass); // true

Thirdly, new_ illustrates some non-intuitive behavors of the new operator. For example, the created object’s prototype is set to Object.prototype if the constructor’s prototype is not an object. Consider:

function foo() {}
foo.prototype = null;
var instance = new foo;
Object.getPrototypeOf(instance) === Object.prototype; // true

A lesser-known behavior is that constructors can themselves return values. If the value returned is an Object (remember that Functions are Objects too), new returns it instead of the object passed to the constructor as this. For example:

function Wooo() { return Wooo; }
Wooo === new new new new new new new new Wooo; // true

I don’t recommend it, but this technique could be used to write constructors that behave identically whether they are called directly or as a constructor:

function Flexible(arg) {
    var this_ = Object.create(Flexible.prototype);
    this_.arg = arg;
    return this_;
}
Flexible.prototype.method = function() {
    return this.arg;
}

var a = Flexible('success');
var b = new Flexible('success');
'success' === a.method(); // true
'success' === b.method(); // true

I hope that you’ve learned something about JavaScript’s new operator. Before sending you on your way, I’d like to point out that Object.create is an ES5 method and thus unsupported in ES3 implementations. So could we write an implementation of new_ that runs in old browsers by avoiding Object.create?

Object.create is effectively a primitive operation on which the new operator is built. And indeed, we can bypass the need for Object.create by using some of new’s behavior to create an object with a specified prototype. Here is the ES3 version of new_:

function new_(T) {
    if (!(T instanceof Function)) {
        throw new TypeError(T + ' is not a constructor');
    }
    var proto = T.prototype;
    if (!(proto instanceof Object)) {
        proto = Object.prototype;
    }
    function dummy() {}
    dummy.prototype = proto;
    var obj = new dummy; // Object.getPrototypeOf(obj) === proto
    var result = T.apply(obj, [].slice.call(arguments, 1));
    return (result instanceof Object) ? result : obj;
}

Emscripten Results: Firefox 19 shows dramatic improvement

by Chad Austin
Nov 28 12

Last time, we looked at Emscripten’s performance with current JS JITs on an in-order Atom core and found a penalty relative to out-of-order cores.

However, I told @js_dev I’d give updated numbers on a more typical out-of-order x86 core like my 2010 MacBook Pro’s i5.

There are a couple interesting things here: Firefox 19 shows substantial Emscripten performance improvements over Firefox 17, which is even still on par with hand-written JavaScript. While JavaScript JITs are still an order of magnitude away from native code performance, Emscripten’s performance meets or exceeds the performance of hand-written JavaScript. Progress!

The machine is a 2010 Macbook Pro, Core i5 2.53 GHz, OS X 10.6.

For each compiler, I compiled with -O0, -O1, -O2, -O3, and picked the best result.

LanguageCompilerVariantVertex RateSlowdown
C++clang -O2SSE1001421971
C++gcc -O3SSE931091801.08
C++gcc -O3scalar603983331.66
C++clang -O2scalar583243081.72
JavaScriptChrome 23untyped951048910.5
Emscripten -O3Aurora 19.0a2scalar766600013.1
Emscripten -O3Firefox 17scalar604400016.6
JavaScriptChrome 23typed arrays589000017
Emscripten -O3Chrome 25.0 canaryscalar573370617.5
JavaScriptFirefox 17untyped526473519
JavaScriptFirefox 17typed arrays524000019.1
Emscripten -O2Chrome 23scalar458616521.8
Emscripten -O1nodejs 0.8.10scalar445310922.5
Emscripten -O2nodejs 0.8.10scalar148340667.5
Emscripten -O3nodejs 0.8.10scalar668796150

Here are the results for various Emscripten optimization levels:

BrowserCompilation LevelVertex Rate
Firefox 17emscripten -O02451509
Firefox 17emscripten -O14080000
Firefox 17emscripten -O25146000
Firefox 17emscripten -O36044000
Chrome 23emscripten -O01229754
Chrome 23emscripten -O14152339
Chrome 23emscripten -O24586165
Chrome 23emscripten -O3465162
Aurora 19.0a2emscripten -O02062762
Aurora 19.0a2emscripten -O14900000
Aurora 19.0a2emscripten -O26214757
Aurora 19.0a2emscripten -O37666000
Chrome 25.0 canaryemscripten -O03001399
Chrome 25.0 canaryemscripten -O14410235
Chrome 25.0 canaryemscripten -O25482000
Chrome 25.0 canaryemscripten -O35733706

I updated the benchmark to automate compiling and running the native and node.js builds.

JavaScript, Emscripten, and the Atom D2700

by Chad Austin
Nov 25 12

Lately I’ve been doing some work with Emscripten. As predicted, the quality of Emscripten’s generated code is improving and JITs are learning to understand its generated code. I have high hopes for asm.js, a formalization of high-performance, low-level JavaScript. I now believe it’s conceivable that Emscripten could approach the same level of performance as PNaCl, though whether that happens remains to be seen.

However, having a rough understanding of how today’s JavaScript JITs work, I’ve always wondered whether Emscripten-generated code would be especially penalized relative to native code on an in-order core like Intel Atom. Having recently built an Intel Atom home server, I figured I’d update my recent Emscripten skinning benchmark results and find out.

First I’ll describe the hardware. The CPU is an Atom D2700 on the Intel D2700DC board. 1066 MHz DDR3 memory. Two cores hyperthreaded. Running Ubuntu 12.04 Server. Firefox and Chromium packages are stock. Node.js and clang 3.1 are x64 Linux binaries downloaded from their respective websites. Emscripten is commit 26250471b46a68204711f037f33790bfb4ba37c7 in the master branch.

Now the results. Remember there are three JavaScript implementations: hand-written JS with untyped arrays and objects “untyped”, hand-written JS with typed arrays “typed arrays”, and Emscripten-compiled C++ “scalar”. Emscripten’s compiler was invoked with -O1. I saw significant performance drop-offs with -O2 and -O3.

LanguageCompilerVariantVertex RateSlowdown
C++gcc 4.6.3 -O3SSE240400001
C++clang 3.1 -O3SSE225300001.07
C++gcc 4.6.3 -O3scalar187300001.28
C++clang 3.1 -O3scalar130400001.84
JavaScriptChromium 20.0untyped31500007.63
JavaScriptFirefox 17typed arrays24375629.86
JavaScriptFirefox 17untyped108457722.2
EmscriptenFirefox 17scalar94433325.5
JavaScriptChromium 20.0typed arrays80757729.8
Emscriptennode 0.8.14scalar67980235.4
EmscriptenChromium 20.0scalar67796635.5

Based on the previous benchmark results and my recent experience with Emscripten, it appears that JavaScript JITted code indeed has a penalty relative native code on in-order cores, or at least the Atom D2700.

Next time I hope to update these benchmarks on a high-end desktop CPU.

As always, if you’d like to reproduce these results or question them, the code is available on my github.

Digging into JavaScript Performance, Part 2

by Chad Austin
Nov 6 11

UPDATE. After I posted these numbers, Alon Zakai, Emscripten’s author, pointed out options for generating optimized JavaScript. I reran my benchmarks; check out the updated table below and the script used to generate the new results.

At the beginning of the year, I tried to justify my claim that JavaScript has a long way to go before it can compete with the performance of native code.

Well, 10 months have passed. WebGL is catching on, Native Client has been launched, Unreal Engine 3 targets Flash 11, and Crytek has announced they might target Flash 11 too. Exciting times!

On the GPU front, we’re in a good place. With WebGL, iOS, and Flash 11 all roughly exposing shader model 2.0, it’s not a ton of work to target all of the above. Even on the desktop you can’t assume higher than shader model 2.0: the Intel GMA 950 is still at the top.

However, shader model 2.0 isn’t general enough to offload all of your compute-intensive workloads to the GPU. With 16 vertex attributes and no vertex texture fetch, you simply can’t get enough data into your vertex shaders do to everything you need, e.g. blending morph targets.

Thus, for the foreseeable future, we’ll need to write fast CPU code that can run on the web, mobile devices, and the desktop. Today, that means at least JavaScript and a native language like C++. And, because Microsoft has not implemented WebGL, the Firefox and Chrome WebGL blacklists are so strict, and no major browsers fall back on software, you probably care about targeting Flash 11 too. (It does have a software fallback!) If you care about Flash 11, then your code had better target ActionScript 3 / AVM2 too.

How can we target native platforms, the web, and Flash at the same time?

Native platforms are easy: C++ is well-supported on Windows, Mac, iOS, and Android. SSE2 is ubiquitous on x86, ARM NEON is widely available, and both have high-quality intrinsics-based implementations.

As for Flash… I’m just counting on Adobe Alchemy to ship.

On the web, you have two choices. Write your code in C++ and cross-compile it to JavaScript with Emscripten or write it in JavaScript and run via your native JavaScript engine. Ideally, cross-compiling C++ to JS via Emscripten would be as fast as writing your code in JavaScript. If it is, then targeting all platforms is easy: just use C++ and the browsers will do as well as they would with native JavaScript.

Over the last two evenings, while weathering a dust storm, I set about updating my skeletal animation benchmark results: for math-heavy code, how does JavaScript compare to C++ today? And how does Emscripten compare to hand-written JavaScript?

If you’d like, take a look at the raw results.

LanguageCompilerVariantVertex RateSlowdown
C++clang 2.9SSE1015800001
C++gcc 4.2SSE964204541.05
C++gcc 4.2scalar633555011.6
C++clang 2.9scalar629281751.61
JavaScriptChrome 15untyped102100009.95
JavaScriptFirefox 7typed arrays840159812.1
JavaScriptChrome 15typed arrays579000017.5
EmscriptenChrome 15scalar518481519.6
JavaScriptFirefox 7untyped510489519.9
JavaScriptFirefox 9a2untyped200598850.6
JavaScriptFirefox 9a2typed arrays193227152.6
EmscriptenFirefox 9a2scalar734126138
EmscriptenFirefox 7scalar729270139

Conclusions?

  • JavaScript is still a factor of 10-20 away from well-written native code. Adding SIMD support to JavaScript will help, but obviously that’s not the whole story…
  • It’s bizarre that Chrome and Firefox disagree on whether typed arrays or not are faster.
  • Firefox 9 clearly has performance issues that need to be worked out. I wanted to benchmark its type inference capabilities.
  • Emscripten… ouch :( I wish it were even comparable to hand-written JavaScript, but it’s another factor of 10-20 slower…
  • Emscripten on Chrome 15 is within a factor of two of hand-written JavaScript. I think that means you can target all platforms with C++, because hand-written JavaScript won’t be that much faster than cross-compiled C++.
  • Emscripten on Firefox 7 and 9 still has issues, but Alon Zakai informs me that the trunk version of SpiderMonkey is much faster.

In the future, I’d love to run the same test on Flash 11 / Alchemy and Native Client but the former hasn’t shipped and the latter remains a small market.

One final note: it’s very possible my test methodology is screwed up, my benchmarks are wrong, or I suck at copy/pasting numbers. Science should be reproducible: please try to reproduce these results yourself!

More High Order Bits

by Chad Austin
Oct 25 11

One of our biggest failings as humans is our inability to ignore small, unimportant decisions. Keyword: unimportant. I’m not referring to details that add up to something greater, like the tiny details that sum to make this computer a joy to use.

We would all be well-served by focusing on the high-order bits in our lives.

  • Creativity and Purpose over following the rules
  • Velocity over predictability
  • Reducing Consumption over recycling
  • Scalable Algorithms over optimal machine code
  • Eating less, Exercising more over antioxidants, carbohydrates, high-fructose corn syrup, etc.

I value the items on the right, but I value the items on the left more.

High Order Bits (or: mostly correct but in the right direction)

by Chad Austin
Oct 25 11

First, the moral: Unit tests are good. But reliable design is better.

Even if you have to deal with short-term pain. Even if you haven’t figured out all of the edge cases.

Let me back up. I love automated tests. I’ve been test-driving code at IMVU since I started. We buy new engineers a copy of Test-Driven Development: By Example. Whenever there is a bug, we write tests to make sure it never happens again.

After years of working this way, seeing projects succeed and fail, I’d like to refine my perspective. Let me share a story.

IMVU was originally a bolt-on addition to AOL Instant Messenger. Two IMVU clients communicated with each other by manipulating AOL IM’s UI and scanning the window for new text messages, much like a screen reader would. This architecture propagated some implications through our entire codebase:

1) The messaging layer was inherently unreliable. AOL IM chat windows could be manipulated by the user or other programs. Thus, our chat protocol was built around eventual consistency.

2) We could not depend on an authoritative source of truth. Since text-over-IM is peer-to-peer, no client has a true view into where all of the avatars are sitting or who currently owns the room.

Thus, in 2008, long after we’d dropped support for integration with third-party IM clients and replaced it with an authoritative state database, we continued to have severe state consistency bugs. The client’s architecture still pretended like the chat protocol was unreliable and state was peer-to-peer instead of authoritative.

To address these bugs, we wrote copious test coverage. These were deep tests: start up a local Apache and MySQL instance, connect a couple ClientApp Python processes to them, have one invite another to chat, and assert that their scene graphs were consistent. We have dozens of these tests, for all kinds of edge cases. And we thought we’d fixed the bugs for good…

But the bugs returned. These tests are still running and passing, mind you, but differences in timing and sequencing result in the same state consistency issues we saw in 2008. It’s clear that test coverage is not sufficient to prevent these types of bugs.

So what’s the other ingredient in reliable software? I argue that, in agile software development, correct-by-design systems are underemphasized.

Doesn’t Test Driven Development guide me to build correct-by-design systems?

TDD prescribes a “red, green, refactor” rhythm, where you write a failing test, do the simplest work to make it pass, and then refactor the code so it’s high quality. TDD helps you reach the “I haven’t seen it fail” stage, by verifying that yes, your code can pass these tests. But just because you’ve written some tests doesn’t mean your code will always work.

So there’s another level of reliability: “I have considered the ways it can fail, but I can’t think of any.” This statement is stronger, assuming you’re sufficiently imaginative. Even still, you won’t think of everything, especially if you’re working at the edge of your human capacity (as you should be).

Nonetheless, thoughtfulness is better than nothing. I recommend adding a fourth step to your TDD rhythm: “Red, green, refactor, what else could go wrong?” In that fourth step, you deeply examine the code and think of additional tests to write.

The strongest level of software correctness is not about finding possible failure conditions; it’s about proving that your system works in the presence of all inputs. Correctness proofs for non-trivial algorithms are too challenging for all of the code we write, but in a critical subsystem like chat state management, the time spent on a lightweight proof will easily pay for itself. Again, I’m not advocating that we always prove the correctness of our software, but we should at least generally be convinced of its correctness and investigate facts that indicate otherwise. TDD by itself is not enough.

OK, so we can’t easily test-drive or refactor our way out of the chat system mess we got ourselves into, because it’s simply too flawed, so what can we do? The solution is especially tricky, because in situations like this, there are always features that depend on subtleties of the poor design. A rewrite would break those features, which is unacceptable, right? Even if breaking those features is acceptable to the company, there are political challenges. Imagine the look on your product owner’s face when you announce “Hey I have a new architecture that will break your feature but provide no customer benefit yet.”

The ancient saying “You can’t make an omelette without breaking some eggs” applies directly here. Preserving 100% feature compatibility is less important than fixing deep flaws.

Why? High-order bits are hardest to change, but in the end, are all that matters. The low-order bits are easy to change, and any competent organization will fix the small things over time.

I can’t help but recall the original iPhone. Everyone said “What?! No copy and paste?!” Indeed, the iPhone couldn’t copy and paste until 18 months and two major OS releases later. Even still, the iPhone reshaped the mobile industry. Clearly 100% feature compatibility is not a requirement for success.

My attitude towards unit testing has changed. While I write, run, and love unit testing, I value correct-by-design subsystems even more. When it comes down to it, tests are low-order bits compared to code that just doesn’t break.

For those curious, what are we doing about the chat system? I’ll let Jon’s GDC presentation speak for itself.

HTML5 – New UI Library for Games [Annotated Slides]

by Chad Austin
Mar 20 11

At GDC 2011, on behalf of IMVU Engineering, I presented our thesis that HTML is the new UI library for developing desktop applications and games.

The annotated slides from our presentation are now available at the IMVU Engineering Blog.

Holiday Report

by Chad Austin
Jan 15 11

Things I learned over the holidays:

  • jQuery
  • AppEngine
  • some iOS
  • some Facebook API
  • that I haven’t lost my ability to Flow, it just takes longer to wind up. Before, I could reach flow in 10-15 minutes. Now it takes 60-90.

In Defense of Language Democracy (Or: Why the Browser Needs a Virtual Machine)

by Chad Austin
Jan 8 11

Years ago, Mark Hammond did a bunch of work to get Python running inside Mozilla’s script tags. Parts of Mozilla are ostensibly designed to be language-independent, even. Unfortunately, even if Mozilla had succeeded at shipping multiple language implementations, it’s unlikely other browser vendors would have followed suit. It’s just not logistically feasible to have all browsers gate and care for the set of interesting languages on the client.

I can hear you asking “Why do I care about Python in the browser? Or C++? Or OCaml? JavaScript is a great language.” I agree! JavaScript is a great language. Given the extremely short timeframe and immense political pressure, I’m thrilled we ended up with something as capable as JavaScript.

Nonetheless, fair competition benefits everyone. Take a look at what’s happened in the web server space in the last few years: Ruby on Rails. Django. Node.js. nginx. Tornado. Twisted. AppEngine. MochiWeb. HipHop-PHP. ASP.NET MVC. A proliferation of interesting datastores: memcache, redis, riak, etc. That’s an incredible amount of innovation in a short period of time.

Now let’s go through the same exercise, but on the client. jQuery, YUI, fast JavaScript JITs, CSS3, CoffeeScript, proliferation of standards-compliant browsers, some amount of HTML5… Maybe ubiquitous usage of Flash video? These advancements are significant, but it’s clear the front-end stack is changing much more slowly than the back-end.

Why is the back-end evolving faster than the front-end?

When building an application backend, even atop a virtualized hosting provider such as EC2, you are given approximately raw access to a machine: x86 instruction set, sockets, virtual memory, operating system APIs, and all. Any software that runs on that machine competes at the same level. You can use Python or Ruby or C++ or some combination thereof. If Redis wants to innovate with new memory management schemes, nothing is stopping it. This ecosystem democratized – nay, meritocratized – innovation.

On the front-end, the problem boils down to the fact that JavaScript is built atop but does not expose the capabilities of the underlying hardware, meaning browsers and JavaScript implementations are inherently more capable than anything built atop them.

Of course, any client-side technology is going to rev slower simply because it’s hard to get people to update their bits. Also, users decide which client bits they like best, whether they be Internet Explorer, Chrome, or Firefox. Now the technology-takes-time-to-gain-ubiquity problem has a new dimension: each browser vendor must also decide to implement this technology in a compatible way. It took years for even JavaScript to standardize across browsers.

However, if we could instead standardize the web on a performant and safe VM such as CLR, JVM, or LLVM, including explicit memory layout and allocation and access to extra cores and the GPU, JavaScript becomes a choice rather than a mandate.

This point of view depends on my prediction that JavaScript will not become competitive with native code, but not everyone agrees. If JavaScript does eventually match native code, than I’d expect the browser itself to be written in it. It’s impossible for me to claim that JavaScript will never match native code, but the sustained success of C++ in systems programming, games, and high-performance computing is a testament to the value of systems languages.

Native Client, however, gives web developers the opportunity to write code within 5-10% of native code performance, in whatever language they want, without losing the safety and convenience of the web. You can write web applications that leverage multiple cores, and with WebGL, you can harness dedicated graphics hardware as well. Native Client does restrict access to operating system APIs, but I expect APIs to evolve reasonably quickly.

Let’s take a particular example: the HTML5 video tag. Native Client could have sidestepped the entire which-video-codec-should-we-standardize spat between Mozilla, Google, Apple, and Microsoft by allowing each site to choose the codec it prefers. YouTube could safely deploy whatever codecs it wanted, and even evolve them over time.

With Native Client, we could share Python code between the front-end and the back-end. We could use languages that support weak references. We could implement IMVU’s asynchronous task system. We could embed new JavaScript interpreters in old browsers.

Native Client is not the only option here. The JVM and CLR are other portable and performant VMs that have seen considerable language innovation while approximating native code performance.

A standardized, performant, and safe VM in the browser would increase the strength of the open web versus native app stores and their arbitrary technology limitations.

Finally, I’d like to thank Alon Zakai (author of Emscripten), Mike Shaver, and Chris Saari for engaging in open, honest discussion. I hope this public discourse leads to a better web. Either way, I hope this is my last post on this topic. :)

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

by Chad Austin
Jan 5 11

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.