Category: HDXPRT

A touch of tomorrow

on December 16, 2011

As is often the case for me, Christmas shopping has given me the chance to look at all sorts of gadgets. (No, I’m not sure who to buy them for, but that isn’t the point.) The wealth of touch-based devices like the iPad, the Kindle Fire, the Galaxy Tab, and phones of all sorts is either incredibly exciting or amazingly confusing. Touch-based interfaces have moved well beyond the devices they started on and are showing up pretty much everywhere. Even my car (a Nissan Leaf) uses a touch interface. When I use a device with a screen, like my camera, and can’t touch the screen, it just feels wrong.

The power of computing devices like the iPad and other tablets is bringing touch into what we traditionally think of as the PC marketplace. The debut next year of Windows 8 with its touch-based Metro user interface will add another serious player to the mix. Touch will be in your desktop and notebook future. (Which for me means a steady supply of cloths for wiping screens will be a necessity, but that’s another story.) I think that touch will be the dominant interface—surpassing the mouse—in the near future.

When I see that kind of shift in the marketplace, and the resulting product diversity, my background makes me think that such an area is ripe for some good tools to compare the products. What do you think? Do we need a new generation of touch-based benchmarks for Metro? For other touch-based platforms?

Back here in HDXPRT Central, I do want to mention that the HDXPRT 2012 design specification is now available. Check it out at http://www.hdxprt.com/forum/2012_design_specification.php!

Bill

Comment on this post in the forums

RFC responses

By Bill Catchings

on December 9, 2011

The official RFC response period ended last week on December 2. We’ve been working our way through the responses and have published all of the comments and our responses here. Please do read through all of them. I wanted to touch on a couple of them here.

First, we heard differing opinions on what the minimum system requirements should be. This is a tough one. On the one hand, we want to keep the benchmark current with the latest versions of applications. Those applications typically increase their minimum system requirements over time. Those system requirements in turn are what we use as the basis for HDXPRT’s requirements. On the other hand, we really want HDXPRT 2012 to be useful on the new class of tablet, netbook, and nettop systems coming out in the next year. Our best idea is to go with the same method for determining the requirements, but to test on those slower systems and try to make sure that they are able to run.

Although we only addressed one in the responses, we heard from multiple people about making HDXPRT 2012 run on versions of Windows other than English. As we are trying to have HDXPRT used around the world, we’d like to make this happen. We face two challenges, however—first, getting systems with OEM images running non-English versions of Windows and second, the effort required for testing and debugging on those systems. You can help with the first by sending us systems. Please contact me if you may be able to help. We will test on any systems we receive and will make it a priority to work out any problems we encounter, but we can’t guarantee that all systems will work.

We are off working on the final design specifications based on the RFC and the responses. While we cannot include your comments in the design specs, we do still want to hear from you. If you have a good idea, we will try to see what we can do to accommodate it in our development cycle. So, please do let us know any comments you may have about either the RFC or the responses to it. Thanks!

Bill

Comment on this post in the forums

Posted in HDXPRT 2012, HDXPRT 2012 RFC, Let us know your thoughts |

Responding to the RFC

By Bill Catchings

on November 30, 2011

We are reaching the end of the RFC period. Your feedback plays a crucial role in defining what HDXPRT 2012 will be. Now is the time to let us know what you agree and disagree with in the RFC. We want to hear from as many of you as possible by the end of this week (December 2nd). We will still accept responses after that date, but they will be more difficult to include in the design specifications, which we will create next week based on the RFC and your feedback.

In case you have not yet had a chance to look at the RFC, it is available for Development Community members at www.hdxprt.com/forum/hdxprt2012RFC.php. You can give us your feedback either in the forums to help stimulate discussion or in email by sending them to HDXPRTsupport@hdxprt.com. However you choose to respond, we appreciate you taking the effort to do so. Thanks!

Bill

Comment on this post in the forums

Posted in HDXPRT 2012, HDXPRT 2012 RFC, Let us know your thoughts |

Thankful for change

By Bill Catchings

on November 23, 2011

With the American holiday of Thanksgiving almost here, I have been thinking of the many things I’m thankful for. I realized how thankful I am for the constant state of change in the computer industry. Part of that change is because of Moore’s Law and part of it is due to general innovation of how to take advantage of additional processing power. The consequences are that there are always new (and usually better) products out there. I love the opportunity both to play with the latest and greatest products (like my new Kindle Fire) and to use them to be more productive and do things I was not able to do previously. I genuinely look forward to when it is time to upgrade to a new computer.

A consequence of constant innovation is that it’s often important to understand how much faster new products are than their predecessors. I certainly don’t feel like going to the hassle of moving to a new computer for 10 percent more performance. But, when it is twice as fast, I have trouble resisting. And, it is important to be able to decide which of two products offers either the most performance or the best performance for the dollar. That, of course, is where benchmarks like HDXPRT come in.

