4 ms·

Google’s marketing for Chrome and V8 was incredibly effective. We’ve basically forgotten that Mozilla, Adobe and Apple were pushing JS perf long before V8 was r

Google’s marketing for Chrome and V8 was incredibly effective. We’ve basically forgotten that Mozilla, Adobe and Apple were pushing JS perf long before V8 was released. Memory usage of early V8 was atrocious and real world performance was barely improved over Safari and Firefox but Google dominated dev mindshare for a decade.

kragen 7y ago
No, Mozilla and Apple didn't release their JIT engines until after Chrome (though I think at least Apple was working on theirs) and so when Chrome came out JS immediately got about 4x faster, which was a bigger improvement than had happened over the entire previous lifetime of JS. Popular web pages didn't immediately get 4x faster, because they had carefully avoided doing anything in JS if its performance mattered, but JS did. It's true that V8 used a ridiculous amount of RAM, and still does, but its existence made it possible to do things in JS that previously required native code. As for Adobe, they never did much for JS; they tried to get people to use ActionScript instead, which was a statically-typed language with syntactic similarities to JS.
- jashmatthews 7y ago
  Apple built the Sunspider benchmarks in 2007, and along with Mozilla, they made dramatic real world performance improvements before Chrome was even publicly announced. https://webkit.org/blog/152/announcing-sunspider-09/ https://webkit.org/blog/152/announcing-sunspider-09/ https://webkit.org/blog/214/introducing-squirrelfish-extreme/ https://webkit.org/blog/214/introducing-squirrelfish-extreme... Chrome + V8 was already behind in real world performance, not ahead! http://www.satine.org/archives/2008/09/19/squirrelfish-extreme-fastest-javascript-engine-yet/ http://www.satine.org/archives/2008/09/19/squirrelfish-extre... Macromedia (later Adobe) funded a whole bunch of JIT research as the Tamarin Tracing project, which was shared with Firefox as TraceMonkey. The NanoJIT assembly backend was actually shared code.
  - kragen 7y ago
    I guess you're right that TraceMonkey was announced before Chrome was released on 2007-09-02, one day after its inadvertent public announcement. TraceMonkey was announced, though incomplete, more than a week earlier, 2008-08-23: https://brendaneich.com/2008/08/tracemonkey-javascript-lightspeed/ https://brendaneich.com/2008/08/tracemonkey-javascript-light.... SFX, however, was announced later, 2008-09-18. I don't want to piss too much on SunSpider, but unsurprisingly V8 did better on V8’s benchmarks, while SFX and TM did better on SunSpider, once they were eventually released. That's because V8 was written to do well on its benchmarks, presumably, not because the benchmarks were rigged. Certainly they were in accordance with my experience at the time. When Chrome was released, V8 was way ahead of the other browser JS engines at JS performance, partly because it had the first JS JIT. But the other browsers took a year or two to catch up, which they had because it also took websites a few years to move most of their functionality into browser JS. I don't know why you keep emphasizing this “real-world” thing. Are you saying you think nbody and fannkuch are especially realistic benchmarks? You're right though that Tamarin was a JS engine, not just an AS engine. We regret the error.
    - jashmatthews 7y ago
      The point is Mozilla, Apple and Adobe did enormous work on JS before Chrome was released. nbody and Fannkuch are meaningless for real world performance on a client side JS app. V8s benchmarks were widely considered to be unrepresentative of what browsers actually do. Sunspider and derivatives were the most realistic tests at the time and Chrome wasn’t a dramatic improvement. https://johnresig.com/blog/javascript-performance-rundown/ https://johnresig.com/blog/javascript-performance-rundown/ Chrome’s marketing was incredibly successful in getting more people to use a browser better than IE but it didn’t have a dramatic improvement over FF or Safari.
      - kragen 7y ago
        > The point is Mozilla, Apple and Adobe did enormous work on JS before Chrome was released. That's true relative to the work they had done on, for example, Gopher support, but it's not true relative to the work they did after Chrome was released. As I said, JS performance from 1995 to 2008 hadn't increased by even a factor of 4; then Chrome was released in 2008 and it immediately increased by a factor of 4, more than it had increased in the entire previous 13-year history of JS. It's true that there existed other optimization efforts. But they weren't successful, probably because not nearly enough effort was devoted to them. Tamarin Tracing/TraceMonkey was eventually discarded and is not part of SpiderMonkey today, although a different JIT strategy is. (LuaJIT uses the tracing-JIT strategy very successfully, though.) > nbody and Fannkuch are meaningless for real world performance on a client side JS app. V8s benchmarks were widely considered to be unrepresentative of what browsers actually do. Sunspider and derivatives were the most realistic tests I mentioned nbody and fannkuch because they are in SunSpider, so it seems that you are contradicting yourself in addition to, as demonstrated previously, mixing up the historical sequence of how things happened. I had just written a parser generator and an experimental functional language that compiled to JS when Chrome came out, and the performance improvements I saw were in line with the Chrome benchmarks. My experience is not part of Google's marketing.
igouy 7y ago
fwiw n-body 2009 10x JavaScript V8 211.76 secs 100x Ruby 1.9 #2 34 min 106x JavaScript TraceMonkey 36 min http://web.archive.org/web/20090705014239/http://shootout.alioth.debian.org/u32/benchmark.php?test=nbody&lang=all http://web.archive.org/web/20090705014239/http://shootout.al...
- jashmatthews 7y ago
  Real world performance was the opposite story, with Safari's super efficient bytecode VM out performing V8s JIT: http://www.satine.org/archives/2008/09/19/squirrelfish-extreme-fastest-javascript-engine-yet/ http://www.satine.org/archives/2008/09/19/squirrelfish-extre...

