User Tools

Site Tools


spo600:start
You were redirected here from spo600:spo600.

SPO600 - 2024 Fall

This is the SPO600 course schedule. It's a live document and will be revised as the course proceed. Each topic will be linked to notes at the end of this page as the course proceeds.

WeekWeek of …Class I (Tuesday - Syncronous on Zoom)Class II (Thursday - Asynchronous)Deliverables
Week 1September 2Introduction, Course Setup (incl SSH Keys)Binary Representation of Data, Introduction to Computer ArchitectureSetup Communication Tools
Week 2September 9Introduction to 6502 Assembly Language6502 Math and Flow ControlLab 1
Week 3September 166502 MathCompiler Internals and Compiler FlagsLab 2
Week 4September 236502 StringsCompiler OptimizationsLab 3
Week 5September 3064-Bit AssemblerSIMD, SVE, & SVE2Blog posts group 1
Week 6October 764-Bit Assembler LabIFunc, FMV, AFMVLab 4
Week 7October 14Building GCC, Initial Project DiscussionProject Stage 1 DetailsProject bogging
Reading WeekOctober 21Reading Week
Week 8October 28Project DiscussionProfilingProject Stage 1, Blog posts group 2
Week 9November 4Strategies for AFMV ParingPaged Memory ConceptsProject blogging
Week 10November 11Project DiscussionAdvanced Memory Concepts Project blogging
Week 11November 18Project DiscussionMemory Access in Multicore SystemsProject stage 2, Blog posts group 3
Week 12November 25Strategies for Landing AFMVProject RecommendationsProject blogging
Week 13December 2Project DiscussionProject RecommendationsProject blogging
Week 14December 9Course Wrap-UpNo classProject Stage 3, Blog posts group 4

Current Participants

Week 1

Week 1 - Class I

Video

Note: these summary videos are no substitute for attending class in-person! It does not include: quizzes and quiz answer discussion, group exercises, and group discussion. It may take several days to process and edit the video before it is made available. It may not record properly and may not be made available. Do not rely only on the summary videos!

General Course Information

  • Course resources are linked from this wiki.
  • Coursework is submitted by blogging. The only exception to this is quizzes.
  • Quizzes will be short (equivalent to ~1 page) and will be held without announcement at the start of any synchronous (Tuesday) class. The quizz answers will be discussed immediately after submission. There is no opportunity to re-take a missed quiz, but your lowest three quiz scores will not be counted, so do not worry if you miss one or two.
    • Students with test accommodations: alternate quizzes can be made available via the Test Centre. Communicate with your professor for details.
  • Course marks (see Weekly Schedule for dates):
    • 60% - Project Deliverables in three phases (15%, 20%, 25%)
    • 20% - Communication (Blog writing, in four phases, 5% each)
    • 10% - Labs
    • 10% - Quizzes (lowest 3 quiz scores not counted)

About SPO600 Classes

  • Online Classes
    • Synchronous: Tuesday 1:30-3:15 pm. Attendance at the Tuesday classes is mandatory.
      • Summary video(s) may be posted on a best-effort basis (technical issues may prevent posting in some cases). The summary video will be edited and will not include all of the content covered in class. The link(s) to the video(s) will be posted on this page under the corresponding date. The video will not cover all of the synchronous session, and may not be posted if there are any technical issues with the recording. Do not rely on the summary videos.
    • Asynchronous: Resources will be released by Thursday 1:30 pm. You are expected to review and learn this material before the following class (the next Tuesday).
    • Please attend the online sessions and take lots of notes.

Introduction to the Problems

Porting and Portability
  • Most software is written in a high-level language which can be compiled into machine code for a specific computer architecture. In many cases, this code can be compiled or interpreted for execution on multiple computer architectures - this is called 'portable' code. However, there is a lot of existing code that contains some architecture-specific code fragments which contains assumptions about the architecture, resulting in architecture-specific high-level or Assembly Language code.
  • Reasons that code is architecture-specific:
    • System assumptions that don't hold true on other platforms
      • Variable or word size
      • Memory ordering
      • Specific machine details, such as memory page size, stack order, or edge-case floating-point behavior
    • Code that takes advantage of platform-specific features
  • Reasons for writing code in machine-specific Assembly Language include:
    • Performance
    • Direct access to hardware features, e.g., CPUID registers
  • Most of the historical reasons for using assembler are no longer valid. Modern compilers can out-perform most hand-optimized assembly code, atomic operations can be handled by libraries or compiler intrinsics, and most hardware access should be performed through the operating system or appropriate libraries.
  • A new architecture has appeared: AArch64, which is a 64-bit execution state introduced as part of ARM architecture version 8 (ARMv8). This is the first new computer architecture to appear in several years (at least, the first mainstream computer architecture).
  • At this point, most key open source software (the software typically present in a Linux distribution such as Ubuntu or Fedora, for example) now runs on AArch64. However, it may not yet be as extensively optimized as on older architectures (such as x86_64).
Optimization

Optimization is the process of evaluating different ways that software can be written or built and selecting the option(s) that has the best performance tradeoffs for the situation at hand.

Optimization may involve substituting software algorithms, altering the sequence of operations, using architecture-specific code, selecting data types, or altering the build process. It is important to ensure that the optimized software produces correct results and does not cause an unacceptable performance regression for other use-cases, system configurations, operating systems, or architectures.

