c# upc-a C++ Example of an Attempt to Tune Code to sum the Elements in a Matrix in C#

Drawer UPC - 13 in C# C++ Example of an Attempt to Tune Code to sum the Elements in a Matrix

sum = 0; elementPointer = matrix; lastElementPointer = matrix[ rowCount - 1 ][ columnCount - 1 ] + 1; while ( elementPointer < lastElementPointer ) { sum = sum + *elementPointer++; }

experience in which converting to pointers hurt perform1 ance by about 10 percent. 2 The same conversion had in 3 another setting improved performance more than 50 percent. See Software Exploratorium: Writing Efficient C Programs (Bentley 1991).

Even though the code wasn t as readable as the first code, especially to programmers who aren t C++ experts, I was magnificently pleased with myself. For a 100-by-100 matrix, I calculated that I had saved 10,000 multiplications and a lot of loop overhead. I was so pleased that I decided to measure the speed improvement, something I didn t always do back then, so that I could pat myself on the back more quantitatively.

No programmer has ever been able to predict or analyze where performance bottlenecks are without data. No matter where you think it s going, you will be surprised to discover that it is going somewhere else. Joseph M. Newcomer

Do you know what I found No improvement whatsoever. Not with a 100-by-100 matrix. Not with a 10-by10 matrix. Not with any size matrix. I was so disappointed that I dug into the assembly code generated by the compiler to see why my optimization hadn t worked. To my surprise, it turned out that I was not the first programmer who ever needed to iterate through the elements of an array the compiler s optimizer was already converting the array accesses to pointers. I learned that the only result of optimization you can usually be sure of without measuring performance is that you ve made your code harder to read. If it s not worth measuring to know that it s more efficient, it s not worth sacrificing clarity for a performance gamble.

Performance measurements need to be precise. Timing your program with a stopwatch or by counting one elephant, two elephant, three elephant isn t precise enough. Profiling tools are useful, or you can use your system s clock and routines that record the elapsed times for computing operations. Whether you use someone else s tool or write your own code to make the measurements, make sure that you re measuring only the execution time of the code you re tuning. Use the number of CPU clock ticks allocated to your program rather than the time of day. Otherwise, when the system switches from your program to another program, one of your routines will be penalized for the time spent executing another program. Likewise, try to factor out measurement overhead so that neither the original code nor the tuning attempt is unfairly penalized.

Once you ve identified a performance bottleneck, you ll be amazed at how much you can improve performance by code tuning. You ll rarely get a 10-fold improvement from one technique, but you can effectively combine techniques; so keep trying, even after you find one that works. I once wrote a software implementation of the Data Encryption Standard, or DES. Actually, I didn t write it once I wrote it about 30 times. Encryption according to DES encodes digital data so that it can t be unscrambled without a password. The encryption algorithm is so convoluted that it seems like it s been used on itself. The performance goal for my DES implementation was to encrypt an 18K file in 37 seconds on an original IBM PC. My first implementation executed in 21 minutes and 40 seconds, so I had a long row to hoe.