5 ms·

unreal. how much theoretical headroom is left to optimize js compiler performance? I had assumed we were reaching some theoretical upper-bound because all majo

by ashot 16y ago

unreal. how much theoretical headroom is left to optimize js compiler performance? I had assumed we were reaching some theoretical upper-bound because all major frameworks were on par in terms of performance.

jerf 16y ago
To a first approximation, my answer would be something like http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=luajit&lang2=v8 http://shootout.alioth.debian.org/u32/benchmark.php?test=all... . That's not necessarily the whole answer and I imagine JS can't ever quite go that fast. But still....
- Raphael_Amiard 16y ago
  > and I imagine JS can't ever quite go that fast I'm not the most knowledgeable person on the subject, but from what i understand, there is no theoretical reason that JS couldn't go that fast. The two languages are more similar than they are different, even if JavaScript is quite more complex. I remember Mike Pall saying something similar in an LTU thread some time ago.
  - grayrest 16y ago
    > I remember Mike Pall saying something similar in an LTU thread some time ago. He did and the mozilla guys pointed out how this wasn't the case. The languages are very similar but JS has some weird semantics due to how things are scoped. (ref. the Chakra optimization brouhaha a month ago)
    - jules 16y ago
      Going the other way: what small changes in languages can we make to make them much more optimize-able while at the same time keeping (most of) the expressiveness?
      - grayrest 16y ago
        It's a tradeoff between compatibility with existing JS versus perf/capability enhancements. The ECMAScript committee goes back and forth on this topic. The biggest stride in that direction was strict mode, which is intended to catch most of the low hanging fruit. I know Brendan Eich has mentioned a number of things that could change to get the language faster. I don't, however, know if I read it all in one place or I'm combining nultiple one-off examples. I'm not confident enough in my memory to write out a probably incorrect list of things I remember. Here's a list of the various things I've read from Brendan in case you're interested in tracking it down: http://lambda-the-ultimate.org/node/3851#comment-57671 http://lambda-the-ultimate.org/node/3851#comment-57671 This is the LtU thread my previous comment referred to. It's a large (and fantastic!) thread, but I believe that comment and children are the most direct comments back and forth between Mike and Brendan. Andreas Gal is also on the thread and from Mozilla. http://www.aminutewithbrendan.com/ http://www.aminutewithbrendan.com/ Brendan's weekly JS podcast. They're relatively accessible and generally cover a lot of area. A good way to get in the language zeitgeist. http://brendaneich.com/ http://brendaneich.com/ Brendan's blog, mostly focuses on ES Harmony stuff and Mozilla specific topics.
- SwellJoe 16y ago
  Would this imply that Lua has reached some pinnacle of speed and can't go any faster? That seems to be a side effect of your statement. I'm not familiar with Lua, beyond reading an article or two about it, but does its simplicity imply some sort of maximal efficiency? Are the developers behind Lua simply the best programmers in the world and already have everything figured out with regard to optimizing a JIT? I'm not arguing with you...it does seem like that's a reasonable goal for JavaScript JITs to strive for in the near future. But, it doesn't really answer the question of how much better performance can get (in JavaScript or Lua or any other language). Past performance is not necessarily indicative of future performance when so many people are working on the problem from so many angles.
  - jws 16y ago
    Browsing the alternatives in the shootout dataset, LuaJIT appears to be the fastest of the dynamic languages and feature-wise matches Javascript well enough to be a fair benchmark. You can gain another factor of 2 or so in speed by going to a static language like C or Ada, but that isn't really a fair comparison and you can see the price paid in code size. The good news for the web is that there may be another factor of 2 to 3 available for Javascript speedup.
    - eru 16y ago
      You can also go to a static language like OCaml. They don't blow up your code size, but are also fast.
  - jerf 16y ago
    LuaJIT is a major outlier, probably the most surprising result in the entire shootout. In point of fact there isn't much more LuaJIT can do without flat-out exceeding C, which isn't going to happen on the shootout to any significant degree any time soon. (The conventional "JIT can be faster than compiled code" argument doesn't apply because the problems are accurately known by the author of the shootout benchmark code in advance, so, for instance, if there's a speed advantage to sticking with 'char' where you might have been tempted to write 'int', the C shootout code already does that.)
- kragen 16y ago
  I think http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=gcc&lang2=v8 http://shootout.alioth.debian.org/u32/benchmark.php?test=all... is probably a better ceiling. LuaJIT is fantastic and already generates better code than GCC in some cases, but in many others it does not. There's no theoretical limit to how close a compiler can come to a programmer when it comes to generating machine code to do a particular well-defined task.
