Monday, September 27, 2010

Two Wrongs Don't Make a Right....What About Multiple Fails?

Good Morning CREU Fans! Looking back on the past week, it has certainly been filled with confusion, failure, mixed with downright frustration. In other words, it was a typical week in the life of programming and getting different components to get along! Our goals for the week were to install Ubuntu (A free-source operating system) on our 2 protege systems for the project, lolcat and rickroll, get them up to speed with CUDA (NVidia's Software to code algorithms to be executed via a GPU), make sure all of the necessary Linux packages were installed and running metric commands properly, and finally, update our fans. Sounds easy in theory, right?

The beginning of Stephanie and Dr. Rivoire's week was spent testing the 'try/fail' method for Ubuntu. Unfortunately, our systems were (seemingly) failing to install Ubuntu. The list of solutions:
  1. New CD Drive - Fail
  2. Changing install script command - Fail
  3. Lots of Google to resolve the above - Fail
  4. Burning the Ubuntu install discs are different speeds (8x, 16x, 24x) - Fail
  5. Burning the Ubunut install discs in different formats (CD/DVD) - Fail
  6. Update to Fedora 9.....updater was broken - Fail
  7. Show that the software was actually failing to install by turning 'silent splash' off - Success!
At this point we even resorted to requesting software from Microsoft. We could see that the systems were still running post-blank screen, however. Roger, our server room extraordinaire at SSU, suggested to change the monitor after a few hours of fail.....and it worked! Who would've thought?

Unfortunately, our frustration did not end here. The install script was showing up fine on the new monitors, and went seemingly flawless, but Lady Gaga came on our resident radio and the screen went blank, again. Fail? Not quite. After a few more hours of tooling around, it turned out that the Ubuntu was installing successfully, but not informing us of this. Needless to say, we left Ubuntu feedback on their forum immediately.

Following our first step of success, we still have a large amount of work to complete for the week, and the success/fail pattern continued. Dr. Rivoire assisted in getting the rest of the Ubuntu/Linux partnership smoothed out, and installing some of the packages required to run our tests.

At the end of it all, we sat at our allotted time for the week still with some friendships to work out between CUDA, Ubuntu, and Linux. Two wrongs don't make a right, but we certainly have proven the trial/error theory. Cheers to more updates this week as we hopefully get our systems up and analyzing!

Monday, September 20, 2010

Week 2 - What's Your Version?

Learning about commenting code changes to avoid confusion when working in a group sounds like something along the lines of common sense. No one can agree what constitutes common sense so this week, in addition to learning more about the hardware setup, involved reading the user’s manual to the version control software used to manage the version control on our code. The best part of this software, Subversion, is that it requires any user committing a change to the master code must comment what they did e.g. “function foo has been entirely gutted and reworked” to be tagged with the version number. Thanks CREU for giving me something new to put on my resume.

Looking over the state of our hardware being used for testing involved the decision to save headaches now or later on in the research. Naturally we opted to save headaches now rather than down the line by committing to changes in the operating system setup. Instead of remaining with an older flavor of Linux, Fedora, we’re changing to a newer flavor, Ubuntu to better utilize a program that will give us access to more detailed information about the CPU.

Friday, September 17, 2010

GPUs: Your Personal Aesthetics Ambassadors

Sunpyo Hong and Hyesoon Kim focus their article upon energy conservation in GPUs by analyzing the optimal number of active cores vs. power consumption. Most people would probably muster an uninformed guess that power consumption for GPUs (or any computer model, for that matter) increases and decreases on a linear scale. In other words, one might assume the best ratio of power consumption and performance would be during a “power off” or idle state, or at max consumption/capacity. Unfortunately, such is not the case, and Hung/Kim can, by pinpointing the optimal active cores, “save up to 22.09% of run-time GPU energy consumption and on average 10.99% of that for the five memory bandwidth-limited benchmarks.” To do so, they obtain power model parameters to stress the different component of the GPU's architecture. Modeling different areas such as temperature and consumption by analyzing different inputs such as memory, they create an IPP (Integrated Power and Performance) Model, which indicates the performance and energy consumption of different components. Based on run-time statistics and graphs, the IPP predicts GPU power consumption, as well as the previously mentioned optimal active running cores, and performance per watt. As a result, the findings in this article and the proposed IPP can be used to optimize configurations for programs to effectively (and efficiently) use GPUs in the most productive/conservative ratios.


Sunpyo Hong, Hyesoon Kim, "An integrated GPU power and performance model", ISCA 2010.

---

Prior to GPUs being a hot topic for power consumption in computers, extensive research was done on CPU power consumption. The majority of what I learned through this article was really the basic, systematic approach to a proper power model and the components that comprise that model. Some of these rules of thumb include accuracy, generality, speed, and expense. The authors used 5 different systems, all of varying degree in power/performance potential, along with various modeling tools, to evaluate each system. From these models, a noteworthy item I came across was that the disk benchmarking for ClamAV was the most accurate because of the minor power consumption contribution disks have vs. CPUs. I considered it noteworthy because the article later mentions that there is a lack of insight into disk and memory power consumption even though CPU power consumption is decreasing, which is limiting the accuracy of benchmarking memory/disk intensive systems (Pg. 4). Our leader for the CREU project, Dr. Rivoire, also mentioned to us this week that with models that aimed to stress the disk's power consumption (while running ClamAV), there was a large variation in power consumption as opposed to the small variation on a normal system, and the subsequent results were anything but accurate; which brings the idea of ClamAV being the "most accurate" analysis method of disk power consumption into question. I also found it interesting, and would be curious to see, how the cooling system of a GPU might be factored into the equation, which is mentioned under the conclusion section. It is such because the cooling system would also consume power, and it would be interesting to see the complexity of the code that would go into making sure that component is reported to the OS (as also stated in the conclusion).


Suzanne Rivoire, Parthasarathy Ranganathan, Christos Kozyrakis. A Comparison of High-Level Full-System Power Models. Hotpower, 2008.


------

It was interesting to compare this article with having experienced growing up in the 90's and early 21st century. PC gaming, software development, and GPUs in general developed an incredible amount over about a decade, and it is amazing to see where everything lies now after this article highlights a few of these points. One thing that was clarified for me was that I had a vague idea of the software/GPU relationship, naturally, because of gaming. But, I didn't necessarily grasp it as much as I do now after having read the article. And, although the concept of a GPU seems quite complex now as a CPU did 10-15 years ago for the average person, I believe that the knowledge (and expectation) of GPU specifications is only going to become mainstream once software is streamlined to take full advantage of them. The article mentions at the end that if you're “Twittering or checking email, GPGPU computing is not for you”, but I must disagree, in part. In due time, people will expect the same technology and graphics of a Playstation 3 or high-end Nvidia graphics processor to be emulated on their daily use PC, or better yet, their cellular phone - Budge even the slightest and the request for more will be even greater.

Matt Buchanan. Giz Explains: GPGPU Computing, and Why It'll Melt Your Face Off

URL: http://gizmodo.com/5252545/giz-explains-gpgpu-computing-and-why-itll-melt-your-face-off

---

As mentioned in the introduction, chapter 5 discusses power conservation on a small component scale, all the way up to conservation challenges of warehouse scale computers (WSCs). The first term analyzed is PUE; power usage effectiveness, which compared the IT power to total building power for a WSC. Several factors contribute to PUE, the majority of which would be the IT equipment and the cooling systems for the IT equipment (About 60-65% combined on average – Figure 5.2). One of the interesting things about the centers that have a good consumption ratio (under 2:1), interestingly enough, is because of non-computer related improvements such as air flow efficiency around the cooling systems and power conversion loss reductions. It was also interesting to note that with multiple components of any given data center, idleness is discouraged by spreading a small system load across multiple components (and vice-versa with large loads) rather than on one or a few, because it conserves more energy. This is true because a system will consume energy even on idle, but the increase of consumption with a light load is minor, making it a more efficient use to utilize multiple systems rather than a single system. The disk alone of a system can spend as much as 70% of it's energy alone keeping the hard drive platters spinning (Pg. 71). As I noted previously regarding technological improvements with GPUs, computing speed itself is nearly doubling at a rate of every 18 months, while maintaining the same power ratio. The article mentions that disk and DRAM are not on pace, however, and that future (well) balanced systems may become storage dominated, which will only increase the inefficiency of most of the world's already poor WSCs. The possible, some being quite easy to implement, solutions seem to be well within grasp, however, and it should be interesting to see if companies follow in the foot steps of others (such as Google) and the growing demand for energy conservation.


Chapter 5 from "The Datacenter as a Computer An Introduction to the design of Warehouse-Scale Machines". Synthesis Series on Computer Architecture, Morgan & Claypool Publishers, May 2009.


Thursday, September 9, 2010

Week 1 - CPUs, GPUs, Power Modeling Oh My

I knew before this project that GPUs lived to make graphic heavy games like Left 4 Dead and Halo look awesome. I never bothered myself to learn the how behind crunching the instructions so quickly. The speed is achievable due to the multiple processing units inside the hardware. The cores are beneficial here unlike the CPU because the mathematics involved with graphics are a good fit for parallel programming [1]. Sanford Russell of Nvidia gives a lay friendly example looking at the traditional CPU & GPU roles in computing [1]:

If you were looking for a word in a book, and handed the task to a CPU, it would start at page 1 and read it all the way to the end … It would be fast, but would take time because it has to go in order. A GPU … "would tear [the book] into a thousand pieces" and read it all at the same time.

Industry is showing a surprising openness with one another by supporting OpenCL (Open Computing Language) as the standard across different GPU hardware. nVidia did come out with the first proprietary GPU programming model with CUDA. The idea of taking advantage of the speedup GPU computing gives has become recognized enough that Mac OS X Snow Leopard incorporated OpenCL.

[1] Matt Buchanan. Giz Explains: GPGPU Computing, and Why It'll Melt Your Face Off. Gizmodo.com, May 2009.

---

Unlike the language side of parallel programming there hasn't been an industry standard defining how to test/measure the total power of this improved hardware. Some attempts have been made with the Green Grid’s Datacenter Performance Efficiency (DCPE). The DCPE is normally incorporated within a simplistic formula [1]

PUE is defined as Power Usage Effectiveness i.e. the datacenter building infrastructure vs the actual equipment (like servers). PUE measurements are performed by electrical equipment without any disruption to normal operations. Great if a datacenter is not available for benchmarking. SPUE stands for Server PUE a ratio of total server input power vs power consumed by components like motherboards, CPUs, etc. But there is no protocol for measuring SPUE. The actual power a server draws could be erratic depending on the activity. Introduce another set of numbers to consider, benchmarks measuring energy efficiency of the servers: Joulesort and SPECpower_ssj2008 benchmark [2]. Both benchmarks attempt to isolate efficiency differences in the hardware.

[1] Luiz André Barroso and Urs Hölzle. Chapter 5 The Datacenter as a Computer An Introduction to the design of Warehouse-Scale Machines. Synthesis Series on Computer Architecture, Morgan & Claypool Publishers, May 2009.

[2] In the interest of fair disclosure our faculty advisor, Dr. Rivoire, is also involved in the team behind JouleSort.

---

The two popular methods on real time power modeling are detailed analytical power models or high-level blackbox models. For a blackbox model the OS-reports make up a large component of present power modeling & benchmarking schemes. This has been the standard as an accurate look at the system under the assumption that CPU, memory, and disk are the main draws of power [1]. In other words graphics processors or power-aware networking equipment fall in the cracks under this assumption bound testing. To learn a great deal about one component though the analytical power model is superior to a blackbox model. An analytical power models looks only at a single component within a system. Extrapolating a model to include an entire system would be impractical and unfeasible. Hardware is moving away from CPU-dominated increasing the outdating of these models to paint an accurate picture.

Only recently have detailed analytical power models or high-level blackbox models have been attempted for modeling GPU power consumption [2]. Ma et all found with more work being sent to the GPU there is a noticeable demand in not only higher power consumption requirement but an increase in cooling solutions (also increasing the power consumption). A current problem with testing GPU Ma et all found is the potential power consumption to rapidly spike (high or low) during testing [2] exceeding the modeling parameters. Given the varying nature within GPU hardware compared to CPU, setting the boundaries for the parameters of a model, as Ma et all found, may require differing models depending on the benchmark being run.

[1] Suzanne Rivoire, Parthasarathy Ranganathan, Christos Kozyrakis. A Comparison of High-Level Full-System Power Models. Hotpower, 2008.

[2] Xiaohan Ma, Mian Dong, Lin Zhong, Zhigang Deng. Statistical Power Consumption Analysis and Modeling for GPU-based Computing. Hotpower, 2009.