CppCon 2016

Welcome! Let's get the paperwork out of the way.

This is a philosophical talk. It deals with ideals, aims, and ways of approximating those. It deals with practical constraints and risks. It gives short examples. It presents a perspective of what drives the evolution of C++. What is C++ and what it must become over the next years for its success to continue? This involves both social and technical points. Towards the end, I discuss the direction of C++ future evolution, give some opinions, point to urgently needed new features, and discuss how to manage until they are part of the standard.

C++ has a pretty good type system, and modern C++ gives us a greater ability than ever before to use that type system for good: to make APIs easier to use and harder to misuse, to make our datatypes more closely express our intent, and generally to make code safer, more obvious in function and perhaps even faster.

This is an interactive session - incorporating games played between presenter and audience, even - taking a look at choices available to us as datatype and API designers, and examining how a little knowledge about the algebra of algebraic datatypes can help. We'll see why std::optional and (hopefully soon) std::variant will quickly become an essential part of everyone's toolbox, and also explore how types can be used to express not just the structure of data, but also the behaviour of objects and functions.

This talk will cover every feature addition, removal, and change in the next version of the C++ standard, provisionally going by the name C++17. Covering both the language and the library, the coverage of any given feature must necessarily brief. The goal is to come away with an understanding of what each feature is, and why you might want to use it, with an overall impression of how the new language might fit together. It is not intended to be an detailed tutorial on any individual feature, but rather, a jumping off point for further sessions on the topics that seem most interesting.

This talk will cover every feature addition, removal, and change in the next version of the C++ standard, provisionally going by the name C++17. Covering both the language and the library, the coverage of any given feature must necessarily brief. The goal is to come away with an understanding of what each feature is, and why you might want to use it, with an overall impression of how the new language might fit together. It is not intended to be an detailed tutorial on any individual feature, but rather, a jumping off point for further sessions on the topics that seem most interesting.

The field of computer science is ever evolving. Not long ago, software developers were able to get "free" performance upgrades with every bit of advancement in CPU architectures. Frequency boost, cache capacity increase, and more sophisticated pipeline all brought significant performance improvements in sequential execution. Now computing has hit the power wall and the performance of a single core has been pushed past the point of diminishing returns. The hardware design begins to shift towards massive parallelism on both chip level. Exploiting thread level parallelism is thus essential for software developers. C++ provides the capability to operate on powerful hardware synchronization primitives such as compare_and_swap, which is indispensable for building concurrent libraries to facilitate the development of high-performance parallel applications.

With the growing availability of concurrent libraries such Boost.Lockfree, Intel TBB, and LibCDS, more and more programmers embrace the concept of lock-free programming. Lock-free data structures provides scalable thread-safe concurrent accesses and guarantee that at any moment at least one thread will make progress. Compared with traditional lock-based approaches, lock-free algorithms utilize fine-grained synchronizations and tolerate thread faults. However, none of the existing lock-free data structures supports transactions yet, which require that a sequence of method calls on the data structures appears to complete in an atomic step and in isolation with regards to other ongoing transactions. Because of this, the users of lock-free libraries who need transaction executions often are forced to fall back to coarse-grained locking which has a negative impact on performance and annihilates the non-blocking progress guarantee provided by the libraries. We propose a holistic approach for developing future non-blocking transactional data structures — an open source library of transactional data structures based on existing non-blocking data structures.
This library will be built on three of the presenters' research works: 1) multi-resource lock (MRLock), which is a scalable lock manager with efficient FIFO conflict revolve scheme; 2) lock-free transactional transformation (LFTT), which is a methodology for transforming high-performance lock-free base data structures into high-performance lock-free transactional data structures; and 3) multi-dimensional linked list (MDList), which is a novel logarithmic search data structure optimized for concurrent accesses.

In the session, we will discuss two strategies for implementing scalable transactional data structures using both locks and lock-free synchronizations. The locking strategy employs MRLock, which is a novel shared-memory resource allocation lock for multi-core processors. It uses a lock-free FIFO queue to manage locking requests in batches, which minimizes memory contention among threads. It is fast and designed as a drop-in replacement for the two-phase locking methods in C++11 and Boost library (std::lock() and boost::lock()). When combined with existing lock-based transaction synchronization techniques such as semantic locking and transaction boosting, it can be used by programmers who prefer lock-based code to implement high-performance transactional data structures on familiar grounds. The lock-free strategy is based on lock-free transactional transformation (LFTT), which uses transaction descriptor object to announce the transaction globally so that delayed threads can be helped. It is applicable to linked data structures such as linked lists and skip lists. The logical status of any node in the data structure depends on the status of the transaction descriptor that was embedded in it. Conflict transactions do not need to revert their operations as required in some of the existing methodologies. We will demonstrate the application of this strategy to existing lock-free lists and skip lists.

