Project Part 2

-
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 continued to increase the 13:20 execution time. Because of this, some of my profile timers were expiring. This lead to inaccurate results (00.00% on all functions. weird!).
To solve this first problem, I duplicated my cust-script.sh into a pro-script.sh. Using this similar script, I was able to run individual profiling tests on single files. Here is a screenshot of the results of my 45mb-00 test case (one of my three focus-tests).
This appears to be a straightforward result, but here's where I discovered my second problem. Below is a screenshot of the same build, but run with the re2-exhaustive focus test.
This second problem is based on the test case itself: when bZip is working with an ultra-worse-case-scenario, it spends much more time in the BZ2_decompress function. Based on the test case I am using, the results are skewed. This brings us to our third problem.
These results don't make sense. Anyone who has seen the pro-script.sh execute with re2 would tell you that it spent far more time in the recompress stage than it did in the decompress stage. So why is our profile telling us that decompression is taking >50%, and recompression is nowhere to be seen? This is because the pro-script.sh calls a total of six commands, and at the execution time of each subsequent command the gmon.out file is overwritten. Therefore, at least for the profiling stage of the project, I need to completely disregard my scripts.

I'm updating this post as of 3:30PM on April 15th. The good news is that the results now make sense, and the previous two profiles are still fairly descriptive of a decompression profile. I've compiled the results from the three focus tests into a spreadsheet, which you can see here.

I will say a few final things:

  • Across the board, decompression is faster than compression in all test cases. This means I should focus my optimization on the functions in the Compress columns.
  • 45MB-00 has fallen out of favor as a test case as it's results do not align with zip64 and re2. Given it's short execution time, there is not much that optimization would do.
  • zip64 and re2 mostly agree in terms of their profiling results. I will have to weigh the execution time of each test in order to determine which function should be my priority (right now it is looking like mainSimpleSort should be my focus)

Comments

Post a Comment

Popular posts from this blog

Project Part 3

-
Image
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
Read more

Lab 5 x86_64 Update

-
This post will serve as a follow up post to the previous. The second part of lab 5 was fairly straightforward, and therefore this post will be fairly short since most of the content was covered in the previous post. The logic between the AArch64 version and x86_64 version has barely changed, the main notable difference is the use of the rax and rdx registers as the division quotient and remainder. This also removes the msub logic required on the AArch64 version, meaning that the code is very slightly smaller. Finally, instead of using the 48 decimal value to convert to ascii, I opted to use the hexadecimal 0x30. This produces the same result, but I decided on hex just to prove that I can do it. You can take a look at the x86_64 version  here .
Read more