3 ms·

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 cl

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.
- jashmatthews 7y ago
  Safari perf had already improved more than 4x with the move from AST Interpretation to a register based bytecode VM with SquirrelFish. This happened before Chrome. I’m working on a tracing JIT for Ruby at the moment partially inspired by LuaJIT. Fingers crossed it’ll be published research this year! Right, but the Sunspider benchmark also tested strings, regex and date manipulation. V8s original benchmarks didn’t. Performance on stuff like a parser generator was way up, but it didn’t run jQuery based Ajax sites any faster.
  - kragen 7y ago
    Best of luck with that! I look forward to seeing it.

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.

jashmatthews 7y ago
Safari perf had already improved more than 4x with the move from AST Interpretation to a register based bytecode VM with SquirrelFish. This happened before Chrome. I’m working on a tracing JIT for Ruby at the moment partially inspired by LuaJIT. Fingers crossed it’ll be published research this year! Right, but the Sunspider benchmark also tested strings, regex and date manipulation. V8s original benchmarks didn’t. Performance on stuff like a parser generator was way up, but it didn’t run jQuery based Ajax sites any faster.
- kragen 7y ago
  Best of luck with that! I look forward to seeing it.