Hacker News Reader

Comment by Kronopath | Hacker News Reader

I actually really like the sound of this, not because of the stated benefits (though those are nice), but because it sounds like this would actually create a really good upgrade path to implementing a proper bytecode into browsers.

I mean, with asm.js and the copious amounts of compile-to-Javascript languages available these days, Javascript is already becoming a de facto bytecode for the web. But it's always been a weird and uncomfortable hack done for the sake of backwards compatibility: a higher-level language hijacked to work as a compile target, simply because it's the only thing supported by browsers.

If projects like this Emterpreter catch on, though, it allows for a smooth path to proper bytecode: for backwards compatibility, you have the Emterpreter read and execute the bytecode, but in other, more modern browsers you have the browser execute the bytecode directly. I think this would be an overall better approach than what we have now.

View on HN

> create a really good upgrade path to implementing a proper bytecode into browsers.

I think that's very unlikely to happen. Instead, what will happen will be exactly "emterpreter"ing: There will be multiple bytescodes, and they will all ship with their own interpreters/compilers.

If the emterpreter, instead of executing the bytecode, would generate JS code for it (and feed it into the JIT compiler if there is one), you'll get the best of all worlds -- bytecode format, top performance, perfect backwards compatibility. I suspect that's kripken's next move.

Given that this is the case, why would someone want to shackle themselves to a specific bytecode format, which is practically impossible to get universally accepted? (This argument is supported by PNaCl; The technical problem is small; the political problem is huge).

Work on JS optimization by all vendors is already extremely impressive and is not going to stop even if everyone agreed on some bytecode. Why not capitalize on it? What does a specific bytecode buy you beyond slightly shorter load times (which the emterpreter already gives a way to greatly reduce), and not having to pull the (essentially universally cached) emterpreter code?

Because these two things, while nice, are not enough support for the revolution that a proper bytecode is.

As with asm.js it wouldn't need to be universally accepted: It can "sneak in the back door" by continuing to work fine in browers that "just" supports standard javascript.

If code using this method clearly labels the bytecode and interpreter and the part that background loads the "real thing", then implementations can opt to add whatever optimisations they like to speed it up as it stabilises . Doesn't matter if the bytecode changes, as long as it's labelled properly so the optimised versions falls back to just interpreting the JS if it comes across a version (of the interpreter/bytecode as a whole, or just a single opcode) it doesn't understand (or that the implementer hasn't seen a need to optimise).

