This is the SPO600 tentative course schedule. It's a live document and will be revised throughout the semester. Each topic will be linked to notes at the end of this page as the course proceeds.
Classes marked Async will be delivered in asynchronous online mode.
Note: these summary videos are no substitute for attending class in-person! They do 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!
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. This code must be 'ported' or adapted to work on other platforms.
Reasons that code is architecture-specific:
Reasons for writing code in machine-specific Assembly Language include:
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 recently 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).
An additional architecture is on the horizon: Risc-V (pronounced “Risk-Five”). This is an experimental architecture which is open-source and may provide a competitive alternative to ARM and other architectures in the future.
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.
Optimization is tied to the concept of Portability because optimization techniques vary according to the details of the target architecture.
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.
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 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.
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:
The updating is done in batches every few days – allow some time!
This is an asynchronous class - there is no live meeting.
Pre-recorded Video:
This is an asynchronous class - there is no live meeting.
Pre-recorded video:
1. IFUNC - The ifunc capability allows a program to provide multiple implementations of a function, and to use a “resolver function” which is run once at program initialization to determine which implementation will be used. The resolver function returns a pointer to the selected function, which is used from that point on as for the life of the process. This capability is very flexible but requires the programmer to create:
2. FMV - The GCC compiler includes a function multiversioning capability for x86_32, x86_64, powerpc, and aarch64 architectures (with slightly different implementations). FMV is similar to ifunc, and can be used in two different ways:
This requires fewer code changes than ifunc, but still requires that the programmer state the architectural variants that will be targetted. The programmer also needs to know (or guess!) which functions would benefit from multiversioning.
3. AFMV - This “automatic function multi-versioning” capability does not exist yet, and is what we're working towards building. AFMV should work like FMV function cloning, but without any source code changes; instead, a compiler option will be used to specify the architectural variants of interest, and any function that would benefit from function multi-versioning will be automatically cloned. It is proposed that AFMV operate in this fashion:
GCC IFUNC documenation:
Current documentation:
target_clones syntax__HAVE_FEATURE_MULTI_VERSIONING (or __FEATURE_FUNCTION_MULTI_VERSIONING or __ARM_FEATURE_FUNCTION_MULTIVERSIONING) does not appear to be defined (as of GCC 14.2.1)Implementation in GCC
__attribue__((target("nnn"))) - where nnn may take the form of “default”, or “feature” eg., “sse4.2”, or “feature,feature” e.g., “sse4.2,avx2”, or it may take the form “arch=archlevel” e.g., “arch=x86-64-v3” or “arch=atom”__attribute__((target_clone("nnn1", "nnn2" [...])))__attribute__((target_version("nnn"))) - where nnn may take the form of “default”, or “feature” e.g., “sve”, or “feature+feature” e.g., “sve+sve2” (Note: in some earlier versions of GCC, a plus-sign was required at the start of the feature list, e.g., “+sve” instead of “sve”. This was changed by gcc 14). Note the use of the attribute target_version as opposed to target (as used on x86) which is compliant with the ACLE specification; it appears possible to use target in some versions of the GCC compiler (apparently with the plus-sign at the start of the feature-list?). Note that the “arch=nnn” format is not supported (and probably should be).__attribute__((target_clone("nnn", "nnn" [...]))) - note that contrary to the ACLE documentation, there is no automatic “default” argument - the first argument supplied should be “default”There are some technical issues with camera focus on the video for this week. My apologies for the low quality!
The sound volume scaling examples mentioned in the video may be found in the file /public/spo600-volume-examples.tgz on either of the SPO600 Servers.
For some SVE/SVE2 example code, see /public/spo600-sve-sve2-ifunc-examples.tgz on aarch64-001.spo600.cdot.systems. This archive contains:
spo600/examples/sve2-test - Example SVE2 code, in vectorizable C, inline assembler, and C with intrinsicsspo600/examples/sve2-test/sve-width - Example inline assembler code C intrinsic code for determining the width of the SVE/SVE2 vectors on a given systemspo600/examples/ifunc - Test/demo code using ifunc with 3 versions of a dummy function (advanced SIMD, SVE, and SVE2)spo600/examples/autoifunc)
Here is some of the code that was discussed in the lecture; this is the execute() method from a pass:
unsigned int pass_ctyler::execute (function *fun) { basic_block bb; if (dump_file) { fprintf(dump_file, "--------------------------------------------------------------------\n"); fprintf(dump_file, "Function: %s\n", IDENTIFIER_POINTER(DECL_NAME(fun->decl)) ); fprintf(dump_file, "--------------------------------------------------------------------\n"); FOR_EACH_BB_FN(bb, fun) { for (gimple_stmt_iterator gsi = gsi_start_bb(bb); !gsi_end_p(gsi); gsi_next(&gsi)) { gimple *stmt = gsi_stmt(gsi); print_gimple_stmt(dump_file, stmt, 0, TDF_NONE); fprintf(dump_file, "\n Gimple code: %d\n", gimple_code(stmt) ); fprintf(dump_file, " Gimple code name: %s\n", gimple_code_name[gimple_code(stmt)] ); fprintf(dump_file, "--------------------------------------------------------------------\n"); } fprintf (dump_file, "\n\n#### End ctyler diagnostics, start regular dump of current gimple ####\n\n\n"); } } return 0; }