Project Part 1

-
For the first phase of the final project, we have been instructed to find and build an open source software package, as well as benchmarking the software on both x86_64 and AArch64 machines. We need to find a test case that takes a minimum of four minutes to complete, and prove it's consistency.

I'll start this post with a bit of my project discovery process. Since we worked with a volume adjustment program in class during our benchmarking lessons, I decided to work with a software package focused on audio. Coincidentally, i've been playing around with Audacity in my free time, and given that Audacity is open source it was a strong candidate for this project. Audacity leverages the portaudio library, which was my initial choice for this project. Portaudio uses the ALSA library for it's functionality on Linux, which became my second choice for this project. Finally, after trying and failing to build both previous libraries, I settled on a dependency that they both shared: Bzip2. Bzip has nothing to do with audio, but after I discovered it's testing library while setting it up for use with ALSA, I knew it would be an excellent choice for this project.

Bzip2 is a high quality data compression tool that boasts 2x compression speed and 6x decompression speed (compared to the PPM family of compressors). It mimics Gzip in the command line, and is standard on many Linux systems. It also comes with an incredible test suite.

I built two separate versions of Bzip on Xerxes, one compiled with the O2 flag (it's default setting) and one with the O3 flag. Using the test suite's provided run-tests.sh script, the total test suite clocked in at approximately 13 minutes. I soon discovered that the run-tests.sh script was not actually using the version of Bzip that I had built, so I modified the script to force it's BZIP2 path to use /home/bwhite/aud/bzip2-1.0.8/bzip2. Here's the result of a full suite O2 test:

This test suite is pretty much all encompassing, for each file it compresses, decompresses, recompresses, and compares hashes. The final stage of the test is to provide corrupt data, and detect integrity errors. The files used by the suite range in size and arrangement, falling everywhere between kilobytes of random data to absolute worst case data. I ran this full suite test approximately ten times with the O2 flag, and identified the three files that took the most time.

These files are, in reverse order of time:
  pyflate/45MB-00 -  stalls on recompress and recompress small
  go/regexp/re2-exhaustive - stalls on recompress and recompress small
  commons-compress/zip64support - stalls on all processes

Here are the results for each of these files, on the O2 and O3 optimizations.
45MB-00: (O2)
(O3)

zip64: (O2)

(O3)

 re2: (O2)

(O3)

I decided to test these three files further. The previous results were generated with a modified version of the run-tests.sh script called cust-script.sh. In the previous examples, this script takes a single .bz2 file and runs one iteration of the run-tests.sh script. I've modified it further to time each portion of the compression process, and to run two test sets in series on O2/O3. The results are as follows.

45MB-00:
 re2:
 zip64:

Here are the highlights of the tests i've run over the course of the last day:

  • 45MB-00 has a very well rounded time on all steps of processing
  • zip64 struggles on the recompression steps, but not as heavily as re2
  • re2 struggles heavily on the recompression steps
  • The recompress and recompress (small) processes only show a small delay in time, despite the severe memory limitation. This means it is possible that the recompress process is not taking advantage of all the memory it could be (this is unlikely)
  • The O3 optimization makes almost no difference in most cases, and almost unanimously slows down processing. I've gone back and made sure that the O3 case is indeed using a separate version of Bzip compiled with the O3 flag (and is outputting with the correct label). The compilation process even reflects the O3 flag with an increased time spent compiling. I did not expect this.

So far the testing has been going well, and is actually quite fun. At this point I have not tested on an AArch64 machine, which will be my next step. I will update this blog post with the AArch tests, and any relevant information that comes with further inspection.

The AArch timings are in! This screenshot thing is getting tedious, so I compiled a spreadsheet containing all test timings for the project. Take a look here.

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

Project Part 2

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