There are many different computational methods for performing integration. Since the integral from xLo to xHi of a function f(x) is the area under the curve between xLo and xHi, one way to compute the integral is to compute that area.
One way to compute this area is using the trapezoidal method, which approximates the area by fitting 1 or more trapezoids to the curve, and computing the combined areas of the trapezoids. With a single trapezoid, the approximation is pretty poor:
but the approximation becomes more accurate as more trapezoids are used:
Create a new folder for this project, and save a copy of these files: integral.h, integral.c, calcPI.c, and Makefile. The integrate() function in the file integral.c uses the trapezoidal method to perform integration.
The program in calcPI.c uses that function to calculate an approximate value of PI. The program uses the function to calculate the area of 1 quadrant of the unit circle. Since a circle's area is PI * radius2 and the radius of a unit circle is 1, the area of the unit circle is PI. If we can find the area of one quadrant of the unit circle, multiplying that area by 4 should provide an approximate value for PI:
Use the provided Makefile to build the program. Then run it from the commandline, using 1 and 10 trapezoids. Since we cannot tell how long it takes the program to run, and the I/O should not take much time, add MPI calls to measure how long the integrate() function takes to run, and have the program output that time.
Rerun the program using 1; 10; 100; 1,000; 10,000; 100,000; 1,000,000; 10,000,000; 100,000,000; 1,000,000,000; and 10,000,000,000 trapezoids. In a spreadsheet, record (i) the number of trapezoids used, (ii) the time required, and (iii) the precision (the number of correct decimal digits) of the result. Create a chart of your times, and predict (a) how many trapezoids, and (b) how long it will take to compute PI to 20 digits of precision.
In this example, finding the "hotspot" or place where the program is spending most of its time is pretty easy. In larger programs, it can be more difficult, and there may be multiple "hotspots". In this part of today's exercise, we are going to use this simple program to explore the capabilities of a program that can help us find such "hotspots".
Intel and other companies make profiling tools that analyze the performance of a sequential program to help you identify its "hotpots". Take a few minutes to watch this short video to get high-level overview of the tools available in Intel's Parallel Studio XE.
Intel's profiling tool is called Advisor. This video walks you through the use of Intel's Advisor for multithreading, to get a general sense of its capabilities.
The general steps to use the Advisor tool are:
To use the standlone Advisor application, your program must be compiled for debugging (i.e., with extra information saved so that the debugger can map machine instructions back to the corresponding source code instructinos). With the gcc compiler, this is accomplished using the -g switch, so edit the Makefile and add -g to the definitions of CFLAGS and LFLAGS. Then save the Makefile, enter
make cleanto remove the old files, and then enter
maketo rebuild the program for debugging. Examine the compile and link commands the Makefile is performing, and verify that the -g switch is present.
The Intel tools reside in /opt/intel/, so to launch the Advisor, enter the following:
/opt/intel/advisor/bin64/advixe-guiTry it out on your own: create a project, and follow the steps in the video to run/profile your calcPI binary. When you create your project and specify calcPI as the Application, you can specify the command-line argument on the Application Parameters line. Give it enough trapezoids (e.g., 1,000,000,000) so that it has enough work to do, or else the Collect Survey Data step may report No Data. To change this command-line argument, choose:
File > Project PropertiesWhile you are in Project Properties, click the Source Search tab and add your project folder to the list of "Search Directories" so that Advisor can find your project's source code.
When you try the Add Annotations step, gcc will likely give you an error when it processes the directive:
#include "advisor-annotate.h"If this happens, gcc does not know the location of Advisor's #include directory. To tell it where to find this directory, add the following switch to the CFLAGS variable in the Makefile:
-I/opt/intel/advisor/includeThe -I switch followed by a directory tells gcc to add that directory to the list of those it searches when processing #include directives. That change should resolve that particular problem.
To avoid some Advisor-specific linking errors, you may also need to tell gcc to enable dynamic loading by adding the following switch to the LFLAGS variable:
Finally, it appears that Intel did not strictly follow the ANSI standard, so their files generate a number of ANSI warnings. If you want to suppress most of those warnings, try removing the -ansi -pedantic switches from the CFLAGS variable in the Makefile.
If you get stuck, Prof. Adams is available to help.
Feel free to try Intel's advisor with your other projects, to see what information it reveals about their runtime behavior.
For more information about Intel's Advisor, see this tutorial from Intel.
If you want to explore more, Intel's Parallel Studio includes two other tools to aid you in parallel program development:
When you are comfortable with the basics of using Intel's Advisor, you may continue to this week's project.
CS > 374 > Exercise > 05 > Hands-On Lab