Mozilla's JM crosses Apple's Nitro threshold
arewefastyet.com
Mozilla's JM crosses Apple's Nitro threshold
1–10 of 37 posts
Re: Mozilla's JM crosses Apple's Nitro threshold
#2Only x86, though. x64 isn't there yet. http://arewefastyet.com/?machine=4
Re: Mozilla's JM crosses Apple's Nitro threshold
#3One possible takeaway from these graphs is the urgent need for better JavaScript benchmarks. Both SunSpider and the V8 benchmarks are sets of microbenchmarks and the difference between them is enormous: JM+TM is significantly faster than plain JM on V8 but is a little slower on SunSpider. The fact that the conclusions can vary so greatly among these two (both deeply flawed) benchmark suites suggests that the true "real-world" performance of the engines is all but entirely unmeasured. Which loads Gmail fastest? That would be a step in the right direction.
Re: Mozilla's JM crosses Apple's Nitro threshold
#4One possible takeaway from these graphs is the urgent need for better JavaScript benchmarks. Both SunSpider and the V8 benchmarks are sets of microbenchmarks and the difference between them is enormous: JM+TM is significantly faster than plain JM on V8 but is a little slower on SunSpider. The fact that the conclusions can vary so greatly among these two (both deeply flawed) benchmark suites suggests that the true "re…
Here's an alternative: http://krakenbenchmark.mozilla.com/kraken-1.0/driver.html
I have to agree, that things like machine translated scheme and OS scheduling are not representative of real world applications. (Part of the V8 suite: http://v8.googlecode.com/svn/data/benchmarks/v6/run.html - specifically Richards, and EarleyBoyer)
Re: Mozilla's JM crosses Apple's Nitro threshold
#5This appears to be what got them there: http://andreasgal.wordpress.com/2010/10/13/compartments/
Also worth noting, there is no longer a gigantic "NO" down at the bottom of the page. :)
Re: Mozilla's JM crosses Apple's Nitro threshold
#6One possible takeaway from these graphs is the urgent need for better JavaScript benchmarks. Both SunSpider and the V8 benchmarks are sets of microbenchmarks and the difference between them is enormous: JM+TM is significantly faster than plain JM on V8 but is a little slower on SunSpider. The fact that the conclusions can vary so greatly among these two (both deeply flawed) benchmark suites suggests that the true "re…
About a month ago, Mozilla released their' "Kraken" benchmark suite, designed to better reflect what actual web-apps actually do:
http://blog.mozilla.com/rob-sayre/2010/09/14/release-the-kraken/
http://weblogs.mozillazine.org/asa/archives/2010/09/javascript_performan.htmlRe: Mozilla's JM crosses Apple's Nitro threshold
#7What actually surprises me about this is just how much faster V8 was (and really, still is) compared to all of the others. It also looks like they're starting to hit a point of diminishing returns. Here's hoping they're not!
Re: Mozilla's JM crosses Apple's Nitro threshold
#8One possible takeaway from these graphs is the urgent need for better JavaScript benchmarks. Both SunSpider and the V8 benchmarks are sets of microbenchmarks and the difference between them is enormous: JM+TM is significantly faster than plain JM on V8 but is a little slower on SunSpider. The fact that the conclusions can vary so greatly among these two (both deeply flawed) benchmark suites suggests that the true "re…
Here's an alternative: http://krakenbenchmark.mozilla.com/kraken-1.0/driver.html I have to agree, that things like machine translated scheme and OS scheduling are not representative of real world applications. (Part of the V8 suite: http://v8.googlecode.com/svn/data/benchmarks/v6/run.html - specifically Richards, and EarleyBoyer)
Keep in mind that V8 is not only running in the browser, but has completely different usecases as well (see node.js).
That it's a javascript benchmark only means that.. it's used by google to finetune their code.. not created to compare javascript in browsers among several different browsers.
Re: Mozilla's JM crosses Apple's Nitro threshold
#9Earlier quoted context omitted.
Here's an alternative: http://krakenbenchmark.mozilla.com/kraken-1.0/driver.html I have to agree, that things like machine translated scheme and OS scheduling are not representative of real world applications. (Part of the V8 suite: http://v8.googlecode.com/svn/data/benchmarks/v6/run.html - specifically Richards, and EarleyBoyer)
Keep in mind that V8 is not only running in the browser, but has completely different usecases as well (see node.js). That it's a javascript benchmark only means that.. it's used by google to finetune their code.. not created to compare javascript in browsers among several different browsers.
And yet that's what people seem to like using it for.
I still don't see why machine translated scheme is a good benchmark for fine tuning code. Javascript is a fine language to work in - especially if you are wanting to use it for things other than a browser (then you must really like it!).
Re: Mozilla's JM crosses Apple's Nitro threshold
#10Earlier quoted context omitted.
Keep in mind that V8 is not only running in the browser, but has completely different usecases as well (see node.js). That it's a javascript benchmark only means that.. it's used by google to finetune their code.. not created to compare javascript in browsers among several different browsers.
And yet that's what people seem to like using it for. I still don't see why machine translated scheme is a good benchmark for fine tuning code. Javascript is a fine language to work in - especially if you are wanting to use it for things other than a browser (then you must really like it!).
I haven't seen the code but based on the description it's a benchmark that was originally in scheme and ported to javascript.. sounds fine to me.
And "kernel simulation benchmark" may have a usecase too, just because you can't think of it, doesn't mean it isn't there ;)
I can think of tests for scheduling, threading, asynchronous code, I/O when i think of "kernel simulation".
Again, people like to use V8benchmarks, when it's not made for browser comparisons. The fact that it's often used only shows that there is a lack of a real cross browser benchmar suite.