1,885
edits
Changes
Created page with "Category:Fall 2019 SPO600 == Overview == The Winter 2019 SPO600 Project consists of: * Stage 1: Identifying and benchmarking a CPU-intensive function or method in an..."
[[Category:Fall 2019 SPO600]]
== Overview ==
The Winter 2019 [[SPO600]] Project consists of:
* Stage 1: Identifying and benchmarking a CPU-intensive function or method in an open source software project
* Stage 2: Implementing and benchmarking an optimization
* Stage 3: Getting that optimization accepted upstream
== Stage 1 ==
1. Find an open source software package that includes a 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 a hash function, compression, a codec, or any other compute-intensive task, and may be in an application or a library.
2. Benchmark the performance of the current implementation on AArch64 systems. Be sure to isolate the performance of the function of interest from the performance of all other functions. Prove the repeatability of your observations.
3. 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
* Algorithm improvements
* In-line assembler
4. Report on your results to this point.
== Stage 2 ==
'''Note:''' It is strongly recommended that you start engaging with the relevant open source community at the start of Stage 2. It takes time to find the right people in the community and engage with them.
1. Implement your optimizations to the function/method/procedure.
2. Prove that the optimized code produces equivalent results to the original code.
3. Benchmark the performance changes ''to the function'' with your optimizations. Where applicable, prove that your changes have not hindered the performance of the software on non-AArch64 platforms (specifically, x86_64).
4. Report on your results.
== Stage 3 ==
1. Get the code changes accepted by the upstream project.
2. 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 an additional final blog post for each stage to summarize the results (and identify it as such).
* 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.
== Due Dates ==
* Stage 1 is due by 11:59 pm on November 8
* Stage 2 is due by 11:59 pm on November 29
* Stage 3 is due by 11:59 pm on December 11
== FAQ ==
* '''Q: What if I can't improve performance?'''
** 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 harder to do that to optimize some portion of the code.
== Overview ==
The Winter 2019 [[SPO600]] Project consists of:
* Stage 1: Identifying and benchmarking a CPU-intensive function or method in an open source software project
* Stage 2: Implementing and benchmarking an optimization
* Stage 3: Getting that optimization accepted upstream
== Stage 1 ==
1. Find an open source software package that includes a 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 a hash function, compression, a codec, or any other compute-intensive task, and may be in an application or a library.
2. Benchmark the performance of the current implementation on AArch64 systems. Be sure to isolate the performance of the function of interest from the performance of all other functions. Prove the repeatability of your observations.
3. 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
* Algorithm improvements
* In-line assembler
4. Report on your results to this point.
== Stage 2 ==
'''Note:''' It is strongly recommended that you start engaging with the relevant open source community at the start of Stage 2. It takes time to find the right people in the community and engage with them.
1. Implement your optimizations to the function/method/procedure.
2. Prove that the optimized code produces equivalent results to the original code.
3. Benchmark the performance changes ''to the function'' with your optimizations. Where applicable, prove that your changes have not hindered the performance of the software on non-AArch64 platforms (specifically, x86_64).
4. Report on your results.
== Stage 3 ==
1. Get the code changes accepted by the upstream project.
2. 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 an additional final blog post for each stage to summarize the results (and identify it as such).
* 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.
== Due Dates ==
* Stage 1 is due by 11:59 pm on November 8
* Stage 2 is due by 11:59 pm on November 29
* Stage 3 is due by 11:59 pm on December 11
== FAQ ==
* '''Q: What if I can't improve performance?'''
** 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 harder to do that to optimize some portion of the code.