1,885
edits
Changes
Created page with "Category:Winter 2020 SPO600 == Overview == The Winter 2020 SPO600 Project consists of: * Stage 1: Identifying and benchmarking a CPU-intensive function or method in..."
[[Category:Winter 2020 SPO600]]
== Overview ==
The Winter 2020 [[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. '''Write the name of the package on the [[Fall 2019 SPO600 Participants|Participants Page]]'''.
2. Build the software.
3. Find or create a test case that takes at least 4 minutes to run and represents a reasonable use-case for the software.
4. Benchmark the performance of the current implementation of the software on AArch64 and x86_64 systems. Control or account for any variables that may alter your results. Prove the repeatability of your observations.
5. Experiment with various build options (e.g., compiler optimization levels) to determine if this has any impact on the performance.
6. Report on your results to this point.
== Stage 2 ==
1. Profile your software to identify where the software is spending its execution time and the amount of memory that the software is using. Perform this profiling using the test case you created in Stage 1, on both x86_64 and AArch64 platforms. Do not compare the absolute performance on different platforms, but do compare the relative performance on a givel platform.
2. Identify the functions or methods that are taking the majority of the CPU time.
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. Examine the code of the functions and methods that are taking the most CPU time.
2. Identify possible approaches to improving the performance of the software. Which changes to data types, software organization, algorithim decisions, or other aspects of the software could improve performance?
3. Defend your approaches either by testing them or by building a case to support your approach(es).
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 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 March 22
* Stage 2 is due by 11:59 pm on April 5
* Stage 3 is due by 11:59 pm on April 12
== Overview ==
The Winter 2020 [[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. '''Write the name of the package on the [[Fall 2019 SPO600 Participants|Participants Page]]'''.
2. Build the software.
3. Find or create a test case that takes at least 4 minutes to run and represents a reasonable use-case for the software.
4. Benchmark the performance of the current implementation of the software on AArch64 and x86_64 systems. Control or account for any variables that may alter your results. Prove the repeatability of your observations.
5. Experiment with various build options (e.g., compiler optimization levels) to determine if this has any impact on the performance.
6. Report on your results to this point.
== Stage 2 ==
1. Profile your software to identify where the software is spending its execution time and the amount of memory that the software is using. Perform this profiling using the test case you created in Stage 1, on both x86_64 and AArch64 platforms. Do not compare the absolute performance on different platforms, but do compare the relative performance on a givel platform.
2. Identify the functions or methods that are taking the majority of the CPU time.
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. Examine the code of the functions and methods that are taking the most CPU time.
2. Identify possible approaches to improving the performance of the software. Which changes to data types, software organization, algorithim decisions, or other aspects of the software could improve performance?
3. Defend your approaches either by testing them or by building a case to support your approach(es).
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 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 March 22
* Stage 2 is due by 11:59 pm on April 5
* Stage 3 is due by 11:59 pm on April 12
