|
 |
|
 |
 |
Software Optimization for High Performance Computing: Creating Faster Applications (HP...
|
by Kevin R. Wadleigh and Isom L. Crawford
Sales Rank: 754246
|
Discount: 17 %
List Price: $46.99
$42.29
At Amazon
|
|
Paperback: 377 pages
Publisher: Prentice Hall PTR May 28, 2000
Language: English
ISBN-10: 0130170089
ISBN-13: 978-0130170088
Product Dimensions:
9.2 x 6.9 x 1 inches
Shipping Weight: 1.4 pounds
Product Review
"(This) is a book that should be in the hands of programmers in high-performance computing."Greg Astfalk, Chief Scientist, Technical Computing Division, Hewlett-Packard Company.
From the Inside Flap
Preface Once you start asking questions, innocence is gone.
- Mary Astor
This purpose of this book is to document many of the techniques used by people who implement applications on modern computers and want their programs to execute as quickly as possible.
There are four major components that determine the speed of an application: the architecture, the compiler, the source code, and the algorithm. You usually don't have control over the architecture you use, but you need to understand it so you'll know what it is capable of achieving. You do have control over your source code and how compilers are used on it. This book discusses how to perform source code modifications and use the compiler to generate better performing applications. The final and arguably the most important part is the algorithms used. By replacing the algorithms you have or were given with better performing ones, or even tweaking the existing ones, you can reap huge performance gains and perform problems that had previously been unachievable.
There are many reasons to want applications to execute quickly. Sometimes it is the only way to make sure that a program finishes execution in a reasonable amount of time. For example, the decision to bid or no-bid an oil lease is often determined by whether a seismic image can be completed before the bid deadline. A new automotive body design may or may not appear in next year's model depending on whether the structural and aerodynamic analysis can be completed in time. Since developers of applications would like an advantage over their competitors, speed can sometimes be the differentiator between two similar products. Thus, writing programs to run quickly can be a good investment.
P.1 A Tool Box
We like to think of this book as a tool box. The individual tools are the various optimization techniques discussed. As expected, some tools are more useful than others. Reducing the memory requirements of an application is a general tool that frequently results in better single processor performance. Other tools, such as the techniques used to optimize a code for parallel execution, have a more limited scope.
These tools are designed to help applications perform well on computer system components. You can apply them to existing code to improve performance or use them to design efficient code from scratch. As you become proficient with the tools, some general trends become apparent. All applications have a theoretical performance limit on any computer. The first attempts at optimization may involve choosing between basic compiler options. This doesn't take much time and can help performance considerably. The next steps may involve more complicated compiler options, modifying a few lines of source code, or reformulating an algorithm. The theoretical peak performance is like the speed of light. As more and more energy, or time, is expended, the theoretical peak is approached, but never quite achieved. Before optimizing applications, it is prudent to consider how much time you can, or should, commit to optimization.
In the past, one of the problems with tuning code was that even with a large investment of a time the optimizations quickly became outdated. For example, there were many applications that had been optimized for vector computers which subsequently had to be completely reoptimized for massively parallel computers. This sometimes took many person-years of effort. Since massively parallel computers never became plentiful, much of this effort had very short-term benefit.
In the 1990s, many computer companies either went bankrupt or were purchased by other companies as the cost of designing and manufacturing computers skyrocketed. As a result, there are very few computer vendors left today and most of today's processors have similar characteristics. For example, they nearly all have high-speed caches. Thus, making sure that code is structured to run well on cache-based systems ensures that the code runs well across almost all modern platforms.
The examples in this book are biased in favor of the UNIX operating system and RISC processors. This is because they are most characteristic of modern high performance computing. The recent EPIC (IA64) processors have cache structures identical to those of RISC processors, so the examples also apply to them.
P.2 Language Issues
This book uses lots of examples. They are written in Fortran, C, or in a language-independent pseudocode. Fortran examples use uppercase letters while the others use lowercase. For example,
DO I = 1,N
Y(I) = Y(I) + A * X(I)
ENDDO
takes a scalar A, multiplies it by a vector x of length N and adds it to a vector Y of length N. Languages such as Fortran 90/95 and C++ are very powerful and allow vector or matrix notation. For example, if x and Y are two-dimensional arrays and A is a scalar, writing
Y = Y + A * X
means to multiple the array x by A and add the result to the matrix Y This notation has been avoided since it can obscure the analysis performed. The notation may also make it more difficult to compilers to optimize the source code.
There is an entire chapter devoted to language specifics, but pseudo-code and Fortran examples assume that multidimensional arrays such as Y (200, 100) have the data stored in memory in column-major order. Thus the elements of Y (200, 100) are stored as
Y(1,1), Y(2,1), Y(3,1),, Y(200,1), Y(1,2), Y(1,3),
This is the opposite of C data storage where data is stored in row-major order.
P.3 Notation
When terms are defined, we'll use italics to set the term apart from other text. Courier font will be used for all examples. Mathematical terms and equations use italic font. We'll use lots of prefixes for the magnitude of measurements, so the standard ones are defined in the following table.
Table P-1: Standard Prefixes
Prefix Factor Factor
tera 1012 240
giga 109 230
mega 106 220
kilo 103 210
milli 10-3
micro 10-6
nano 10-9
Note that some prefixes are defined using both powers of 10 and powers of two. The exact arithmetic values are somewhat different. Observe that 106 = 1,000,000 while 210 = 1,048,576. This can be confusing, but when quantifying memory, cache, or data in general, associate the prefixes with powers of two. Otherwise, use the more common powers of 10.
Finally, optimizing applications should be fun. It's really a contest between you and the computer. Computers sometimes give up performance grudgingly, so understand what the computer is realistically capable of and see that you get it. Enjoy the challenge!
Customer Reviews & Comments
I don't wish to offend the authors of this book, who I am sure are experts in this field. However, I found this book to be unnecessarily difficult to read. The the book presents inherently complex material, which testifies to the proficiency of the authors. However, it was often not clear what point the authors were trying to make, especially regarding graphs which lacked clear explanations. Often I had to to re-read an entry several times before I understood what the authors were trying to express. I am sure the book contains a wealth of valuable information (which is why I ordered it), but I personally was unwilling to invest the time and energy necessary to fathom the authors intent. I am a systems engineer for an international telecom company.
Comment | Permalink |
(Report this)
|
Software Optimization for High Performance Computing: Creating Faster Applications (HP...
List Price: $46.99
Discount: 17 %
Available from Amazon
Price: $42.29
| |
|
|
|
|