seanalltogether 16y ago
Javascript execution is very rarely the bottleneck on webpages. The bottleneck is almost 90% render speed of dom updates.

by ashot 16y ago

jerf 16y ago

To a first approximation, my answer would be something like http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=luajit&lang2=v8 http://shootout.alioth.debian.org/u32/benchmark.php?test=all... . That's not necessarily the whole answer and I imagine JS can't ever quite go that fast. But still....

Raphael_Amiard 16y ago
> and I imagine JS can't ever quite go that fast I'm not the most knowledgeable person on the subject, but from what i understand, there is no theoretical reason that JS couldn't go that fast. The two languages are more similar than they are different, even if JavaScript is quite more complex. I remember Mike Pall saying something similar in an LTU thread some time ago.
- grayrest 16y ago
  > I remember Mike Pall saying something similar in an LTU thread some time ago. He did and the mozilla guys pointed out how this wasn't the case. The languages are very similar but JS has some weird semantics due to how things are scoped. (ref. the Chakra optimization brouhaha a month ago)
  - jules 16y ago
    Going the other way: what small changes in languages can we make to make them much more optimize-able while at the same time keeping (most of) the expressiveness?
    - grayrest 16y ago
      It's a tradeoff between compatibility with existing JS versus perf/capability enhancements. The ECMAScript committee goes back and forth on this topic. The biggest stride in that direction was strict mode, which is intended to catch most of the low hanging fruit. I know Brendan Eich has mentioned a number of things that could change to get the language faster. I don't, however, know if I read it all in one place or I'm combining nultiple one-off examples. I'm not confident enough in my memory to write out a probably incorrect list of things I remember. Here's a list of the various things I've read from Brendan in case you're interested in tracking it down: http://lambda-the-ultimate.org/node/3851#comment-57671 http://lambda-the-ultimate.org/node/3851#comment-57671 This is the LtU thread my previous comment referred to. It's a large (and fantastic!) thread, but I believe that comment and children are the most direct comments back and forth between Mike and Brendan. Andreas Gal is also on the thread and from Mozilla. http://www.aminutewithbrendan.com/ http://www.aminutewithbrendan.com/ Brendan's weekly JS podcast. They're relatively accessible and generally cover a lot of area. A good way to get in the language zeitgeist. http://brendaneich.com/ http://brendaneich.com/ Brendan's blog, mostly focuses on ES Harmony stuff and Mozilla specific topics.
SwellJoe 16y ago
Would this imply that Lua has reached some pinnacle of speed and can't go any faster? That seems to be a side effect of your statement. I'm not familiar with Lua, beyond reading an article or two about it, but does its simplicity imply some sort of maximal efficiency? Are the developers behind Lua simply the best programmers in the world and already have everything figured out with regard to optimizing a JIT? I'm not arguing with you...it does seem like that's a reasonable goal for JavaScript JITs to strive for in the near future. But, it doesn't really answer the question of how much better performance can get (in JavaScript or Lua or any other language). Past performance is not necessarily indicative of future performance when so many people are working on the problem from so many angles.
- jws 16y ago
  Browsing the alternatives in the shootout dataset, LuaJIT appears to be the fastest of the dynamic languages and feature-wise matches Javascript well enough to be a fair benchmark. You can gain another factor of 2 or so in speed by going to a static language like C or Ada, but that isn't really a fair comparison and you can see the price paid in code size. The good news for the web is that there may be another factor of 2 to 3 available for Javascript speedup.
  - eru 16y ago
    You can also go to a static language like OCaml. They don't blow up your code size, but are also fast.
- jerf 16y ago
  LuaJIT is a major outlier, probably the most surprising result in the entire shootout. In point of fact there isn't much more LuaJIT can do without flat-out exceeding C, which isn't going to happen on the shootout to any significant degree any time soon. (The conventional "JIT can be faster than compiled code" argument doesn't apply because the problems are accurately known by the author of the shootout benchmark code in advance, so, for instance, if there's a speed advantage to sticking with 'char' where you might have been tempted to write 'int', the C shootout code already does that.)
kragen 16y ago
I think http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=gcc&lang2=v8 http://shootout.alioth.debian.org/u32/benchmark.php?test=all... is probably a better ceiling. LuaJIT is fantastic and already generates better code than GCC in some cases, but in many others it does not. There's no theoretical limit to how close a compiler can come to a programmer when it comes to generating machine code to do a particular well-defined task.

seanalltogether 16y ago

Javascript execution is very rarely the bottleneck on webpages. The bottleneck is almost 90% render speed of dom updates.