We will also introduce a lock-free logarithmic search data structure based on multi-dimensional linked list. This brand new data structure is designed from ground up to achieve full potential for concurrent accesses. It has a distributed memory layout which alleviates contention. Write operations modify at most two nodes so interference among operations are brought down to a minimum. This data structure implements the collection/dictionary abstract data type, which is ubiquitous in modern applications. When combined with the above mentioned transactional strategies, this work could greatly benefit application developers who deal with data intensive scenarios such as in memory databases.


Preliminary version of source code can be accessed from https://ucf-cs.github.io/tlds/. The research work mentioned in this presentation can be accessed from http://cse.eecs.ucf.edu/bios/delizhang.html.

Modern programs’ performance characteristics are often dictated by their data. Whether the cache locality of data access, the size of working set, or avoiding costly memory allocation overhead. Unfortunately, the standard C++ library data structures range from adequate to terrible at controlling these aspects, and they don’t provide any of the core mechanisms needed for extremely efficient data structure design.

This talk will present the core concepts of designing high performance data structures in C++. It is based on years of experience in the LLVM compiler as well as several other large code bases. From these principles, the talk will propose a suite of data structures that provide performance without loss of generality or functionality. As much as this talk will present specific data structure designs, its primary intent will be to give an understanding of what makes these structures have greater performance than more naive approaches.

Most of us have heard this story. We’ve even told it ourselves…

C++ is nearly all of C, plus a whole lot more. Migrating code from C to C++ is pretty easy. Moreover, the migration itself can yield immediate benefits by exposing questionable type conversions that can be sources of latent bugs. After migration, the code performs as well in C++ as in the original C. And now that it’s C++, you have ready access to a wealth of advanced features you can (but don’t have to) use to implement enhancements.

Who wouldn’t want that? Legions of C programmers, apparently.

Despite the success of C++ in numerous application domains, C remains considerably more popular, especially in embedded, automotive, and aerospace applications. In many cases, projects resist C++ because their managers think the risks outweigh the benefits. In other cases, the resistance comes from programmers who persist in believing bad things about C++, even when those things aren’t true.

What can the C++ community do to overcome this resistance? Drawing on lessons from cognitive science, linguistics and psychology, and (of course) computer science, this talk offers suggestions about how to make the case for C++ more persuasive to C programmers.

An overview of the additions to the standard C++ concurrency libraries in the Technical Specifications for Concurrency and Parallelism and the C++14 and C++17 standards. These additions include: continuations, latches, barriers, atomic smart pointers, shared ownership mutexes, executors, concurrent queues, distributed counters, coroutines, parallel algorithms and more.

GPU computing has gone mainstream. It is a dominant part of the performance landscape, providing the initial 10x performance lift to a wide variety of applications. However, programing for GPUs can be extremely challenging. C++ is rarely available in an unmodified form, and there are few portable and open source approaches available. One of the most popular platforms, CUDA, has no production quality open source implementation. As a consequence, its C++ support has lagged behind and it has been a less appealing area for researchers and others that weren’t comfortable relying on NVIDIA’s tooling.

However, today things are different. Clang is now a fully functional open-source GPU compiler. It provides a CUDA-compatible programming model and can compile most of the awesome CUDA libraries out there ranging from Thrust (the CUDA-enabled parallel algorithms library that gave rise to the new parallelism technical specification) to Eigen and TensorFlow.

In this talk we will give an overview of how LLVM and Clang support targeting C++ to GPUs, how they work to be compatible with existing CUDA code, and how you can build your code today to run on GPUs with this open source compiler.

This talk takes the “ultimately practical” approach to concurrent programming, with a focus on lock-free programs: after all, in reality such programs are almost always written in the hopes of getting better performance. We’re going to measure performance of the individual concurrent primitives and their effect on the overall performance of the whole program.

The goal of the talk is two-fold. On one hand, I will show a set of tools and practices that can be used to get quantitative measurements of the performance of different implementations under various load conditions. Mastering these techniques will allow the attendees to choose their concurrent algorithms and implementations based on solid data instead of guesswork or “common knowledge” (which is often wrong or outdated). On the other hand, even with the focus on real-life applications we can learn a few things about the fundamental nature of concurrent programs. This understanding comes especially useful when dealing with the “common knowledge” and “simple logic”. For example, it’s “common knowledge” that lock-free programs are faster than lock-based (not always). It’s also a “simple logic” that the hardware must protect shared memory access in a multi-core system, so ultimately locking is always present (sometimes true, sometimes true but misleading, and sometimes false). It is both “common knowledge” and “simple logic” that a wait-free program does not wait (but if your definition of wait is “will I have to wait for the results after I finish my coffee?” then it definitely does).

