Month: August 2014

HDXPRT 2014 source code coming soon

on August 28, 2014

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

By Justin Greene

on August 21, 2014

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

Posted in Battery life, Benchmark metrics, Google Chrome, Performance benchmarking, Windows 8 |

Looking for a bargain?

By Justin Greene

on August 14, 2014

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

Posted in BenchmarkXPRT development community, Collaborative benchmark development, Community Preview, Performance benchmarking, Source code |

Speaking the same language

By Eric Hale

on August 7, 2014

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

Posted in BenchmarkXPRT development community, Collaborative benchmark development, Source code, What makes a good benchmark? |

Month: August 2014

HDXPRT 2014 source code coming soon

Seeing the whole picture

Looking for a bargain?

Speaking the same language

Check out the other XPRTs: