Continuing on with the series, in the post, allow me to run you through the first example of how JS engines can and do game benchmarks by showing you a few examples from SunSpider.
Join the DZone community and get the full member experience.Join For Free
so, in the post, allow me to run you through the first example of how js engines can and do game benchmarks.
the notorious sunspider examples
after the first loop iteration and will remain
for the next 599999 iterations. so once you get this to good performance, i.e. anything below 5ms on decent hardware, you can start gaming this benchmark by trying to recognize that only the first iteration of the loop is necessary, while the remaining iterations are a waste of time (i.e. dead code after
is either a regular property of the global object or not present before you execute the script, there must be no interceptor on the global object or it’s prototypes, etc., but if you really want to win this benchmark, and you are willing to go all in, then you can execute this test in less than 1ms. however this optimization would be limited to this special case, and slight modifications of the test would probably no longer trigger it.
ok, so that
test was definitely the worst example of a micro-benchmark. let’s move on to something more real-world-ish in sunspider, the
test, which essentially runs a very early version of the
polyfill. the test arguably looks a lot more reasonable that the bitwise and test, but looking at the profile of the benchmark for some time immediately reveals that a lot of time is spent on a single
expression (up to 20% of the overall execution time for parsing and compiling plus up to 10% for actually executing the compiled code):
looking closer reveals that this
is executed exactly once, and is passed a jsonish string that contains an array of 2501 objects with
obviously parsing these object literals, generating native code for it and then executing that code, comes at a high cost. it would be a lot cheaper to just parse the input string as json and generate an appropriate object graph. so, one trick to speed up this benchmark is to mock with
and try to always interpret the data as json first and only fallback to real parse, compile, execute if the attempt to read json failed (some additional magic is required to skip the parenthesis, though). back in 2007, this wouldn’t even be a bad hack, since there was no
...yields an immediate performance boost, dropping runtime from 36ms to 26ms for v8 lkgr as of today, a 30% improvement!
this is a common problem with static benchmarks and performance test suites. today, no one would seriously use
to parse json data (also for obvious security reasons, not only for the performance issues), but rather stick to
for all code written in the last five years. in fact using
to parse json would probably be considered a bug in production code today! so the engine writers effort of focusing on performance of newly written code is not reflected in this ancient benchmark, instead it would be beneficial to make
complex to win on
ok, so let’s look at yet another example: the
. this benchmark does a lot of matrix operations, where even the smartest compiler can’t do a lot about it, but just has to execute it. essentially, the benchmark spends a lot of time executing the
function and functions called by it.
- 0.05235987755982989, and
...obviously. so, one thing you could do here to avoid recomputing the same sine and cosine values all the time is to cache the previously computed values, and in fact, that’s what v8 used to do in the past, and other engines like spidermonkey still do. we removed the so-called transcendental cache from v8 because the overhead of the cache was noticeable in actual workloads where you don’t always compute the same values in a row, which is unsurprisingly very common in the wild. we took serious hits on the sunspider benchmark when we removed these benchmark-specific optimizations back in 2013 and 2014, but we totally believe that it doesn’t make sense to optimize for a benchmark while at the same time penalizing the real world use case in such a way.
obviously, a better way to deal with the constant sine/cosine inputs is a sane inlining heuristic that tries to balance inlining and take into account different factors like prefer inlining at call sites where constant folding can be beneficial, like in the case of the
call sites. but this was not really possible with the crankshaft compiler for various reasons. with ignition and turbofan, this becomes a sensible option, and we are already working on better
garbage collection considered harmful
besides these very test-specific issues, there’s another fundamental problem with the sunspider benchmark: the overall execution time. v8 on decent intel hardware runs the whole benchmark in roughly 200ms currently (with the default configuration). a minor gc can take anything between 1ms and 25ms currently (depending on live objects in new space and old space fragmentation), while a major gc pause can easily take 30ms (not even taking into account the overhead from incremental marking), that’s more than 10% of the overall execution time of the whole sunspider suite! so any engine that doesn’t want to risk a 10-20% slowdown due to a gc cycle has to somehow ensure it doesn’t trigger gc while running sunspider.
there are different tricks to accomplish this, none of which has any positive impact in the real world as far as i can tell. v8 uses a rather simple trick: since every sunspider test is run in a new
, which corresponds to a new
in v8 speak, we just detect rapid
creation and disposal (all sunspider tests take less than 50ms each), and in that case perform a garbage collection between the disposal and creation, to ensure that we never trigger a gc while actually running a test. this trick works pretty well, and in 99.9% of the cases doesn’t clash with real uses; except, every now and then, it can hit you hard if for whatever reason you do something that makes you look like you are the sunspider test driver to v8, then you can get hit hard by forced gcs, and that can have a negative effect on your application. so rule of thumb:
don’t let your application look like sunspider!
i could go on with more sunspider examples here, but i don’t think that’d be very useful. by now it should be clear that optimizing further for sunspider above the threshold of good performance will not reflect any benefits in the real world. in fact, the world would probably benefit a lot from not having sunspider anymore, as engines could drop weird hacks that are only useful for sunspider and can even hurt real-world use cases. unfortunately, sunspider is still being used heavily by the (tech) press to compare what they think is browser performance, or even worse, to compare phones! so there’s a certain natural interest from phone makers and also from android, in general, to have chrome look somewhat decent on sunspider (and other nowadays meaningless benchmarks fwiw). the phone makers generate money by selling phones, so getting good reviews is crucial for the success of the phone division or even the whole company, and some of them even went as far as shipping old versions of v8 in their phones that had a higher score on sunspider, exposing their users to all kinds of unpatched security holes that had long been fixed and shielding their users from any real-world performance benefits that come with more recent v8 versions!source: galaxy s7 and s7 edge review: samsung's finest get more polished, www.engadget.com .
i always loved this in myles borins ’ talks, so i had to shamelessly steal his idea. anyway, hope that refreshed your pallate. and now that we've recovered from the sunspider rant, we can all get back to whatever it is we were doing. tomorrow, we'll continue on looking into the other classic benchmarks…
stay tuned for part three. here's part one in case you missed it.
Published at DZone with permission of Benedikt Meurer, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.