Problem 424-3: In this problem, you will explore some of the challenges of getting reliable performance measures for the loop-based vector code examples discussed in the book.

Part 1. Write a paragraph about the challenges that arise when using the time stamp counter in current x86 processors. Look at the "time stamp counter" Wikipedia entry to get some insight here. (Feel free to consult additional sources.) Be sure to say something about repeatability, and specific problems arising if the measurement interval is too short or too long.

Part 2. Analyze the source code in this tar file ( http://ece324web.groups.et.byu.net/hw/code/cpecode.tar ) that is used to create a "getcpe" executable that can produce CPE measures for loop-based code. Write a paragraph describing how this code addresses the problems you identified above. Be sure to identify both strengths and weaknesses in the overall approach taken.

Part 3. Briefly describe the key parameters in this code that must be fine-tuned to get the most accurate results. For two of these parameters, devise and conduct a few experiments to see if the default parameter values work well on a system you have access to. On the basis of your results, suggest values for the two selected parameters that result in the most reliable results.

Part 4. For a machine of your choise, use the getcpe tool to try to produce results along the lines of those reported in the book (Sections 5.3 through 5.6) for this set of functions: {combine1(), combine2(), combine3(), combine4()} and for these combinations of data type and operation: {long add, long multiply, double add, double, multiply}. Be sure to change the OP and IDENT #defines for each new operation; IDENT must be 0 for addition and 1 for multiplication.

Write a paragraph about how the results you obtained compare with those reported in the book. Highlight the major differences you found, and say something about what the causes might be.

Clarifications

Part 1. The challenges of interest arise because of the characteristics of the system we're interested in measuring. (The challenge is not creating the assembly code to access the counter -- that is easy.)

Part 2. Once you have the file cpecode.tar, place it in your directory of choice. From within that directory, typing "tar xvf *" will create a new "cpecode" subdirectory with all the files required to build the getcpe executable. Typing "make" within that subdirectory should produce an executable named getcpe. It should compile correctly under Linux or Mac OS X.

Part 3. To identify key parameters, start by considering what values control the number of iterations of important loops in the code.

Part 4. You'll be populating a 4x4 grid of CPE measurements. Do all your work on one machine, but you can use any machine you want that this code compiles and runs on -- it need not be a spice machine. Note that the book reports results on ints while you will be using longs. To get each desired data point, you'll need to edit one or more of these files: getcpe.c, vector.h, and the Makefile (to change GCC optimization levels). After your edits, you'll recompile and run the new version. Also, you will find combine2, combine3 and combine4 in your book (combine1 is already in the code). Depending on your test platform, you may encounter problems arising from the OS dynamically scaling the processor speed, a power-saving feature that kicks in when the CPU is lightly loaded. You can tell if this happens because the processor speed reported by the "getcpe" program will be a small fraction of what you would otherwise expect. The simplest solution is to make sure that a handful of other programs are running (actually consuming CPU resources) while you run "getcpe" and collect the measurements you report.

Part 5. Focus your attention on anything that you find surprising. (It would be surprising to me if you got exactly the results reported in the book.) Different processors and different versions of GCC can produce quite different results, and our method for measuring GCC is not identical to that used by the authors of our text.