kragen 7y ago

No, Mozilla and Apple didn't release their JIT engines until after Chrome (though I think at least Apple was working on theirs) and so when Chrome came out JS immediately got about 4x faster, which was a bigger improvement than had happened over the entire previous lifetime of JS. Popular web pages didn't immediately get 4x faster, because they had carefully avoided doing anything in JS if its performance mattered, but JS did. It's true that V8 used a ridiculous amount of RAM, and still does, but its existence made it possible to do things in JS that previously required native code. As for Adobe, they never did much for JS; they tried to get people to use ActionScript instead, which was a statically-typed language with syntactic similarities to JS.

jashmatthews 7y ago
Apple built the Sunspider benchmarks in 2007, and along with Mozilla, they made dramatic real world performance improvements before Chrome was even publicly announced. https://webkit.org/blog/152/announcing-sunspider-09/ https://webkit.org/blog/152/announcing-sunspider-09/ https://webkit.org/blog/214/introducing-squirrelfish-extreme/ https://webkit.org/blog/214/introducing-squirrelfish-extreme... Chrome + V8 was already behind in real world performance, not ahead! http://www.satine.org/archives/2008/09/19/squirrelfish-extreme-fastest-javascript-engine-yet/ http://www.satine.org/archives/2008/09/19/squirrelfish-extre... Macromedia (later Adobe) funded a whole bunch of JIT research as the Tamarin Tracing project, which was shared with Firefox as TraceMonkey. The NanoJIT assembly backend was actually shared code.
- kragen 7y ago
  I guess you're right that TraceMonkey was announced before Chrome was released on 2007-09-02, one day after its inadvertent public announcement. TraceMonkey was announced, though incomplete, more than a week earlier, 2008-08-23: https://brendaneich.com/2008/08/tracemonkey-javascript-lightspeed/ https://brendaneich.com/2008/08/tracemonkey-javascript-light.... SFX, however, was announced later, 2008-09-18. I don't want to piss too much on SunSpider, but unsurprisingly V8 did better on V8’s benchmarks, while SFX and TM did better on SunSpider, once they were eventually released. That's because V8 was written to do well on its benchmarks, presumably, not because the benchmarks were rigged. Certainly they were in accordance with my experience at the time. When Chrome was released, V8 was way ahead of the other browser JS engines at JS performance, partly because it had the first JS JIT. But the other browsers took a year or two to catch up, which they had because it also took websites a few years to move most of their functionality into browser JS. I don't know why you keep emphasizing this “real-world” thing. Are you saying you think nbody and fannkuch are especially realistic benchmarks? You're right though that Tamarin was a JS engine, not just an AS engine. We regret the error.
  - jashmatthews 7y ago
    The point is Mozilla, Apple and Adobe did enormous work on JS before Chrome was released. nbody and Fannkuch are meaningless for real world performance on a client side JS app. V8s benchmarks were widely considered to be unrepresentative of what browsers actually do. Sunspider and derivatives were the most realistic tests at the time and Chrome wasn’t a dramatic improvement. https://johnresig.com/blog/javascript-performance-rundown/ https://johnresig.com/blog/javascript-performance-rundown/ Chrome’s marketing was incredibly successful in getting more people to use a browser better than IE but it didn’t have a dramatic improvement over FF or Safari.
    - kragen 7y ago
      > The point is Mozilla, Apple and Adobe did enormous work on JS before Chrome was released. That's true relative to the work they had done on, for example, Gopher support, but it's not true relative to the work they did after Chrome was released. As I said, JS performance from 1995 to 2008 hadn't increased by even a factor of 4; then Chrome was released in 2008 and it immediately increased by a factor of 4, more than it had increased in the entire previous 13-year history of JS. It's true that there existed other optimization efforts. But they weren't successful, probably because not nearly enough effort was devoted to them. Tamarin Tracing/TraceMonkey was eventually discarded and is not part of SpiderMonkey today, although a different JIT strategy is. (LuaJIT uses the tracing-JIT strategy very successfully, though.) > nbody and Fannkuch are meaningless for real world performance on a client side JS app. V8s benchmarks were widely considered to be unrepresentative of what browsers actually do. Sunspider and derivatives were the most realistic tests I mentioned nbody and fannkuch because they are in SunSpider, so it seems that you are contradicting yourself in addition to, as demonstrated previously, mixing up the historical sequence of how things happened. I had just written a parser generator and an experimental functional language that compiled to JS when Chrome came out, and the performance improvements I saw were in line with the Chrome benchmarks. My experience is not part of Google's marketing.

igouy 7y ago

fwiw n-body 2009 10x JavaScript V8 211.76 secs 100x Ruby 1.9 #2 34 min 106x JavaScript TraceMonkey 36 min http://web.archive.org/web/20090705014239/http://shootout.alioth.debian.org/u32/benchmark.php?test=nbody&lang=all http://web.archive.org/web/20090705014239/http://shootout.al...

jashmatthews 7y ago
Real world performance was the opposite story, with Safari's super efficient bytecode VM out performing V8s JIT: http://www.satine.org/archives/2008/09/19/squirrelfish-extreme-fastest-javascript-engine-yet/ http://www.satine.org/archives/2008/09/19/squirrelfish-extre...