Category: What makes a good benchmark?

Time to get creative

on September 4, 2014

The CrXPRT Community Preview is right around the corner, and there’s no sign of things slowing down. We’re exploring new opportunities on a number of fronts, and we’d love to hear what you think! We’re considering possible changes to WebXPRT and MobileXPRT, and since the mobile device market is changing all the time, we’re looking for the next great benchmark opportunity. In both cases, the development community is a rich source of ideas, so we’d like to tap into it one more time.

A while back, we added a new Web form in the members’ area for submitting benchmark ideas. Some of the ideas we have so far include:

A benchmark to evaluate camera features and photo quality on phones and tablets
A benchmark for measuring the performance of cloud services
A benchmark for measuring the performance and battery life of iOS-based devices

So, what would you like to see? Any of these, or do you have ideas we haven’t mentioned? Also, we’d love to hear your feedback on ways we can improve, both with the XPRTs themselves and with community life. Either way, send a message to BenchmarkXPRTSupport@principledtechnologies.com and let us know what you think!

Justin

Comment on this post in the forums

Posted in BenchmarkXPRT development community, Collaborative benchmark development, Community Preview, CrXPRT, MobileXPRT, WebXPRT, What makes a good benchmark? |

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? |

Testing the waters

By Eric Hale

on June 19, 2014

A couple of weeks ago, we talked about some of our ideas for a new XPRT designed for Google’s Chrome OS. We’ve been working with some of these ideas and, while we’re still in the experimental stage, things look promising so far.

As we mentioned in the earlier blog, we’re trying WebXPRT as a base for the performance part of the test. So far, the performance component is working well. In addition to modified WebXPRT tests, we’re also trying some things that are not part of the WebXPRT 2013 workload.

We’ve been able to get battery life, but it’s been challenging and we haven’t found a way to avoid using Chrome’s Developer Mode. Accessing Developer Mode in Chrome can be tricky and requires different steps for each hardware manufacturer. We’re hoping to find ways to make battery life testing easier.

I’ve been vague about the tests because they’re likely to change over the next few weeks. We’re experimenting with both browser-based and Native Client-based performance tasks. As they firm up, I’ll be able to share more information.

Challenges aside, we’re excited about this new benchmark, and committed to making it as effective as possible. We’d still love feedback on a name, so feel free to contact us at BenchmarkXPRTsupport@principledtechnologies.com with your ideas.

Eric

Comment on this post in the forums

Posted in Battery life, Chrome OS, Collaborative benchmark development, Performance benchmarking, What makes a good benchmark? |

Something shiny

By Eric Hale

on May 22, 2014

As I mentioned in Looking for the next big thing, we’ve received some ideas for benchmarks recently. While there were several good ideas, the one that rose to the top of the list was a benchmark for Chrome-based devices.

For the past year or so, Chromebooks have been the fastest-growing segment of the PC market, so there’s a lot of interest. Given the rising profile of Chromebooks, a Chrome OS benchmark seems like a good fit with the existing XPRTs.

We’ve just started batting around ideas about what a Chrome OS benchmark might look like. Because the browser is the interface, WebXPRT is the natural place to start. However, WebXPRT runs on all platforms. We would like a Chrome benchmark to consider Chrome‑specific technologies like Google Native Client. If possible, it would also be great to get the battery life as well as performance.

Those are a few of our ideas. Do you have ideas about what you would like to see in a Chrome OS benchmark? If so, what would you consider most important for it to include? Let us know at benchmarkxprtsupport@principledtechnologies.com!

And remember, we’re always looking for new ideas. If there’s a benchmark you’d love to see, let us know.

Eric

Comment on this post in the forums

Posted in Collaborative benchmark development, Future of performance evaluation, Google Chrome, WebXPRT, What makes a good benchmark? |

Looking for the next big thing

By Eric Hale

on April 17, 2014

We recently introduced a new Web form in the members’ area to make it easier for you to submit new benchmark ideas. We’ve already received some interesting suggestions:

A benchmark to assess performance, battery life, and Chrome-specific technologies on Chromebooks
A benchmark to evaluate camera features and photo quality on phones and tablets
A benchmark for measuring the performance of cloud services
A benchmark for measuring the performance and battery life of iOS-based devices

Are you interesting in seeing any of these? Or do you have an idea no one has mentioned yet? We know there’s more out there! We like finding new things to measure and new ways to measure them, so please don’t hesitate to share your ideas!

Also, remember that the comment period for BatteryXPRT 2014 for Android CP2 ends on Monday, April 21. CP2 is the first XPRT to feature a Simplified Chinese UI. Please send in your comments. We’ll be aiming for a BatteryXPRT general release soon.

By the way, if you have a language you’d like to see and you’re willing to help with the translation, we’d love to talk to you!

Let us know what you think about potential new benchmarks, language options, or anything else on your mind at BenchmarkXPRTSupport@principledtechnologies.com.

Eric

Comment on this post in the forums

Posted in BatteryXPRT 2014 for Android, Benchmarking, Chinese, Collaborative benchmark development, Community Preview, Future of performance evaluation, What makes a good benchmark? |

What is truth?

By Eric Hale

on April 3, 2014

Last fall, we discussed AnandTech’s report on benchmark cheating, and why open and honest benchmark development is so important. This week, benchmark optimization is back in the news, as AnandTech says that the HTC One M8 boosts its performance in whitelisted benchmarks. CNET has quoted HTC admitting that they not only boosted performance, but promoted the boost as a feature.

However, HTC has gone a step further, giving users the option to manually set the phone to high-performance mode. Some of us at PT have been involved in developing benchmarks for over 20 years, and it’s always been true that one person’s cheat can be another person’s valid optimization. Whatever their motivation, HTC’s position – that some people will choose higher performance over longer battery life – is not necessarily wrong.

BatteryXPRT recognizes that there’s a tradeoff between performance and battery life, and that you shouldn’t penalize a fast system the same way you would a system that simply has poor battery life. That’s why it reports a performance score along with the estimated battery life.

Do you have thoughts on optimizations, cheating, or ways to make the benchmarks better? Please drop us a line at BenchmarkXPRTSupport@principledtechnologies.com.

Eric

Comment on this post in the forums

Posted in BatteryXPRT 2014 for Android, Benchmarking, Collaborative benchmark development, Performance benchmarking, What makes a good benchmark? |

Category: What makes a good benchmark?

Time to get creative

Speaking the same language

Testing the waters

Something shiny

Looking for the next big thing

What is truth?

Check out the other XPRTs: