7 ms·

The difference is that Javascript is about the worst possible IL for a compiler to compile down to. Yeah you can recover some of the speed by spending man years

by jules 16y ago

The difference is that Javascript is about the worst possible IL for a compiler to compile down to. Yeah you can recover some of the speed by spending man years on making Javascript execute somewhat fast. As a bytecode you wouldn't use a bytecode that is targeted at handling Javascript constructs. You'd use a bytecode that, for example, supports machine integers (unlike Javascript). Something that allows you to allocate objects, rather than string indexed hash tables. Something that allows you to allocate an array of floats, rather than an array of boxed floats.

InclinedPlane 16y ago
"Worst possible"? Sub-optimal perhaps, but Javascript is becoming very fast in the browser, perhaps it's not such a bad choice after all.
- jules 16y ago
  With enough effort you can put lipstick on a pig. But really, an IL that doesn't support integers? An IL where a member field access may involve looking up a string in a hash table instead of being a single machine instruction? Propose that as an IL to a compiler guy and they'll laugh at you. Javascript is an historical accident. Let's look at some alternatives if history was different: - Scheme: this would have been a much better choice, because it supports integers and has a compact object representation instead of representing everything with hash tables. Bad point: all objects are boxed (like in JS). Good point: tail calls are handy when compiling all kinds of control structures. - Java: As an IL to compile down to this would have been better than Javascript. Good points on top of Scheme: unboxed primitive types, static typing means fewer runtime checks. Bad point: lack of tail calls. - ML: excellent choice: has both unboxed primitives and tail calls. I challenge you to find a language that would have been a worse choice than Javascript. It may turn out that by working really hard on smart runtimes and compilers you can get OKish performance out of Javascript in some cases, but that doesn't mean that it's a good choice for an intermediate language. A ML compiler that just translates to LLVM IL as simply as possible without doing any optimizations itself will easily beat the highly optimized Javascript engines we have today.
  - Robin_Message 16y ago
    Just to note though: Javascript in fact doesn't require representing objects as hash tables. For example, the V8 javascript engine represents objects as instances of classes, more or less exactly how C++ would do it (the build the class definitions automatically in the background.) You are right on integers though, and other types of memory block in general, they are trickier to fix in a javascript engine. Surely the best IL is LLVM IL though, since it was designed so everything can compile down to it.
    - silentbicycle 16y ago
      > Just to note though: Javascript in fact doesn't require representing objects as hash tables. For example, the V8 javascript engine represents objects as instances of classes, more or less exactly how C++ would do it (the build the class definitions automatically in the background.) That sounds like what Self does, too. See the excellent paper, "An Efficient Implementation of SELF" (http://selflanguage.org/documentation/published/implementation.html http://selflanguage.org/documentation/published/implementati...). The Self bibliography page (http://selflanguage.org/documentation/published/index.html http://selflanguage.org/documentation/published/index.html) has a lot of other content applicable to dynamic languages in general, too.
      - wmf 16y ago
        Self and V8 are connected through Lars Bak. http://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer) http://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer)
        silentbicycle 16y ago
        He worked on Beta / Mjølner, too. Neat!
    - jules 16y ago
      Yep, sophisticated implementations try to infer the patterns in which objects occur and then dynamically generate classes for them. However this is not without problems, because if you assign to a new slot then you need to change the object's class, it needs to gracefully degrade to when the objects are used as hash tables, etc. LLVM IL would be excellent for speed. The problem is that it's not memory safe (i.e. it allows reading and writing to arbitrary memory locations). NativeClient at Google is trying to solve that. http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/
wmf 16y ago
As a bytecode you wouldn't use a bytecode that is targeted at handling Javascript constructs. So now you're asking the browsers to support two different VMs; one for JS and another one. Standardizing bytecode for JS (perhaps based on the existing Nitro or JagerMonkey bytecode) would be much less work.
ianb 16y ago
The browser provides very high level constructs (e.g., the DOM), handling numbers quickly is uninteresting and would be a poor direction for optimization. While I think an appropriate VM could be something interesting, I doubt an appropriate VM in this case would look like the JVM.

by jules 16y ago

InclinedPlane 16y ago

"Worst possible"? Sub-optimal perhaps, but Javascript is becoming very fast in the browser, perhaps it's not such a bad choice after all.

jules 16y ago
With enough effort you can put lipstick on a pig. But really, an IL that doesn't support integers? An IL where a member field access may involve looking up a string in a hash table instead of being a single machine instruction? Propose that as an IL to a compiler guy and they'll laugh at you. Javascript is an historical accident. Let's look at some alternatives if history was different: - Scheme: this would have been a much better choice, because it supports integers and has a compact object representation instead of representing everything with hash tables. Bad point: all objects are boxed (like in JS). Good point: tail calls are handy when compiling all kinds of control structures. - Java: As an IL to compile down to this would have been better than Javascript. Good points on top of Scheme: unboxed primitive types, static typing means fewer runtime checks. Bad point: lack of tail calls. - ML: excellent choice: has both unboxed primitives and tail calls. I challenge you to find a language that would have been a worse choice than Javascript. It may turn out that by working really hard on smart runtimes and compilers you can get OKish performance out of Javascript in some cases, but that doesn't mean that it's a good choice for an intermediate language. A ML compiler that just translates to LLVM IL as simply as possible without doing any optimizations itself will easily beat the highly optimized Javascript engines we have today.
- Robin_Message 16y ago
  Just to note though: Javascript in fact doesn't require representing objects as hash tables. For example, the V8 javascript engine represents objects as instances of classes, more or less exactly how C++ would do it (the build the class definitions automatically in the background.) You are right on integers though, and other types of memory block in general, they are trickier to fix in a javascript engine. Surely the best IL is LLVM IL though, since it was designed so everything can compile down to it.
  - silentbicycle 16y ago
    > Just to note though: Javascript in fact doesn't require representing objects as hash tables. For example, the V8 javascript engine represents objects as instances of classes, more or less exactly how C++ would do it (the build the class definitions automatically in the background.) That sounds like what Self does, too. See the excellent paper, "An Efficient Implementation of SELF" (http://selflanguage.org/documentation/published/implementation.html http://selflanguage.org/documentation/published/implementati...). The Self bibliography page (http://selflanguage.org/documentation/published/index.html http://selflanguage.org/documentation/published/index.html) has a lot of other content applicable to dynamic languages in general, too.
    - wmf 16y ago
      Self and V8 are connected through Lars Bak. http://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer) http://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer)
      - silentbicycle 16y ago
        He worked on Beta / Mjølner, too. Neat!
  - jules 16y ago
    Yep, sophisticated implementations try to infer the patterns in which objects occur and then dynamically generate classes for them. However this is not without problems, because if you assign to a new slot then you need to change the object's class, it needs to gracefully degrade to when the objects are used as hash tables, etc. LLVM IL would be excellent for speed. The problem is that it's not memory safe (i.e. it allows reading and writing to arbitrary memory locations). NativeClient at Google is trying to solve that. http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/

wmf 16y ago

As a bytecode you wouldn't use a bytecode that is targeted at handling Javascript constructs. So now you're asking the browsers to support two different VMs; one for JS and another one. Standardizing bytecode for JS (perhaps based on the existing Nitro or JagerMonkey bytecode) would be much less work.

ianb 16y ago

The browser provides very high level constructs (e.g., the DOM), handling numbers quickly is uninteresting and would be a poor direction for optimization. While I think an appropriate VM could be something interesting, I doubt an appropriate VM in this case would look like the JVM.