Fall 2018 SPO600 Project

Overview

The Fall 2018 SPO600 Project consists of:

• Stage 1: Identifying a hash, checksum, or compression function in an open source project
• Stage 2: Benchmarking the current performance of the function
• Stage 3: Implementing and testing an optimization of that function

Stage 1

1. Find an open source software package that is not claimed (see #2 below) and which includes a checksum, hash, or compression function or method that is implemented in a language that compiles to machine code (C, C++, or Assembler). This could be the Murmurhash, SHA family of hashes, a compression function, or similar. To see possible packages, you can use a command like this on Fedora: dnf search '*hash*' and to see information about that package, including the upstream URL, you can use: dnf info packageName

2. Claim the package by putting it in the Fall 2018 SPO600 Participants page under the "Project 1".

3. Identify the strategy you will use to (i) benchmark and then (ii) attempt to optimize the function for better performance on AArch64 systems. This might include some combination of:

• Altered build options
• Code changes to permit better optimization by the compiler
• Algorithm improvements
• In-line assembler

4. Report on your results to this point.

Stage 2

1. Benchmark the performance of the current implementation on AArch64 systems. Be sure to isolate the hash performance from the performance of all other functions. Prove the repeatability of your observations.

2. Report on your results.

Stage 3

1. Implement your optimizations to the hash function.

2. Prove that the optimized code produces equivalent results to the original code.

3. Benchmark the performance changes to the hash function with your optimizations. If applicable, prove that your changes have not hindered the performance of the software on non-AArch64 platforms.

4. Report on your results.

Reporting on Results

• Blog about your work frequently as you are performing it: the package you have selected, the quality of the code you've found, benchmarking challenges, and so forth.

• Write a final blog post for each stage to summarize the results.

• Write in detail, and include resources (such as test results, links to modified source code, and so forth) so that others can reproduce your results.

• Be thorough, professional, and convincing in your reported results.

• Use correct spelling, grammar, and punctuation, and ensure that your blog post contains appropriate links and code/command examples.

• Include your personal reflections on the process and your learning.

Bonus

A bonus of 5% of the course mark is available if you do either one of these two additional steps:

• Report on the total impact of your changes on the application. For example, you may have sped up the hash function by 100%, which will have a total impact of 1.5% on the application when running a particular workload.

or

• Get your code changes accepted by the upstream open source community.

Due Dates

• Stage I is due by 11:59 pm on Tuesday, November 6, 2018
• Stage 2 TBA
• Stage 3 TBA

FAQ

• Q: What if I can't improve performance?
  • A: You might have chosen an approach with minimal impact. Try alternate approaches.
• Q: What if, after trying alternate approaches to optimization, I still can't improve performance?
  • A: You can complete the project by proving that the code and build instructions, as provided by upstream, cannot be further optimized. Note that in most cases this is harder to do that to optimize some portion of the code.