[deleted]
Traditional JavaScript benchmarks
11–20 of 43 posts
Re: Traditional JavaScript benchmarks
#12[deleted]
Re: Traditional JavaScript benchmarks
#13[deleted]
Re: Traditional JavaScript benchmarks
#14[deleted]
Re: Traditional JavaScript benchmarks
#15I'm going to say something about js benchmarks.
Every time you say "Firefox sucks because it's slow" someone will come and say "that is false, look at these js benchmarks! We're in line with other browsers!". But then those benchmarks omit the stuff that actually matters, stuff that Firefox simply sucks at, like DOM manipulation..
Re: Traditional JavaScript benchmarks
#16The part about optimizing for the Mandreel-test by skipping some initialization has gone full circle, as this is now exploited by developers. https://github.com/nolanlawson/optimize-js
Re: Traditional JavaScript benchmarks
#17All of these changes that the author is making are changes that the compiler should be generating. Unless you work in the embeded systems I don't expect people to have done or needed the % 2048 trick.
The author is writing the compiler (and modifying it to make these changes). What do you mean exactly?
I'm just wowed by this not already being part of V8. What else have they been doing?
I know that V8 has some amazing performance characteristics and if they aren't from doing things that C compilers have been doing for years, then what are these speed boosts coming from?
Re: Traditional JavaScript benchmarks
#18Earlier quoted context omitted.
The author is writing the compiler (and modifying it to make these changes). What do you mean exactly?
I'm just wowed by this not already being part of V8. What else have they been doing? I know that V8 has some amazing performance characteristics and if they aren't from doing things that C compilers have been doing for years, then what are these speed boosts coming from?
It might help to read a bit more closely. A lot of the optimisations being discussed were already added years ago; the point is that they are not as useful in real-world usage as they are in benchmarks (or, in fact, disadvantageous).
JIT compiling a highly dynamic language is quite a different task than AOT compiling a statically typed language. Bit-twiddling tricks are unlikely to be the biggest concern. Try starting with the obvious like https://en.wikipedia.org/wiki/Just-in-time_compilation
Re: Traditional JavaScript benchmarks
#19I'm going to say something about js benchmarks. Every time you say "Firefox sucks because it's slow" someone will come and say "that is false, look at these js benchmarks! We're in line with other browsers!". But then those benchmarks omit the stuff that actually matters, stuff that Firefox simply sucks at, like DOM manipulation..
could you cite an example?
Re: Traditional JavaScript benchmarks
#20I'm going to say something about js benchmarks. Every time you say "Firefox sucks because it's slow" someone will come and say "that is false, look at these js benchmarks! We're in line with other browsers!". But then those benchmarks omit the stuff that actually matters, stuff that Firefox simply sucks at, like DOM manipulation..
http://dromaeo.com/ benchmarks show Firefox beating Chrome for me. What's it missing?