We will explore practical examples of (mostly) lock-free data structures, with actual implementations and performance measurements. Even if the specific limitations and simplifying assumptions used in this talk do not apply to your problem, the key point to take away is how to find such assumptions and take advantage of them in your specific application: after all, in reality it’s almost always about performance.

This talk discusses the ins and outs of how to write software that is at such a high standard that it gets reused everywhere. It covers organization, design, infrastructure, testing, documentation, reviews, and general suggestions based on my experience in the industry.

The Commodore 64 was released in 1982 and is the best selling computer model of all time. At 34 years old, even the most simple embedded processor today outperforms it. Join me on an exploration of how C++17 techniques can be utilized to write expressive, high performance, high level code for simple computers. Together we will create a game for this aging system.

You'll leave the talk with a better understanding of what your compiler is capable of and be able to apply these ideas to create better code on modern systems

One of the most powerful features of the C++ standard library is the collection of basic algorithms. Everyone knows about sort and copy, but there are is a lot of powerful capabilities in the other algorithms as well. In this talk, I will explore some of the algorithms in the library, and give a rationale for writing your own, along with examples.

The motivation for writing your own algorithms is that you can create generic building blocks that can be used over and over again in your library or application, and which will allow your to program at a higher level of abstraction. Instead of thinking, "how do I sort this vector", you just call std::sort. The same should apply to the algorithms that are specific to your domain - once you write them.

Most programmers should usually avoid C++ atomics altogether and use mutexes instead. If that's not possible, perhaps because the code must be usable in interrupt handlers, I recommend that you consider limiting yourself to sequentially consistent atomics, which provide a more subtle, but still reasonably unsurprising programming model. This talk will target those who choose to ignore both of those pieces of advice, for either good or bad reasons.

I will start by trying to distinguish the good and bad reasons for using weakly ordered atomics, and then follow with guidelines for using them correctly.

I will discuss why it is often incorrect to think of atomics in terms of fence-based implementations, and about some common errors I've seen, including some really convincing looking, but still incorrect, code. I will also try to go through some of the common idioms for which weakly ordered atomics are actually safe. In my experience, the latter are also reasonably common, but not always easy to distinguish from the subtly erroneous examples.

C++ was lacking the reflections feature for a long time. But a new metaprogramming trick was discovered recently: we can get some information about POD structure by probing it's braced initializes. Combining that trick with variadic templates, constexpr functions, implicit conversion operators, SFINAE, decltype and integral constants we can count structure's fields and even deduce type of each field.

Now the best part: everything works without any additional markup nor macros typically needed to implement reflections in C++.

In this talk I'll explain most of the tricks in detail, starting from a very basic implementation that is only capable of detecting fields count and ending up with a fully functional prototype capable of dealing with nested PODs, const/volatile qualified pointers, pointers-to-pointers and enum members. Highly useful use-cases will be shown a the end of the talk. You may start experimenting right now using the implementation at https://github.com/apolukhin/magic_get.

Small motivating example:

#include <iostream>
#include "magic_get.hpp"

int main() {
    struct foo { // no `ostream& operator <<` defined for `foo`!
        double d;
        char c;
   };

   foo f{ 1.0, '!' };
   std::cout << f; // Outputs `{1.0, !}`
}

Compile times are a pain point for C++ programmers all over the world. Google is no exception.. We have a single unified codebase with hundreds of millions of lines of C++ code, all of it built from source. As the size of the codebase and the depth of interrelated interfaces exposed through textually included headers grew, the scaling of compiles became a critical issue.

Years ago we started working to build technology in the Clang compiler that could help scale builds more effectively than textual inclusion. This is the core of C++ Modules: moving away from the model of textual inclusion. We also started preparing our codebase to migrate to this technology en masse, and through a highly automated process. It's been a long time and a tremendous effort, but we'd like to share where we are as well as what comes next.

In this talk, we will outline the core C++ Modules technology in Clang. This is just raw technology at this stage, not an integrated part of the C++ programming language. That part is being worked on by a large group of people in the ISO C++ standards committee. But we want to share how Google is using this raw technology internally to make today's C++ compiles faster, what it took to get there, and how you too can take advantage of these features. We will cover everything from the details of migrating a codebase of this size to use a novel compilation model to the ramifications for both local and distributed build systems. We hope to give insight into the kinds of benefits that technology like C++ Modules can bring to a large scale C++ development environment.

This talk will explain what public blockchain systems like Bitcoin and Ripple are, the unique challenges of developing software for them, and how C++ helps to meet these challenges. 

