High Performance Computing - Charles Severance [36]
Exercises*
Exercise 2.8.1.
Does your compiler recognize dead code in the program below? How can you be sure? Does the compiler give you a warning?
main()
{
int k=1;
if (k == 0)
printf ("This statement is never executed.\n");
}
Exercise 2.8.2.
Compile the following code and execute it under various optimization levels.
Try to guess the different types of optimizations that are being performed to improve the performance as the optimization is increased.
REAL*8 A(1000000)
DO I=1,1000000
A(I) = 3.1415927
ENDDO
DO I=1,1000000
A(I) = A(I) * SIN(A(I)) + COS(A(I)) ENDDO
PRINT *,"All Done"
Exercise 2.8.3.
Take the following code segment and compile it at various optimization levels. Look at the generated assembly language code (–S option on some compilers) and find the effects of each optimization level on the machine language. Time the program to see the performance at the different optimization levels. If you have access to multiple architectures, look at the code generated using the same optimization levels on different architectures.
REAL*8 A(1000000)
COMMON/BLK/A
.... Call Time
DO I=1,1000000
A(I) = A(I) + 1.234
ENDDO
.... Call Time
END
Why is it necessary to put the array into a common block?
2.2. Timing and Profiling
Introduction*
Perhaps getting your code to produce the right answers is enough. After all, if you only plan to use the program once in a while, or if it only takes a few minutes to run, execution time isn’t going to matter that much. But it might not always be that way. Typically, people start taking interest in the runtime of their programs for two reasons:
The workload has increased.
They are considering a new machine.
It’s clear why you might care about the performance of your program if the workload increases. Trying to cram 25 hours of computing time into a 24-hour day is an administrative nightmare. But why should people who are considering a new machine care about the runtime? After all, the new machine is presumably faster than the old one, so everything should take less time. The reason is that when people are evaluating new machines, they need a basis of comparison—a benchmark. People often use familiar programs as benchmarks. It makes sense: you want a benchmark to be representative of the kind of work you do, and nothing is more representative of the work you do than the work you do!
Benchmarking sounds easy enough, provided you have timing tools. And you already know the meaning of time.[22] You just want to be sure that what those tools are reporting is the same as what you think you’re getting; especially if you have never used the tools before. To illustrate, imagine if someone took your watch and replaced it with another that expressed time in some funny units or three overlapping sets of hands. It would be very confusing; you might have a problem reading it at all. You would also be justifiably nervous about conducting your affairs by a watch you don’t understand.
UNIX timing tools are like the six-handed watch, reporting three different kinds of time measurements. They aren’t giving conflicting information — they just present more information than you can jam into a single number. Again, the trick is learning to read the watch. That’s what the first part of this chapter is about. We’ll investigate the different types of measurements that determine how a program is doing.
If you plan to tune a program, you need more than timing information. Where is time being spent — in a single loop, subroutine call overhead, or with memory problems? For tuners, the latter sections of this chapter discuss how to profile code at