If the interpreter is guaranteed to retain a certain structure, it could be very easy to just "unroll" the interpreter loop and selectively JIT portions of the bytecode based on hotspots. You can optimise that a lot in a non-bytecode specific way by annotating the interpreter loop with assertions that grants extra guarantees (immutable bytecode; markers to indicate which code is only interpreter scaffolding; decoding hints; if you also tack on "labels" for each instructions, implementations can special case on individual instructions that "settle" while still handling new instructions/changes by inlining the interpreter code.

> What does a specific bytecode buy you beyond slightly shorter load times (which the emterpreter already gives a way to greatly reduce)

The full speed from the start; note the substantially lower speed for the first little part. And the example codebase is small compared to some of the things people want to run.

I think we sort-of agree. I don't necessarily think there's a reason to specify a standard bytecode, exactly because this approach could conceivably be extended to effectively give us a "mostly standard" bytecode with the freedom to continue to change the format without a lengthy committee approach, because there's a demonstrably viable fallback.

> I actually really like the sound of this, not because of the stated benefits (though those are nice), but because it sounds like this would actually create a really good upgrade path to implementing a proper bytecode into browsers.

We already have a proper bytecode with several high-performance implementations that's supported on virtually every platform, which works as an excellent compilation target for both dynamic and static languages.

It's called JavaScript.

Now you might say JS is bloated! But that's only if it's not gzipped or minified.

Make a "proper bytecode" and you gain absolutely nothing except losing the wide support JS enjoys.

Except you gain better startup speed which was kind of the premise of this article.

True, that's maybe the only case where there's an improvement. But it's a one-time cost (the browser can cache the compiled version), and switching to bytecode is not necessarily the only way to improve performance.

For example, a JS parser specially optimised for asm.js.

Note that cache is not always a solution. Cache is a terrible answer for first-time user experience. A lot of stuff on the web is loaded outside of the cache too for various reasons. Caches gets flushed.

My suspicion is that it will never be possible to parse asm.js as quickly as bytecode simply because it is structurally different. However, a quick search does suggest there are still some improvements possible in Firefox to speed things up somewhat.

With proper bytecode you would have to do bytecode verification so no.

Javascript is as much of a bytecode for the web as Java is a bytecode for the JVM.

It is not. Where would we be if we could only execute Java on the JVM? Clojure and Scala transpiled into Java? Can you imagine how terrible that would be?

> Can you imagine how terrible that would be?

I can, and it won't be terrible at all. Compile times might suffer a little (but that's likely to be negligible with a good Java compiler - I think Jikes is now abandoned, but back in 2002 it was pretty much instantaneous even for huge files, unlike Sun's). I don't think you'd notice it on Scala, and likely also not in other JVM languages.

I've worked with Python extensions that compile indirectly through C, and I have no experience with Nim but it seems to do that very well and very quickly.

What exactly do you believe the problem would have been if Scala or Clojure generated Java rather than JVM bytecode?

Yea I'm crossing my fingers that asm.js eventually leads to a real bytecode VM in browsers and Javascript simply becomes a language that targets it.

For large applications compiling to asm.js (such as Unity3D) this experiment could provide significant gains in load time. Considering games usually spend their initial time presenting a menu, background loading of the fast-path makes a ton of sense.

Other than load time (which the emterpreter already makes great advances on), what other advantages does a bytecode carry?

I don't see "load time" as a good enough reason for a revolution of this magnitude. Do you?

Binary sizes, which would even further improve startup times, along with reducing network usage (and thereby hosting costs). GZip works just as good on binaries as it does on JavaScript.

There are two things here:

1. [citation needed] and a [specific bytecode] needed. Details are everything: an uncompressed .dex file is comparable to a gzipped compile jvm class file; Also, with a specific bytecode in mind, if you compared minified+gzipped gs to gzipped bytecode, I suspect the difference will be small.

2. Regardless, the benefit of binary size is already provided, yesterday, with the emterpreter, without requiring any buy in from any browser vendor.

So, again - what's the benefit, other than startup time (which might be solved in other ways) of a universal browser bytecode?

If you read the article, it downloads the full sized binary later. So actually the size with the emterpreter is higher

I commented on another thread, that I believe a future version of the emterpreter will generate the full JS back from the bytecode, thus eliminating that problem - it will increase the emterpreter size by a few tens of Ks, but that will probably by cached everywhere through CDNs.

And even if it never does - it's politically close to impossible to agree on a universal bytecode, so it is extremely unlikely to happen. (Google already tried with PNaCl - if they can't pull it, I doubt anyone else can)

The thing for now is that the asm.js "family" is riding on LLVM's back. More and more it's the LLVM that is becoming that VM people have longed for. It looks like LLVM is inching towards the JavaScript VM with every year that goes by. I read that Apple is using it for further JavaScript optimizations on the browser. LLVM already powers WebKit underneath right?

So as things stand right now we have 2 popular "VMs" people really use. One is JavaScript since it's going nowhere. And the other is LLVM that is "free as in beer" for companies all over. JavaScript was secluded to the client. And LLVM was secluded to the backend. Now they are going to be marrying and having lots of children. :-)

asm.js code doesn't have to be shipped in pure JavaScript form. It could come as byte code that's "uncompiled" into asm.js code before being thrown at the JavaScript runtime.

A smart compiler could recognize the ordering priority and load in chunks sequentially, with hot code rolled in first, less frequently exercised methods last.

Now they are going to be marrying and having lots of children. :-)

Here's to hybrid vigor!

So free software/open source is analogous to an open society without any arbitrary marriage restrictions, whereas closed source proprietary software tends to cause aristocratic inbreeding?

I suspect that bastards also fit into the analogy somewhere.

LLVM is not a VM by any stretch of the imagination. It is an intermediate language for compilers whose primary utility is to provide a common target for code generation and optimization. LLVM's name is a misnomer.

You're thinking of that email that someone sent on a mailing list a while back about how LLVM isn't really a bytecode because it includes architecture-specific codes.

It was a stupid email - you can make LLVM into an architecture-agnostic bytecode by disallowing those codes.

Don't believe me?... https://developer.chrome.com/native-client/reference/pnacl-b...

"You're thinking of that email that someone sent on a mailing list a while back about how LLVM isn't really a bytecode because it includes architecture-specific codes."

No, I'm not. In fact, I have no idea what email you're referencing.

LLVM as an intermediate language (I guess you could call it bytecode if you really wanted to) for compilers of arbitrary languages (expressly not a virtual machine!) is the only point I intended to make.

You are probably thinking of this email titled "LLVM IR is a compiler IR".

http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437...

It was not a stupid email. The arguments there are still pretty much correct today.

This is true, but the comment you were replying to was pretty clearly treating it as a language. With "VM" in scare quotes because it's a semantic model.

Reply on news.ycombinator.com