Open main menu

CDOT Wiki β

Changes

Fall 2014 SPO600 Weekly Schedule

834 bytes added, 12:12, 17 October 2014
no edit summary
|6||Oct 6||[[#Tuesday (Oct 7)|Guest Speaker: Jon "Maddog" Hall]]||[[#Friday (Oct 10)|Codebase analysis / Memory barriers and Atomics]]||[[#Week 6 Deliverables|Analyze the platform-specific code in 3 packages.]]
|-
|7||Oct 13||[#Tuesday (Oct 14)|[[Architecture-specific Code for Performance- Why?]]||[[#Friday (Oct 17)|Compiler Intrinsics and Picking your Package]]||[[#Week 7 Deliverables|Pick you package and blog about it.]]
|-style="background: #f0f0ff"
|Study Week||Oct 20||colspan="3" align="center"|Study Week<br />'''[http://fsoss.ca FSOSS 2014] on Thursday-Friday'''
|-
|8||Oct 27||Architecture-specific Code for PerformanceProfiling||Group hack session - PortingProfiling||Blog about your progress.
|-
|9||Nov 3||Portability - Removing platform-specific code||Group hack session - Portability||Blog about Post baseline stats for your progresssoftware.|-<!-- |8||Nov 10||Project Work||Project Work||Get code into review and blog about it.|- |9||Nov 17||Status Update||Foundation Models||Install and Test With Foundation Model and blog about it.|--->
|10||Nov 10||ProfilingOptimizing Code||Baseline ProfilingGroup hack session||Post baseline stats for Blog about your softwareprogress.
|-
|11||Nov 17||Optimizing Code||Group hack session - Profiling and optimizing||Post a code review update.
|-
!Category!!Percentage!!Evaluation Dates
|-
|Communication||align="right"|20%||<strike>September 30</strike>, October 31, November 21, December 10
|-
|Quizzes||align="right"|10%||May be held during any class, usually at the start of class. A minimum of 5 one-page quizzes will be given. No make-up/retake option is offered if you miss a quiz. Lowest 3 scores will not be counted.
|Labs||align="right"|10%||See deliverables column above.
|-
|Project work||align="right"|60%||October 10, November 21, December 10
|}
* Pick three additional packages (not the ones done in class) from your section of the [[Fall 2014 SPO600 Packages by Participant|Packages by Participant]] list and find the platform-specific code (or build instructions). Figure out what that code does, and document that on the list page. Blog about your results and your reflections on the task.
 
== Week 7 ==
 
=== Tuesday (Oct 14) ===
 
Discussion of some of the reasons that platform specific (usually assembly language) code is used in software
 
==== Memory Barriers ====
'''Memory Barriers''' ensure that memory accesses are sequenced so that multiple threads, processes, cores, or IO devices see a predictable view of memory.
* Leif Lindholm provides an excellent explanation of memory barriers.
** Blog series - I recommend this series, especially the introduction, as a very clear explanation of memory barrier issues.
*** Part 1 - [http://community.arm.com/groups/processors/blog/2011/03/22/memory-access-ordering--an-introduction Memory Access Ordering - An Introduction]
*** Part 2 - [http://community.arm.com/groups/processors/blog/2011/04/11/memory-access-ordering-part-2--barriers-and-the-linux-kernel Memory Access Ordering Part 2 - Barriers and the Linux Kernel]
*** Part 3 - [http://community.arm.com/groups/processors/blog/2011/10/19/memory-access-ordering-part-3--memory-access-ordering-in-the-arm-architecture Memory Access Ordering Part 3 - Memory Access Ordering in the ARM Architecture]
** Presentation at Embedded Linux Conference 2010 (Note: Acquire/Release in C++11 and ARMv8 aarch64 appeared after this presentation):
*** [http://elinux.org/images/f/fa/Software_implications_memory_systems.pdf Slides]
*** [http://free-electrons.com/pub/video/2010/elce/elce2010-lindholm-memory-450p.webm Video]
* [http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2010.07.23a.pdf Memory Barriers - A Hardware View for Software Hackers] - This is a highly-rated paper that explains memory barrier issues - as the title suggests, it is designed to describe the hardware origin of the problem to software developers. Despite the fact that it is an introduction to the topic, it is still very technical.
* [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka14041.html ARM Technical Support Knowlege Article - In what situations might I need to insert memory barrier instructions?] - Note that there are some additional mechanisms present in ARMv8 aarch64, including Acquire/Release.
* [https://www.kernel.org/doc/Documentation/memory-barriers.txt Kernel Documentation on Memory Barriers] - discusses the memory barrier issue generally, and the solutions used within the Linux kernel. This is part of the kernel documentation.
* Acquire-Release mechanisms
** [http://blogs.msdn.com/b/oldnewthing/archive/2008/10/03/8969397.aspx MSDN Blog Post] with a very clear explanation of Acquire-Release.
** [http://preshing.com/20130922/acquire-and-release-fences/ Preshing on Programming post] with a good explanation.
** [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.genc010197a/index.html ARMv8 Instruction Set Architecture Manual] (ARM InfoCentre registration required) - See the section on Acquire/Release and Load/Store, especially Load/Store Exclusive (e.g., LDREX)
 
==== Atomics ====
'''Atomics''' are operations which must be completed in a single step (or appear to be completed in a single step) without potential interruption.
* Wikipedia has a good basic overview of the need for atomicity in the article on [http://en.wikipedia.org/wiki/Linearizability Linerarizability]
* GCC provides intrinsics (built-in functions) for atomic operations, as documented in the GCC manual:
** [http://gcc.gnu.org/onlinedocs/gcc-4.9.1/gcc/_005f_005fsync-Builtins.html#_005f_005fsync-Builtins Legacy __sync Built-in Functions for Atomic Memory Access]
** [http://gcc.gnu.org/onlinedocs/gcc-4.9.1/gcc/_005f_005fatomic-Builtins.html#_005f_005fatomic-Builtins Built-in functions for memory model aware atomic operations]
* The Fedora project has some guidelines/recommendations for the use of these GCC builtins:
** http://fedoraproject.org/wiki/Architectures/ARM/GCCBuiltInAtomicOperations
 
=== Friday (Oct 17) ===
 
* [[Compiler Intrinsics]]
* Selecting your project.
** Criteria:
**# Interest
**# Scope
**# Fit between your skills and project needs
**# Upstream status (e.g., dead project)
 
=== Week 7 Deliverables ===
 
# Select at least two software packages from the [http://performance.linaro.org|Linaro performance web site] and/or the [[Fall 2014 SPO600 Packages by Participant|Packages]] page.
# Record your choice on:
## The [[Fall 2014 SPO600 Participants|Participants page]]
## The [http://performance.linaro.org|Linaro performance web site]
# Investigate and blog about your choice.
 
'''Over reading week:'''
# Contact the upstream communities for the packages you have selected
# Formulate a work plan that will conclude with landing your software changes in the upstream software before the end of the course.
<!--
Platform-specific code is often utilized for '''Memory Barriers''' and '''Atomics Operations'''.
==== Memory Barriers ====
'''Memory Barriers''' ensure that memory accesses are sequenced so that multiple threads, processes, cores, or IO devices see a predictable view of memory.
* Leif Lindholm provides an excellent explanation of memory barriers.
** Blog series - I recommend this series, especially the introduction, as a very clear explanation of memory barrier issues.
*** Part 1 - [http://community.arm.com/groups/processors/blog/2011/03/22/memory-access-ordering--an-introduction Memory Access Ordering - An Introduction]
*** Part 2 - [http://community.arm.com/groups/processors/blog/2011/04/11/memory-access-ordering-part-2--barriers-and-the-linux-kernel Memory Access Ordering Part 2 - Barriers and the Linux Kernel]
*** Part 3 - [http://community.arm.com/groups/processors/blog/2011/10/19/memory-access-ordering-part-3--memory-access-ordering-in-the-arm-architecture Memory Access Ordering Part 3 - Memory Access Ordering in the ARM Architecture]
** Presentation at Embedded Linux Conference 2010 (Note: Acquire/Release in C++11 and ARMv8 aarch64 appeared after this presentation):
*** [http://elinux.org/images/f/fa/Software_implications_memory_systems.pdf Slides]
*** [http://free-electrons.com/pub/video/2010/elce/elce2010-lindholm-memory-450p.webm Video]
* [http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2010.07.23a.pdf Memory Barriers - A Hardware View for Software Hackers] - This is a highly-rated paper that explains memory barrier issues - as the title suggests, it is designed to describe the hardware origin of the problem to software developers. Despite the fact that it is an introduction to the topic, it is still very technical.
* [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka14041.html ARM Technical Support Knowlege Article - In what situations might I need to insert memory barrier instructions?] - Note that there are some additional mechanisms present in ARMv8 aarch64, including Acquire/Release.
* [https://www.kernel.org/doc/Documentation/memory-barriers.txt Kernel Documentation on Memory Barriers] - discusses the memory barrier issue generally, and the solutions used within the Linux kernel. This is part of the kernel documentation.
* Acquire-Release mechanisms
** [http://blogs.msdn.com/b/oldnewthing/archive/2008/10/03/8969397.aspx MSDN Blog Post] with a very clear explanation of Acquire-Release.
** [http://preshing.com/20130922/acquire-and-release-fences/ Preshing on Programming post] with a good explanation.
** [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.genc010197a/index.html ARMv8 Instruction Set Architecture Manual] (ARM InfoCentre registration required) - See the section on Acquire/Release and Load/Store.
 
==== Atomics ====
'''Atomics''' are operations which must be completed in a single step (or appear to be completed in a single step) without potential interruption.
* Wikipedia has a good basic overview of the need for atomicity in the article on [http://en.wikipedia.org/wiki/Linearizability Linerarizability]
* GCC provides intrinsics (built-in functions) for atomic operations, as documented in the GCC manual:
** [http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/_005f_005fsync-Builtins.html#_005f_005fsync-Builtins Legacy __sync Built-in Functions for Atomic Memory Access]
** [http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/_005f_005fatomic-Builtins.html#_005f_005fatomic-Builtins Built-in functions for memory model aware atomic operations]
* The Fedora project has some guidelines/recommendations for the use of these GCC builtins:
** http://fedoraproject.org/wiki/Architectures/ARM/GCCBuiltInAtomicOperations
=== Friday (Feb 7) ===
Retrieved from "https://wiki.cdot.senecapolytechnic.ca/wiki/Special:MobileDiff/106461"