3 ms·

"6x faster than other browsers at typical JavaScript on websites." Bold claim. http://live.arstechnica.com/apples-october-16-2014-media-event/images/IMG_0250.J

by rikkus 12y ago

"6x faster than other browsers at typical JavaScript on websites." Bold claim. http://live.arstechnica.com/apples-october-16-2014-media-event/images/IMG_0250.JPG http://live.arstechnica.com/apples-october-16-2014-media-eve... Would be interesting to know what the technology is behind this (if the claim is even half true).

Artemis2 12y ago
That's very bold, but also pretty vague given the "average website" mention. I doubt Apple has more developers working on Safari than Google has on V8.
- Zikes 12y ago
  Safari is able to cheat by interfacing more with the OS than V8, which has to be able to run on more platforms. It's the same reason IE beats it out in certain benchmarks.
  - DannyBee 12y ago
    To be honest, this makes near 0 difference in javascript performance, which is entirely good codegen (and making things like DOM traversal really fast). In fact, for average website javascript, the fastest "not horrible" codegen will win, because they run for such short times.
stock_toaster 12y ago
> Would be interesting to know what the technology is behind this (if the claim is even half true). I was thinking maybe the WebKit FTL JIT[1], but that had a claimed 35% increase in performance though.... [1]: https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-jit/ https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-...
bhouston 12y ago
It is FTL Jit? http://www.infoq.com/news/2014/05/safari-webkit-javascript-llvm http://www.infoq.com/news/2014/05/safari-webkit-javascript-l... https://trac.webkit.org/wiki/FTLJIT https://trac.webkit.org/wiki/FTLJIT Or is it something else?
- DannyBee 12y ago
  There's no way that the FTL JIT gets involved on "typical javascript" which wouldn't run long enough. They even say so on the blog post for the FTL JIT: "Websites today serve large amounts of highly dynamic JavaScript code that typically runs for a relatively short time. The dominant cost in such code is the time spent loading it and the memory used to store it. " Instead, it's more likely they have some weird benchmarks that they win on. Everyone has their favorites, and reasons they claim they matter. While it's been about year since i looked, most of them are just not large enough amounts of executing code to be reasonable benchmarks to argue about (they try to increase workloads bby increasing iterations, etc). In truth, i can't fault anyone for the benchmarks they choose (except maybe regexp-dna), most are testcases extracted from the websites/programs they care about. But this does not actually make them good benchmarks to optimize for, just good things to make fast. The difference being, you want to pick representative benchmarks such that if you optimize for them, ideally all the cases you care about are made fast, not just the ones in the benchmarks. For example, regex-dna (part of sunspider) is a benchmark about regular expression searching in DNA sequences (which is "not common" in webapps). To make it fast, most browsers have dedicated regular expression compilers tuned to it. This is pretty much worthless for webapps as a whole (the kinds of regexps involved do not generalize to the ones used in web apps), but it makes sunspider fast. That's exactly what you don't want :)

by rikkus 12y ago

Artemis2 12y ago

That's very bold, but also pretty vague given the "average website" mention. I doubt Apple has more developers working on Safari than Google has on V8.

Zikes 12y ago
Safari is able to cheat by interfacing more with the OS than V8, which has to be able to run on more platforms. It's the same reason IE beats it out in certain benchmarks.
- DannyBee 12y ago
  To be honest, this makes near 0 difference in javascript performance, which is entirely good codegen (and making things like DOM traversal really fast). In fact, for average website javascript, the fastest "not horrible" codegen will win, because they run for such short times.

stock_toaster 12y ago

> Would be interesting to know what the technology is behind this (if the claim is even half true). I was thinking maybe the WebKit FTL JIT[1], but that had a claimed 35% increase in performance though.... [1]: https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-jit/ https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-...

bhouston 12y ago

It is FTL Jit? http://www.infoq.com/news/2014/05/safari-webkit-javascript-llvm http://www.infoq.com/news/2014/05/safari-webkit-javascript-l... https://trac.webkit.org/wiki/FTLJIT https://trac.webkit.org/wiki/FTLJIT Or is it something else?

DannyBee 12y ago
There's no way that the FTL JIT gets involved on "typical javascript" which wouldn't run long enough. They even say so on the blog post for the FTL JIT: "Websites today serve large amounts of highly dynamic JavaScript code that typically runs for a relatively short time. The dominant cost in such code is the time spent loading it and the memory used to store it. " Instead, it's more likely they have some weird benchmarks that they win on. Everyone has their favorites, and reasons they claim they matter. While it's been about year since i looked, most of them are just not large enough amounts of executing code to be reasonable benchmarks to argue about (they try to increase workloads bby increasing iterations, etc). In truth, i can't fault anyone for the benchmarks they choose (except maybe regexp-dna), most are testcases extracted from the websites/programs they care about. But this does not actually make them good benchmarks to optimize for, just good things to make fast. The difference being, you want to pick representative benchmarks such that if you optimize for them, ideally all the cases you care about are made fast, not just the ones in the benchmarks. For example, regex-dna (part of sunspider) is a benchmark about regular expression searching in DNA sequences (which is "not common" in webapps). To make it fast, most browsers have dedicated regular expression compilers tuned to it. This is pretty much worthless for webapps as a whole (the kinds of regexps involved do not generalize to the ones used in web apps), but it makes sunspider fast. That's exactly what you don't want :)