Security issues are paramount. Blockchain systems are open source, have large attack surfaces, and can cause significant financial damage if they have exploitable defects. Performance and scalability are also major concerns. 

C++ provides a unique balance that helps meet these challenges. The language's design makes it possible to catch bugs at compile time, write modular code that can be tested, develop flexible data structures and manage resources. Yet, where performance is critical, it does not obscure what your code is making the computer actually do. 

The primary purpose of the talk is to explain what blockchains are, increase understanding of the unusual challenges developers of blockchain software experience, and to demonstrate why C++ is a good choice to address them. 

Prominent members of the C++ community are advocating the "almost-always-auto" idiom, but there are understandable concerns from many about its implications. This case study will demonstrate how it may be applied in different situations, suggest ways to avoid performance penalties, introduce algorithms to minimize the "almost" part, and discuss the overall impact.

In the past 6 years ChaiScript's performance has been improved by nearly 100x. This was not accomplished by adding a virtual machine or performing dynamic recompilation. Instead, these increases have been accomplished by moving to more simple, cleaner, idiomatic C++ and by following some simple rules. We will outline these concepts with examples for how they both simplified code while improving performance.

Templates - and variadic templates - are an important aspect of writing a successful library in C++; libraries that can deal with custom types the user creates greatly eases their use. Variadic templates specifically are still a new, relatively unknown and at the same time quite a buggy (in the sense of bugs in their implementations) tool, but nevertheless, they offer much easier ways of creating truly generic types and functions.

This talk will focus slightly less on variadic templates in general; the common pitfalls will be discussed, but more attention will be given to the tool of parameter pack expansion and all the contexts where it can be used, especially as a code generation tool.

The talk will start mostly from scratch, assuming the audience's general knowledge about templates. It'll introduce the idea of variadic templates and general syntax and typical techniques for their use. Next, it will head into the (mostly) unknown and buggy lands of the interesting uses of variadic packs, like unpacking a tuple into a function call using `std::integer_sequence`, the use of empty packs for a slightly easier way to work with `enable_if`. The final examples will explain the way of invoking an expression per every argument in a pack, and dispatch to appropriate version of code for each of the argument types based on runtime values, which will be used to more easily create variant visitors.

I give a report on the progress we have made since last year on specification, standardization, implementation experience, deployment, and user experience with C++ modules. Looking forward, I will give a glimpse into the world of semantics-aware developer tools, including runtime reflection, made possible by C++ module implementation.

Lifetime safety means writing code that, by construction, is guaranteed to eliminate two things: (a) use of null/dangling pointers (including pointerlike things such as references, iterators, views, and ranges), and (b) leaks (including the rare 1% case where we’re tempted to admit the possibility of an ownership cycle or need to support lock-free concurrent data structures).

 

Last year, my CppCon 2015 talk “Writing Good C++14… By Default” focused on (a), null/dangling, because it's the more difficult and usually more serious problem. I gave an overview of a new approach of using static analysis rules to eliminate use of null and dangling in C++. That work continues and we’re in the process of writing down the formal rules for the approach that I showed last year.

 

This year, the focus will be on (b), leaks: The talk aims to begin with a set of simple rules, the “5-minute talk” to demonstrate that a handful of rules can be taught broadly to programmers of all levels, and results in code that is clean and free of leak bugs by construction.

 

But, since we’ll still have 85 minutes left, we can use the time to spelunk through a series of “Appendix” code examples, in which we'll demonstrate "why and how" to apply those rules to a series of increasingly complex/difficult situations, and that are aimed at increasingly advanced and “clever” (note: not always a good thing) programs and programmers. We’ll address questions such as: How should we represent Pimpl types? How should we represent trees – what should the child and parent pointer types be, and (when) should they be unique and when shared? How should we deal with “intra-module” or “encapsulated” cycles when you control all the objects in the cycle, such as all the nodes within a Graph? And what about “inter-module” or “compositional” cycles when you don’t know in advance about all the objects that could be in the cycle, such as when combining libraries written by different people in a way that may or may not respect proper layering (notoriously, using callbacks can violate layering)? The answers focus on cases where we have solid guidance, and then move toward some more experimental approaches for potentially addressing the ~1% of cases that aren’t yet well covered by unique_ptr, shared_ptr, and weak_ptr.

Want to meet your standard library maintainer? Now's your chance! Join us for a panel discussion of the C++ standard library with the people who implement it! C++ standard library maintainers and members of the C++ Committee's Library Working Group will talk about the philosophy behind the specification and implementation of the C++ standard library. We'll talk about all the new library features coming in C++17 (and beyond).