Changes

Jump to: navigation, search

Winter 2018 SPO600 Project

325 bytes removed, 10:32, 23 February 2018
no edit summary
[[Category:Fall 2017 Winter 2018 SPO600]]
[[Category: Chris Tyler Draft]]
== Overview ==
The Fall 2017 Winter 2018 [[SPO600]] Project consists of:* Stage 1: Identifying and Benchmarking benchmarking a Hash CPU-intensive function or Checksum Function method in an Open Source Software Projectopen source software project* Stage 2: Implementing and Benchmarking benchmarking an Optimizationoptimization* Stage 3: Getting that optimization accepted upstream
== Stage 1 ==
1. Find an open source software package that includes a checksum or hash CPU-intensive function or method that is implemented in a language that compiles to machine code (such as C, C++, or Assembler). This could be the Murmurhasha hash function, SHA family of hashescompression, a codec, or a similar functionany other compute-intensive task.
2. Benchmark the performance of the current hash implementation on AArch64 systems (I'll refer to hash and checksums both as hashes from now on, and functions and methods as functions). Be sure to isolate the hash performance of the function of interest from the performance of all other functions. Prove the repeatability of your observations.
3. Identify Clearly identify the strategy you will use in Stage 2 to attempt to optimize the hash 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
== Stage 2 ==
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 Where applicable, prove that your changes have not hindered the performance of the software on non-AArch64 platforms.
4. Report on your results.
 
== Stage 3 ==
 
1. Get the code changes accepted by the upstream project.
 
2. Report on your 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 an additional 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.
* 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 Saturday, December 16, 2017...* Stage II is due by 11:59 on Monday, January 8, 2018...* Stage III is due by 11:59 pm on ...
== FAQ ==
** A: You may have selected your area of focus poorly, or be using the wrong approach to optimization. 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 '''much''' harder to do that to optimize some portion of the code.

Navigation menu