July/August 2012 (Vol. 32, No. 4) pp. 2-2
0272-1732/12/$31.00 © 2012 IEEE
Published by the IEEE Computer Society
Published by the IEEE Computer Society
The Odd Couple: Hardware and Software
PDFs Require Adobe Acrobat
This column discusses issues in software performance and communication between hardware and software. It also discusses two departures from IEEE Micro's editorial board and the introduction of a new associate editor in chief.
My current position involves lots of interaction with people writing software. Unlike hardware design, where performance is a key criterion of design (and often the key criterion), performance is often an afterthought in software, if a thought at all. In addition, there seems to be little effective communication between people in software and hardware—despite such communication being hailed as an important concern since at least the birth of RISC in the mid-1980s. Instead, the situation seems more like Yogi Berra's adage about the weather: "Everybody talks about it, but nobody does anything about it."
As an example, a leader of a prominent software effort was recently asked what hardware improvements might help his software. His answer was "nothing." After further investigation, improvements indeed appear possible. However, such improvements are so secondary a concern that many in software aren't even thinking of what might be possible. Another illustration of this lack of concern about software performance comes from the increasing use of Hadoop and map-reduce for a variety of software tasks. Multiple instances have been observed where Hadoop is 1,000 times slower than a direct implementation to solve a particular problem (for example, using C, Fortran, and MPI). But the stampede is to Hadoop, not C, Fortran, and MPI. Why? Hadoop offers a simple programming model, reliability, a growing set of tools and support, and scalability (if not raw performance).
This dichotomy and separation of concerns was in some ways natural when every couple of years, Dennard scaling allowed frequency doublings and extra transistors (and power) for improved microarchitecture. Software could leave performance to the hardware and focus on productivity and improving functionality for users. However, such a separation seems increasingly strange, especially with wide interest in green computing. Not only is Hadoop 1,000 times slower than a direct implementation for a number of tasks, it consumes 1,000 times more energy. While factors of 1,000 may be extreme, I have seen many other examples where factor improvements are possible.
In that vein, Guest Editor David August produced an exciting issue, pulling together a collection of articles illustrating a variety of techniques for parallelizing sequential workloads. These techniques help enable use of more power-efficient cores and begin building a bridge allowing people in hardware and software to communicate and more effectively address each others' concerns, with minimal disruption.
This issue also marks several changes on IEEE Micro's board. On a tragic note, Associate Editor Chuck Moore passed away in May. Chuck was optimistic to the end, always expecting to persevere and triumph as he had in so many other aspects of his life. Despite his many accomplishments working on Power processors at IBM and later on AMD's offerings, Chuck remained modest, hardworking, and eager to help and share his knowledge with people up and coming in the field. We will miss him at IEEE Micro. For a fuller remembrance of Chuck, please see the "In Memoriam" column on page 3 of this issue.
IEEE Micro is also losing Kevin Skadron as an associate editor, although for happier reasons. Kevin's research and other duties have made it increasingly hard to find time for IEEE Micro work. I am sad to lose Kevin, but look forward to continued good work and interesting results from his other efforts.
Finally, on a happy note, we welcome Lieven Eeckhout as associate editor in chief of IEEE Micro. Lieven was previously an associate editor. In addition to his strong research background on issues of performance and microarchitecture, Lieven brings new energy and ideas, a fruit of which you can already see in this issue with the column by Rich Belgard about Yale Patt's selection as winner of the inaugural B. Ramakrishna Rau Award. Expect additional features in the coming months, discussing the winners of major architecture awards and highlighting other noteworthy happenings in the field. Lieven has been the initiator and driving force in these efforts, and I think they will help keep IEEE Micro interesting and relevant.
Erik R. Altman
Editor in Chief