The definition of “performance” varies according to the target system and the operating goals. For example, in some contexts, low memory or storage usage is important; in other cases, fast operation; and in other cases, low CPU utilization or long battery life may be the most important factor. It is often necessary to trade off performance in one area for another; using a lookup table, for example, can reduce CPU utilization and improve battery life in some algorithms, in return for increased memory consumption.

Virtually all compilers (and interpreters) perform some level of optimization, and the options selected for compilation can have a significant effect on the trade-offs made by the compiler, affecting memory usage, execution speed, executable size, power consumption, and debuggability.

However, there are some types of optimization that cannot be applied by the compiler, and which must be applied by the programmer.

Build Process

Building software is a complex task that many developers gloss over. The simple act of compiling a program invokes a process with five or more stages, including pre-processing, compiling, optimizing, assembling, and linking. However, a complex software system will have hundreds or even thousands of source files, as well as dozens or hundreds of build configuration options, auto configuration scripts (cmake, autotools), build scripts (such as Makefiles) to coordinate the process, test suites, and more.

The build process varies significantly between software packages. Most software distribution projects (including Linux distributions such as Ubuntu and Fedora) use a packaging system that further wraps the build process in a standardized script format, so that different software packages can be built using a consistent process.

In order to get consistent and comparable benchmark results, you need to ensure that the software is being built in a consistent way. Altering the build process is one way of optimizing software.

Note that the build time for a complex package can range up to hours or even days!

Benchmarking and Profiling

Benchmarking involves testing software performance under controlled conditions so that the performance can be compared to other software, the same software operating on other types of computers, or so that the impact of a change to the software can be gauged.

Profiling is the process of analyzing software performance on finer scale, determining resource usage per program part (typically per function/method). This can identify software bottlenecks and potential targets for optimization. The resource utilization studies may include memory, CPU cycles/time, or power.

Communication Tools Setup

Follow the instructions on the SPO600 Communication Tools page to set up a blog, create SSH keys, and send your blog URLs and public key to me.

I will use this information to:

  1. Update the Current SPO600 Participants page with your information, and
  2. Create an account for you on the SPO600 Servers, if you didn't do that during class.

The updating is done in batches every few days – allow some time!

Introduction to the 6502 Processor

The 6502 Processor is a simple 8-bit processor that powered a number of early microcomputers (and video games). We're going to use it to learn machine language and assembly language concepts before tackling modern processors (because the 6502 instruction set can be documented in one page rather than 7000 pages!).

  • 6502 - Basic information about the processor
  • We'll continue exploration of this processor in the next class…

Week 1 - Class II

Video

Due to a power + Internet outage, these videos are from a previous semester.

Week 1 Deliverables

Week 2

Week 2 - Class I

Video

6502 Assembly Language Programming

Lab 1

Week 2 - Class II

Video

Resources

Week 2 Deliverables

  • Complete and blog about Lab 1

Week 3

Week 3 - Class I

Video

Resources

Lab 2

Week 3 - Class II

Video

Resources

Week 3 Deliverables

  • Complete and blog about Lab 2

Week 4

Week 4 - Class I

Video

  • This video does not include the quiz answers or discussion of the blog posts.

Code

Lab 3

Week 4 - Class II

Video

Resources

Week 4 Deliverables

  • Complete and blog about Lab 3
  • Reminder: the first group of blogs is due next week (Oct 6 11:59 PM)

Week 5

Week 5 - Class I

Video

64-bit Class Servers

64-bit Assembly Language

Week 5 - Class II

Video

Week 5 Deliverables

  • Wrap up your Blog Posts Group 1 by Sunday Midnight (Oct 6)

Week 6

Week 6 - Class I

Video

  • Video to follow

64-bit Class Servers - Changes

  • Note that the AArch64 server was reinstalled. When using SSH to this server (aarch64-001.spo600.cdot.systems) you may see a message saying the host key has changed. Remove the appropriate line in your old known_hosts file to clear this message.
  • The x86 server is now available.
  • Remember: These servers are never backed up and may go offline temporarily or permanently, or be reinstalled or migrated, at any time. Back up all of your work!

Lab 4

Week 6 - Class II

Due to techical issues, the content for Week 6 - Class II will be covered in the October 15th class.

Week 6 Deliverables

  • Complete Lab 4 and blog about it

Week 7

Week 7 - Class I

64-bit Class Servers - Changes

  • A second aarch64 server (aarch64-002.spo600.cdot.systems) is now available. This machine has more RAM and is suitable for performing large builds (such as GCC for the course project).
  • Remember: These servers are never backed up and may go offline temporarily or permanently, or be reinstalled or migrated, at any time. Back up all of your work!

Video

  • Video to follow

How to Build GCC

Week 7 - Class II

Video

  • There is no video content for today.

Course Project - Stage 1: Preparation

    • This stage involves preparing to modify the GCC compiler
    • You will obtain the source code for GCC and build it on both architectures
    • The codebase is very large - tens of millions of lines across many thousands of files!
    • One key to learning to navigate such a large codebase is learning to ignore most of the code and zero in on the specific code of interest

Week 7 Deliverables

spo600/start.txt · Last modified: 2024/10/17 18:04 by chris

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki