BenchmarkXPRT Blog banner

Category: Benchmarking

Seeing the whole picture

In past posts, we’ve discussed how people tend to focus on hardware differences when comparing performance or battery life scores between systems, but software factors such as OS version, choice of browser, and background activity often influence benchmark results on multiple levels.

For example, AnandTech recently published an article explaining how a decision by Google Chrome developers to increase Web page rendering times may have introduced a tradeoff between performance and battery life. To increase performance, Chrome asks Windows to use 1ms interrupt timings instead of the default 15.6ms timing. Unlike other applications that wait for the default timing, Chrome ends up getting its work done more often.

The tradeoff for that increased performance is that waking up the OS more frequently can diminish the effectiveness of a system’s innate power-saving attributes, such as a tick-less kernel and timer coalescing in Windows 8, or efficiency innovations in a new chip architecture. In this case, because of the OS-level interactions between Chrome and Windows, a faster browser could end up having a greater impact on battery life than might initially be suspected.

The article discusses the limitations of their test in detail, specifically with regards to Chrome 36 not being able to natively support the same HiDPI resolution as the other browsers, but the point we’re drawing out here is that accurate testing involves taking all relevant factors into consideration. People are used to the idea that changing browsers may impact Web performance, but not so much is said about a browser’s impact on battery life.

Justin

Comment on this post in the forums

Looking for a bargain?

There are many benefits to being a member of the community: the XPRT community previews, the source code for the benchmarks, the monthly newsletter, and more. To join the community, all you’ve had to do up until now is sign up and pay a one-time $20 fee. Our goal with the fee was to make sure that people who joined were serious.

Today, we’re announcing a change. We recognize that, for some companies, getting that $20 fee reimbursed can be a hassle. So, if you work for a device maker, OEM, chip manufacturer, or retailer, you’ll be able to join the community for free.

Here’s how it works: Simply fill out the form, use your company e-mail address, and click the option to be considered for a free membership. We’ll send you an email within one business day to verify the address is real and then activate your membership.

Simple, right?

Justin

Comment on this post in the forums

Speaking the same language

We count on our community members for so much: benchmark ideas, critiquing the benchmark designs, and testing the community previews. Community members with programming skills can vet the source code and submit code for inclusion in the benchmarks.

We love getting code from our members. However, people have widely differing opinions about what constitutes well-documented code. A lot of it comes down to taste, but it’s easier to read code when there are common conventions. So, we’ve put together a very brief description of some conventions that would make it easier to read your code.

Because the XPRT benchmarks are written in a number of languages, we don’t discuss the particulars of coding style in detail. We know that you know the best practices for your language of choice. However, when we’re reading code in C, C++, C#, Java, JavaScript, HTML5, XML, and more, it helps to have some points of reference.

So, check it out and let us know what you think. If you have code to share, please post on the forums or send us a message at BenchmarkXPRTsupport@principledtechnologies.com. We can’t wait to see what you’ve come up with!

Eric

Comment on this post in the forums

An XPRT training course

We have a couple of exciting announcements today! A few weeks ago, we promised something special for BatteryXPRT, and we can now show off the all new BatteryXPRT training course. The BatteryXPRT training course is an online, interactive, multi-media tool designed to make learning about the benchmark easy and enjoyable.

You can easily navigate to detailed videos and graphics explaining how to build the benchmark from source code, how to configure your device, how results are calculated, and much more. It’s like the BatteryXPRT design document, white paper, and user manual have come to life!

BattXPRT training

In addition to following the link above, you can also find the course at BatteryXPRT.com. The course works on most popular browsers in Windows and OSX.

In other news, we have a name for the Chrome benchmark, CrXPRT. Thanks for all the suggestions, and let us know what you think of the name.

As promised last week, the CrXPRT Design Document is available to the development community today.  You’ll find it on the CrXPRT tab in the members’ area. If you’re not yet a member, we’d love for you to join here.

If you have any questions about CrXPRT of feedback on the BatteryXPRT course, feel free to contact us at BenchmarkXPRTsupport@principledtechnologies.com.

Eric

Comment on this post in the forums

More details to come

As we’ve been saying the past couple of months, we’re working on a benchmark for Chrome OS. The experimentation phase is winding down, and we are starting to shape the code into a useable benchmark. The design plan will leverage existing WebXPRT tests, of course. However, we’ve gone far beyond that. The benchmark will include video playback, 3D modeling via WebGL, and even an HTML5 game.  The test also uses Chrome OS’ native execution capability. The benchmark will actually use the Portable Native Client (PNaCl), as PNaCl is the recommended tool chain for native client. It also gives the benchmark the ability to run on more platforms.

As we mentioned before, we’re including a battery test as part of the new benchmark. So far, we haven’t found a way to remove the requirement to put the device in developer mode for the battery test.

Next week, we’ll publish a design document for the community to review. As always, the design document is based on the comments and suggestions we received combined with our own research and experimentation.

Eric

Comment on this post in the forums

It makes a difference

Ars Technica reported this week that they tested the developer preview of Android L and saw a whopping 36 percent improvement in battery life! Google made improving battery life a priority, and it sounds like they are succeeding. I can’t wait to test Android L with BatteryXPRT.

This is a spectacular example of how a change in software can change benchmark results, but it’s hardly unique. I’ve written before about how background activity on a phone depressed my friend’s WebXPRT scores. AnandTech used both IE 11 and Chrome 30 to test the Surface Pro 2 with a variety of benchmarks, including WebXPRT, SunSpider, Octane, Browsermark, and others. Browser choice had a noticeable impact on results – about a 40 percent difference for WebXPRT and a 76 percent difference for SunSpider!

People are generally pretty aware that changing the hardware changes performance. However, sometimes they lose track of software differences. When you compare scores, it’s not always possible to keep all the variables the same, but it’s crucial to know what the differences are.

In other BenchmarkXPRT news, we’re making some final adjustments to HDXPRT 2014, and the general release is just around the corner.

Eric

Comment on this post in the forums

Check out the other XPRTs:

Forgot your password?