Comment by bad_user | Hacker News Reader

Comment by bad_user | Hacker News Reader

Parent Full thread

> In the earlier days of Java, a common refrain was that the JVM could get better-than-native performance because it could make runtime decisions about JIT optimization

In reality, that goal was achieved ;-)

> You are aware that Mono AOT compiles C#, correct?

Java can be compiled straight to native code too. GCJ works like that for instance. The resulting performance from binaries of such compilers is abysmal though.

C# is not really a good example because C# was designed for AOT compilation. For example, most methods in the standard library are not polymorphic and methods in C# are final by default, whereas with Java it's the complete opposite, with methods being virtual by default. With all respect to Mono and Xamarin, it's hardly an epitome of performance.

Also, right now JRuby trumps in performance just about every other Ruby implementation available, including MRI, RubyMotion, Rubinius or IronRuby.

> JIT is not strictly necessary here

For dynamic languages, if you want decent performance, all the known techniques require JIT techniques. One of the most important optimizations the JVM does is inlining of virtual method calls at runtime, something which is impossible to do ahead of time. Another important technique is tracing JIT compilation, used successfully in recent Javascript engines (except V8 I think) and by Lua [1]

All known techniques for optimizing dynamic languages or runtime-polymorphic method dispatch require recompilation of code based on changing conditions.

[1] http://en.wikipedia.org/wiki/Trace_tree

> In reality, that goal was achieved ;-)

This ... has not been my experience. And I write a lot of high-performance native and Java code.

> For dynamic languages, if you want decent performance, all the known techniques require JIT techniques.

Then adopt a bytecode standard so that it can be JIT'd. I don't believe that NaCL is the end of the conversation, just that Mozilla has consistently prevented the conversation from starting, and refused to participate in it unless it involves Eich's JavaScript as the baseline implementation language.

So, you want a standard program representation that's amenable to JIT compilation. But why, exactly, does it need to be a bytecode format, rather than source code in a standardized language?

Let me reiterate some of the advantages of JavaScript:

* A performance arms race among JavaScript implementers has been underway for nearly half a decade now. JS thus has a head start in that area over any hypothetical language or bytecode format that might be integrated in a browser.

* JS already has first-class access to the DOM -- the API that all the browsers already have -- as well as all the other up-and-coming APIs.

* There are already JS debuggers, and with source maps, these debuggers can even be made to work with other languages that can be compiled to JS. All JS developers benefit from this, as well as all developers who use languages that compile to JS.

So basically, JS has a head start over NaCl, Dart, or any other potential "clean" replacement.

As far as I can tell, your only objection then is that there's something aesthetically wrong with using a quirky high-level language as a compilation target for other languages. To that I can only say that worse is better. We might as well get on with the business of writing great apps with the tools we have.

Reply on news.ycombinator.com