Someday, the constraints of physics may put an end to Moore’s Law. When that happens, computers will be more like cars. Instead of the new model being twice or ten times as fast as your old one, it will be just a little faster, but have a really cool paint job and boss fins on it. That is not a day I look forward to! Not only will the computer industry be much less interesting, but there won’t be much need for benchmarks. I am thankful for the constant change in computers!

And, I’m thankful for all of you in the Development Community for your help in defining, developing, testing, and promoting HDXPRT. Now, before the tryptophan kicks in, please send us your responses to the RFC!

Bill

Comment on this post in the forums

Posted in HDXPRT 2012 RFC, Let us know your thoughts |

What to do with all the times

By Bill Catchings

on November 17, 2011

HDXPRT, like most other application-based benchmarks, works by timing lots of individual operations. Some other benchmarks just time the entire script. The downside of that approach is that the time includes things that are constant regardless of the speed of the underlying hardware. Some things, like how fast a menu drops down or text scrolls, are tied to the user experience and should not go faster on a faster system. Including those items in the overall time dilutes the importance of the operations that we wait on and are frustrated by, the operations we need to time.

In the case of HDXPRT 2011, we time between 20 and 30 operations. We then roll these up into the times we report as well as the overall score. We do not, however, report the individual times. We expect to include even more timed operations in HDXPRT 2012. As we have been thinking about what the right metrics are, we have started to wonder what to do with all of those times. We could total up the times of similar operations and create additional results. For example, we could total up all the application load times and produce an application-load result. Or, we could total up all the times for an individual application and produce an application result. I can definitely see value in results like those.

Another possibility is to try and look at the general pattern of the results to understand responsiveness. One way would be to collect the times in a histogram, where buckets correspond to ranges of response times for the operations. Such a histogram might give a sense of how responsive a target system feels to an end user. There are certainly other possibilities as well.

If nothing else, I think it makes sense to expose these times in some way. If we make them available, I’m confident that people will find ways to use them. My concern is the danger of burdening a benchmark with too many results. The engineer in me loves all the data possible. The product designer knows that focus is critical. Successful benchmarks have one or maybe two results. How to balance the two?

One wonder of this benchmark development community is the ability to ask you what you think. What would you prefer, simple and clean or lots of numbers? Maybe a combination where we just have the high-level results we have now, but also make other results or times available in an “expert” or an “advanced” mode? What do you think?

Bill

Comment on this post in the forums

Posted in HDXPRT Development Community benefits, HDXPRT metrics, HDXPRT workloads, Let us know your thoughts |

Turning a role into a scenario

By Bill Catchings

on November 9, 2011

To give you an idea about our process for proposing the scenarios in the RFC, I want to walk you through one of them. (Download the RFC at http://www.hdxprt.com/forum/hdxprt2012RFC.php if you haven’t already.) The role I’m going to discuss is that of a photo blogger. By photo blogger, I am thinking of someone who is a photo enthusiast, not someone who snaps pictures with his iPhone and puts them on Facebook. By my thinking, this type of photo blogger is someone who enjoys photography, has substantial knowledge of digital tools, and is interested in processing and posting photos on enthusiast Web sites. That person would commonly use raw rather than compressed photos from their camera and convert them to a standard format as the last step. The person would certainly edit the photos using different filters and effects. That person might also do some more esoteric things like stitch together multiple photos to create a panorama or work with high dynamic range (HDR) images. The latter is growing in popularity due to its ability both to better represent the color palette found in nature and to go farther and create amazing surreal images. Some newer cameras (like my Sony NEX-5) will produce the necessary multiple exposures to make HDR fairly easy to do.

What software would such a person use to do those things? Because HDXPRT is a consumer-oriented benchmark, we want to find affordable (or free) applications that a typical consumer might use. For photo manipulation, I think Adobe Photoshop Elements is the leading consumer application. The software lets users create, edit, organize, and share images. For HDR images, HDRsoft Photomatix is a good tool for high-quality two-stage HDR processing. It provides capabilities for both image overlaying and adjustable tone mapping. Another useful tool is GIMP, which stands for GNU Image Manipulation Program. It’s a free graphics editor that allows users to edit and retouch images. I think including some free tools like this mimics what many consumers with limited budgets are using.

Having seen the basic process we used in the RFC, what do you think? Does that process make sense to you? In this particular one, do you agree with the basic activities? The applications? Thanks, I look forward to hearing from you!

Bill

Comment on this post in the forums

Posted in HDXPRT 2012 RFC, Let us know your thoughts |

Category: HDXPRT

A touch of tomorrow

RFC responses

Responding to the RFC

Thankful for change

What to do with all the times

Turning a role into a scenario

Check out the other XPRTs: