The Au Library: Handling Physical Units Safely, Quickly, and Broadly

Tuesday, October 3 • 14:00 - 15:00

by Chip Hogg

We present Au: a new open-source C++ units library, by Aurora.  If you've rejected other units libraries because they couldn't meet your needs, check out Au (pronounced, "ay yoo").  It combines cutting-edge developer experience (fast compilation, simple and readable compiler errors) with wide accessibility (C++14 compatibility, single-header delivery option).  You can be up and running with Au in your project --- in any build system --- in less time than it takes to read this abstract!

We'll orient the viewer by providing a decision framework for choosing a units library, and using this framework to compare several leading options. We'll also see how these libraries influence each other. For example, Au has several compelling features inspired by other libraries, such as the concise and readable compiler errors of mp-units, and the frictionless single-header delivery of the nholthaus library --- in fact, Au is the first library to provide both these features at once. Au has also provided many new features of its own, including: fully unit-safe APIs; an adaptive "overflow safety surface" that governs unit conversions; on-the-fly composition for units and prefixes; smart, unit-aware rounding and inverse functions; and more.

Finally, Au has a notably low barrier to migration --- in either direction.  We'll explain how to set up a correspondence between Au and any other units library.  Even though neither library knows about the other, you'll be able to pass Au-typed variables to APIs which take the other library's types, and vice versa.  This doesn't just make it easy to switch to Au; it promises a smooth upgrade path to any better library which comes along later (such as a future C++ standard units library).  With such a low barrier to entry, give Au a try, and find out what it feels like to get effortlessly correct handling for all your physical quantities!

Back to Basics: Iterators

Tuesday, October 3 • 14:00 - 15:00

by Nicolai Josuttis

One key success factor of C++ was the introduction of the Standard Template Library (STL) bringing together containers/ranges and algorithms using iterators as glue API to iterate over elements of collections.

This talk will present the basics of the design of iterators, the various consequences, remarkable corner cases, and what this means when using ranges and views as introduced with C++20.

"Distributed Ranges": A Model for Building Distributed Data Structures, Algorithms, and Views

Monday, October 2 • 16:45 - 17:45

by Benjamin Brock

Writing programs that run on clusters of computers is notoriously difficult. Distributed data structures can simplify this problem by automatically splitting up data across multiple memory spaces or nodes in a distributed memory program. Algorithms in most distributed data structures libraries, however, are not generic, but operate only on a specific data structure. In this work, we discuss how modern C++ features like concepts, customization points, and the ranges library can be used to support generic algorithms and views that can interoperate with multiple distributed data structures. We first discuss background in distributed computing and distributed data structures, including common techniques used to create high-level distributed data structures. We then show how customization point objects and concepts can be used to allow the implementation of generic algorithms that can be used with any distributed data structure as long as it fulfills a "distributed range" concept. We then show how to implement views that satisfy this concept, allowing algorithms to operate on lazily evaluated views of distributed data structures. Finally, we discuss two implementations of this model, for multi-GPU and multi-node programs, as well as performance considerations when running on state-of-the-art HPC systems.

Expressing Implementation Sameness and Similarity in Modern C++ 

Tuesday, October 3 • 14:00 - 15:00

by Daisy Hollman

Polymorphism is among the most widely discussed introductory topics in software engineering. Often couched in a vague context of code reuse, much of this introductory focus nonetheless revolves around interface similarity. More advanced discussions of code reuse in software engineering typically revolve around general topics like the maintainability cost of code coupling, but usually avoid discussing the merits of advanced language-specific mechanisms for code reuse. Furthermore, very little is made of the information loss and cognitive load associated with poor expression of sameness in implementation, regardless of interface coupling concerns.

In this talk, we will examine the wide spectrum of tools for expressing “sameness” in modern C++. Beyond introductory “is-a” inheritance and runtime polymorphism, we will delve into templates, concepts, mixins, CRTP, C++23’s “deducing this,” and a number of more advanced techniques on the spectrum from generic programming to template metaprogramming. We will explore the long-term software engineering costs and benefits of each of these mechanisms. In each case, we will discuss important trade-offs, such as runtime and compile-time overhead, mechanistic complexity versus “sameness” information loss, code coupling, maintainability, and the ability to adapt to evolving implementation needs over time. Finally, we will discuss mechanisms for expressing “sameness” that are difficult or impossible in modern C++—such as dependency injection and aspect-oriented programming—but that are commonplace in other languages. We will delve into both the minimal and ideal language features that would enable these paradigms to become a part of the C++ toolbox, and we will discuss the outlook for the inclusion of such features in future versions of standard C++.

C++ Exceptions and Memory Allocation Failure

By Wu Yongwei

C++ exceptions are habitually disabled in many software projects. A related issue is that these projects also encourage the use of new (nothrow) instead of the more common new, as the latter may throw an exception. This choice is kind of self-deceptive, as people don’t usually disable completely all mechanisms that potentially throw exceptions, such as standard library containers and string. In fact, every time we initialize or modify a string, vector, or map, we may be allocating memory on the heap. If we think that new will end in an exception (and therefore choose to use new (nothrow)), exceptions may also occur when using these mechanisms. In a program that has disabled exceptions, the result will inevitably be a program crash.

However, it seems that the crashes I described are unlikely to occur… When was the last time you saw a memory allocation failure? Before I tested to check this issue, the last time I saw a memory allocation failure was when there was a memory corruption in the program: there was still plenty of memory in the system, but the memory manager of the program could no longer work reliably. In this case, there was already undefined behaviour, and checking for memory allocation failure ceased to make sense. A crash of the program was inevitable, and and it was a good thing if the crash occurred earlier, whether due to an uncaught exception, a null pointer dereference, or something else.

Now the question is: If there is no undefined behaviour in the program, will memory allocation ever fail? This seems worth exploring.

Open Content: C++ Conversation: Object Lifetime

Monday, October 2 • 12:30 - 13:30

by Jason Turner

Want to learn more about C++ in a highly interactive way?

We will have a lunchtime group conversation about C++ Object Lifetime. We will discuss the types of Object Lifetime that exist in C++, and go through some fun puzzle-like exercises together.

Expect a casual, relaxed, fun, interactive setting to spend your lunch time!

Back to Basics: Debugging

Monday, October 2 • 11:00 - 12:00

by Greg Law

Everyone knows that debugging is twice as hard as writing a program in the first place. Fortunately, there is more help available than you might have thought. GDB is much more powerful than most people realize; Valgrind and Address Sanitizer can catch many common bugs before they wreak havoc; time-travel debugging can turn even the most intractable nightmarish bugs into pussycats. This fast-paced talk is light on slides and heavy on demos to show you what's available and how to use it. Familiarity with the tools available to you is an essential part of being a great programmer; you will leave this talk at least one step closer to programming zen.

Cache-friendly Design in Robot Path Planning

Monday, October 2 • 17:20 - 17:55

by Brian Cairl

Point-to-point planning is a major component in virtually all mobile robotic systems. These systems may require agents to generate paths over very large areas on demand; and sometimes several more times during their journey as part of intelligent recovery routines under dynamic environmental conditions. Since planning over large areas is a resource-intensive operation, particularly in higher-dimensional state-spaces, planning routines must be carefully tuned to execute as efficiently as possible so as to prevent perceptible delays in robot responsiveness.

Attendees can expect an overview of common planning algorithms used in robotics, such as Dijkstra's and A-star, to provide a motivating context. Rather than focus on time saving tricks specific to a particular environment or robot morphology, we will instead focus on getting the most out of these algorithms by way of leveraging cache-friendly design of requisite graph and memoization structures; and memory layouts. In particular, we will focus on achieving these results using common C++ STL facilities; and compile-time facilities to promote generic design, where possible. Finally, we will provide comparisons between naive and cache-optimized implementations; and guides for effectively profiling these algorithms for system-specific tuning purposes.

Effective Ranges: A Tutorial for Using C++2x Ranges

Monday, October 2 • 16:45 - 17:45

by Jeff Garland

This course provides in introduction to using C++ ranges effectively. Ranges are the largest revamp of the Standard Template Library (STL) in 20 years and impacts daily C++ programming dramatically. The presentation provides a survey of C++20 and C++23 ranges and their application. Note that C++14/17 programmers can also benefit since Range v3 library provides an implementation of many of the discussed facilities.

The tutorial goes beyond the basics to explore what's behind the ranges library. For example, understand the key differences between algorithms and views and when to apply them. We'll look at some of the concepts used in the design of ranges. And finally we'll explore how ranges fits into the wider standard library with i/o integration, collection integration, and support of legacy stl algorithms.

Chock full of example code this tutorial will bootstrap programmer's usage of std::ranges.

Your Performance Todo List 2: Maintaining Performance Scalability and Avoiding Bottlenecks

Tuesday, October 3 • 09:00 - 10:00

by Jan Bielak

Writing efficient programs is hard. This is because it requires a lot of knowledge, experience and strategic thinking. There have been many talks on optimization and often each addresses a single concept. Being able to achieve a bird’s eye view of factors affecting performance often requires many hours of researching the topic. To lessen the mental burden of optimizing programs, I have picked out the techniques, I believe are most important. During the talk, I will present them in an organized manner and provide practical examples of how they can be applied.

I will first discuss what I believe are the main goals efficient programs strive to achieve. Then, I will present the general methods of achieving those goals. Then, for the majority of the talk, we will discuss a few dozen performance opportunities. For each of them, I will explain the underlying mechanism of how the optimization works. I will avoid bluntly giving guidelines to follow without explanation. Each of the techniques naturally comes with its costs, and those will be discussed as well.

I will additionally discuss various performance pitfalls. These are sometimes called “premature pessimizations” in contrast to the often used term of “premature optimizations”. I will show examples of optimizations which do not incur any cost on program readability or maintainability and as such should be considered performance best practices. Avoiding their use doesn’t improve code in any manner, while making it slower.

This talk is intended for a diverse audience, as, after all, probably most of the C++ community is interested in performance. It is appropriate for hobbyists and professionals alike, with varying experience with the language, due to the gradual increase in difficulty of examples. It will be a time productively spent.

----

This presentation builds upon "Your Performance Todo List", from last year's conference (30k+ views, 8th most viewed). It will serve as an extension to its material, by revisiting certain topics and explaining them in more detail as well as by providing more examples of techniques and their applications. Specifically, it will first provide a more in-depth and illustrative view of various microarchitectural details and their impact on performance, as well as of relevant optimizations:
* branch prediction and speculative execution,
* pipelining and out of order execution,
* vectorization and SIMD processing,
* cache and memory functioning and intercommunication.

Then, the talk will focus on the topics emerging as being the most crucial to maintaining performance scalability - parallelism and concurrency. I will ground multithreading concepts, like atomics, memory barriers, and other synchronization primitives, in the context of both the theoretical C++ memory model as well as specific cache coherency protocols.

I will also discuss the interactions between a user-space application and the underlying operating system as well as their effects on performance.