SPO600

Alright, let's start off with the most relevant function: mainSimpleSort (50%, 28%) Right off the bat, there's a tiny bit of hoisting that was half-done but seems to have been forgotten. As you can see, lo + h - 1  is loop invariant. lo + h   is actually calculated outside the loop at the very beginning of the function, but   it is used as a counter. I will create a separate variable called loHi_1  and hoist this calculation. This hoist can be repeated three times, since there are three separate instances of this condition in three separate loops. Another hoist we can do is move the v+d  calculation outside the loop. I've repeated the same procedure, storing this result into a variable called  v_d . At this point in my blog post, I would like to thank the person who created the bZip2 makefile. At the end of the makefile, there are six small sample files that are run through the bZip2 function suite (decompress, compress, recompress) and their results are automatically

For the second phase of the final project, we have been instructed to profile our project and identify our optimization targets. This went terribly, and then very well. Profiling an application requires a few steps: Build a version of the app with the -Og flag Run the test case Parse the gmon.out file Make sure the results make sense Building the application was as simple as modifying the makefile, which went off without a hitch. I assumed that running my full run-tests.sh script on a profile-compatible version of the application would be the best approach. This was wrong for two reasons, which quickly became three reasons. If you remember (I don't blame you if not), the run-tests.sh  test case takes approx. 13 minutes and 20 seconds to execute completely. bZip does not spend an equal amount of time on each file, these 13 minutes are mostly consumed by the three focus-tests  that I defined in my previous post. Compiling with the -Og flag reduced optimization, which contin