BenchmarkXPRT Blog banner

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 HDXPRT 2014 update

After the HDXPRT 2014 release last week, we discovered a new issue. During installation, if network connections were active, Windows SmartScreen would pop up with a message that said, “Windows SmartScreen prevented an unrecognized app from starting…” If network connections were disabled, a popup would say, “Windows SmartScreen can’t be reached right now.”

Even after turning off SmartScreen entirely, we continued to receive Windows publisher verification warnings. It turns out that the problem relates to testing on a system where Windows 8/8.1 is reinstalled over an existing copy of the OS. Residual information in the C:\Windows.old files apparently trigger the warning. It may also occur if you upgraded from Windows 8 or 8.1 Preview to Windows 8.1.

You may not encounter this problem at all during testing. If you do, there are at least three options for dealing with this. The first option is to turn off SmartScreen in the Windows Action center and disable Windows prompts about publisher verification. Then, open Internet Explorer – Internet Options, click the Security tab, click the Custom level button, and scroll down to select Enable Launching applications and unsafe files.

Screenshot (2)

The second option is to delete any Windows.old files. You can find instructions for that here.

The third is to test on a completely fresh OS install on a reformatted drive.

Also, today we’re posting an updated build that fixes a few UI issues. Scores from the original build are still valid and comparable.

If you have any feedback or questions regarding HDXPRT 2014, feel free to send us a message at BenchmarkXPRTsupport@principledtechnologies.com.

Justin

Comment on this post in the forums

HDXPRT 2014 is here!

Today we formally released HDXPRT 2014. The BenchmarkXPRT Development Community has been using a community preview for several weeks now. Now that we’ve released the benchmark, anyone may freely use it.

HDXPRT home screen

HDXPRT 2014 address the most common comments we had about the previous versions. It is a much smaller and faster benchmark. Instead of taking over five hours to get a result, as HDXPRT 2012 did, you can now install the benchmark and get a result in less than 2 hours. Also, because we were able to trim the benchmark size considerably, you can download HDXPRT directly from our site via a compressed install file. See the HDXPRT 2014 User Manual, available in the download and at HDXPRT.com, for installation instructions.

The HDXPRT 2014 source code will soon be available to the community. Remember that community members have access to the source code, but it is not available to the general public.

Although HDXPRT is much smaller and faster than HDXPRT 2013, we worked hard to make sure than we did not compromise the results. Give it a try and let us know what you think!

Eric

Comment on this post in the forums

Check out the other XPRTs:

Forgot your password?