<br><br><div class="gmail_quote">On Sat, Jul 4, 2009 at 3:27 PM, Maciej Stachowiak <span dir="ltr">&lt;<a href="mailto:mjs@apple.com">mjs@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><br><div><div class="im"><div>On Jul 4, 2009, at 11:47 AM, Mike Belshe wrote:</div><br><blockquote type="cite"><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse"><div>
I&#39;d like to understand what&#39;s going to happen with SunSpider in the future.  Here is a set of questions and criticisms.  I&#39;m interested in how these can be addressed.</div> <div><br></div><div>There are 3 areas I&#39;d like to see improved in SunSpider, some of which we&#39;ve discussed before:</div>
<div><br></div><div>#1: SunSpider is currently version 0.9.  Will SunSpider ever change?  Or is it static?</div> <div>I believe that benchmarks need to be able to move with the times.  As JS Engines change and improve, and as new areas are needed to be benchmarked, we need to be able to roll the version, fix bugs, and benchmark new features.  The SunSpider version has not changed for ~2yrs.  How can we change this situation?  Are there plans for a new version already underway?</div>
</span></blockquote><div><br></div></div><div>I&#39;ve been thinking about updating SunSpider for some time. There are two categories of changes I&#39;ve thought about:</div><div><br></div><div>1) Quality-of-implementation changes to the harness. Among these might be ability to use the harness with multiple test sets. That would be 1.0.</div>
<div><br></div><div>2) An updated set of tests - the current tests are too short, and don&#39;t adequately cover some areas of the language. I&#39;d like to make the tests take at least 100ms each on modern browsers on recent hardware. I&#39;d also be interested in incorporating some of the tests from the v8 benchmark suite, if the v8 developers were ok with this. That would be SunSpider 2.0.</div>
<div><br></div><div>The reason I&#39;ve been hesitant to make any changes is that the press and independent analysts latched on to SunSpider as a way of comparing JavaScript implementations. Originally, it was primarily intended to be a tool for the WebKit team to help us make our JavaScript faster. However, now that third parties are relying it, there are two things I want to be really careful about:</div>
<div><br></div><div>a) I don&#39;t want to invalidate people&#39;s published data, so significant changes to the test content would need to be published as a clearly separate version.</div><div><br></div><div>b) I want to avoid accidentally or intentionally making changes that are biased in favor of Safari or WebKit-based browsers in general, or that even give that impression. That would hurt the test&#39;s credibility. When we first made SunSpider, Safari actually didn&#39;t do that great on it, which I think helped people believe that the test wasn&#39;t designed to make us look good, it was designed to be a relatively unbiased comparison.</div>
<div><br></div><div>Thus, any change to the content would need to be scrutinized in some way. I&#39;m not sure what it would take to get widespread agreement that a 2.0 content set is fair, but I agree it&#39;s time to make one soonish (before the end of the year probably). Thoughts on this are welcome.</div>
<div class="im"><br><blockquote type="cite"><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse"> <div><br></div><div>#2: Use of summing as a scoring mechanism is problematic</div><div>Unfortunately, the sum-based scoring techniques do not withstand the test of time as browsers improve.  When the benchmark was first introduced, each test was equally weighted and reasonably large.  Over time, however, the test becomes dominated by the slowest tests - basically the weighting of the individual tests is variable based on the performance of the JS engine under test.  Today&#39;s engines spend ~50% of their time on just string and date tests.  The other tests are largely irrelevant at this point, and becoming less relevant every day.  Eventually many of the tests will take near-zero time, and the benchmark will have to be scrapped unless we figure out a better way to score it.  Benchmarking research which long pre-dates SunSpider confirms that geometric means provide a better basis for comparison:  <span style="font-family:calibri, tahoma, arial, sans-serif;font-size:16px;color:rgb(51, 51, 51);line-height:22px"><a href="http://portal.acm.org/citation.cfm?id=5673" rel="nofollow" style="color:rgb(162, 66, 124);text-decoration:none" target="_blank">http://portal.acm.org/citation.cfm?id=5673</a> <span style="color:rgb(0, 0, 0);font-family:arial;font-size:small;line-height:normal">Can future versions of the SunSpider driver be made so that they won&#39;t become irrelevant over time?</span></span></div>
</span></blockquote><div><br></div></div><div>Use of summation instead of geometric mean was a considered choice. The intent is that engines should focus on whatever is slowest. A simplified example: let&#39;s say it&#39;s estimated that likely workload in the field will consist of 50% Operation A, and 50% of Operation B, and I can benchmark them in isolation. Now let&#39;s say implementation in Foo these operations are equally fast, while in implementation Bar, Operation A is 4x as fast as in Foo, while Operation B is 4x as slow as in Foo. A comparison by geometric means would imply that Foo and Bar are equally good, but Bar would actually be twice as slow on the intended workload.</div>
</div></div></blockquote><div><br></div><div>BTW - the way to work around this is to have enough sub-benchmarks such that this just doesn&#39;t happen.  If we have the right test coverage, it seems unlikely to me that a code change would dramatically improve exactly one test at an exponential expense of exactly one other test.  I&#39;m not saying it is impossible - just that code changes don&#39;t generally cause that behavior.  To combat this we can implement a broader base of benchmarks as well as longer-running tests that are not &quot;too micro&quot;.</div>
<div><br></div><div>This brings up another problem with summation.  The only case where summation &#39;works&#39; is if the benchmark workload is *the right workload* to measure what browsers do.  In this case, your argument that slowing down one portion of the benchmark at the expense of another should be measured is reasonable.  But, I think the benchmark should be capable of adding more benchmarks over time - potentially even covering corner cases and less-frequented code.  These types of micro benchmarks have no place in a summation based scoring model because we can&#39;t weight them accurately.  Using geometric means, I could still weight the low-priority benchmark at 1/2 (or whatever) the weight of other benchmarks and have meaningful overall scores.  However, in a sum based model, a browser which does really badly on one low-priority test can get a horrible score even if it is better than all the other browsers every other benchmarks.</div>
<div><br></div><div>Mike</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div></div><div><br></div>
<div>Of course, doing this requires a judgment call on reasonable balance of different kinds of code, and that balance needs to be re-evaluated periodically. But tests based on geometric means also make an implied judgment call. The operations comprising each individual test are added linearly. The test then judges that these particular combinations are each equally important.</div>
<div class="im"><div><br></div><br><blockquote type="cite"><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse"> <div><br></div><div>#3: The SunSpider harness has a variance problem due to CPU power savings modes.</div>
<div>Because the test runs a tiny amount of Javascript (often under 10ms) followed by a 500ms sleep, CPUs will go into power savings modes between test runs.  This radically changes the performance measurements and makes it so that comparison between two runs is dependent on the user&#39;s power savings mode.  To demonstrate this, run SunSpider on two machines- one with the Windows &quot;balanced&quot; (default) setting for power, and then again with &quot;high performance&quot;.  It&#39;s easy to see skews of 30% between these two modes.  I think we should change the test harness to avoid such accidental effects.</div>
 <div><br></div><div>(BTW - if you change SunSpider&#39;s sleep from 500ms  to 10ms, the test runs in just a few seconds.  It is unclear to me why the pauses are so large.  My browser gets a 650ms score, so run 5 times, that test should take ~3000ms.  But due to the pauses, it takes over 1 minute to run test, leaving the CPU ~96% idle).</div>
</span></blockquote><div><br></div></div><div>I think the pauses were large in an attempt to get stable, repeatable results, but are probably longer than necessary to achieve this. I agree with you that the artifacts in &quot;balanced&quot; power mode are a problem. Do you know what timer thresholds avoid the effect? I think this would be a reasonable &quot;1.0&quot; kind of change.</div>
<div class="im"><br><blockquote type="cite"><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse"> <div><br></div><div>Possible solution:</div><div>The dromaeo test suite already incorporates the SunSpider individual tests under a new benchmark harness which fixes all 3 of the above issues.   Thus, one approach would be to retire SunSpider 0.9 in favor of Dromaeo.   <a href="http://dromaeo.com/?sunspider" style="color:rgb(42, 93, 176)" target="_blank">http://dromaeo.com/?sunspider</a>  Dromaeo has also done a lot of good work to ensure statistical significance of the results.  Once we have a better benchmarking framework, it would be great to build a new microbenchmark mix which more realistically exercises today&#39;s JavaScript.</div>
 </span></blockquote></div></div><br><div>In my experience, Dromaeo gives much significantly more variable results than SunSpider. I don&#39;t entirely trust the test to avoid interference from non-JS browser code executing, and I am not sure their statistical analysis is sound. In addition, using sum instead of geometric mean was a considered choice. It would be easy to fix in SunSpider if we wanted to, but I don&#39;t think we should. Also, I don&#39;t think Dromaeo has a pure command-line harness, and it depends on the server so it can&#39;t easily be used offline or with the network disabled.</div>
<div><br></div><div>Many things about the way the SunSpider harness works are designed to give precise and repeatable results. That&#39;s very important to us, because when doing performance work we often want to gauge the impact of changes that have a small performance effect. With Dromaeo there is too much noise to do this effectively, at least in my past experience.</div>
<div><br></div><div>Regards,</div><div>Maciej</div><font color="#888888"><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></font></div></blockquote></div><br>