BenchmarkXPRT Blog banner

Category: Benchmarking

HDXPRT 2014 source code coming soon

We’ve really been enjoying the smaller size and quicker install and runtimes of HDXPRT 2014, and we encourage you to give the benchmark a try if you haven’t already! Within the next week or so, we’ll make the HDXPRT 2014 source code available to BenchmarkXPRT Development Community members. Part of what makes the XPRT community work is the feedback we get from members, whether it comes in the form of new benchmark ideas, suggestions for improvement, or questions raised during community preview testing. Having members comb through the code is another aspect of that community model. We welcome any members with programming skills to comment on our code and submit their own code for review.

If you decide to submit code, please read the XPRT commenting conventions, which are simply brief descriptions of a few practices that will make it easier for us to read your code.

We’ll also post detailed build instructions for HDXPRT 2014 in the Members Area. When the source code is available, 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. If you haven’t yet joined the community, we’d love for you to join now.

Justin

Comment on this post in the forums

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

Check out the other XPRTs:

Forgot your password?