Fedor G. Pikus is a Technical Fellow and the Director of the Advanced Projects Team at Siemens Digital Industries Software. His responsibilities include planning the long-term technical direction of Calibre products, directing and training the engineering teams, overseeing the design and architecture of the software, and researching new design and software technologies.
His earlier positions included Chief Scientist at Mentor Graphics (acquired by Siemens Software), Senior Software Engineer at Google, and Chief Software Architect for Calibre PERC, LVS, and DFM. He joined Mentor Graphics in 1998, making the switch from academic research in computational physics to the software industry.
Fedor is a recognized expert in high-performance computing and C++. He is an O'Reilly author and has written three books on C++ and software design. He is a regular instructor at the CppCon Academy, leading two of the best-attended classes, and has presented his work at CppNow, CppCon, CppNorth, SD West, DesignCon, and in various software development journals. Fedor holds over 30 patents and has authored over 100 papers and conference presentations on physics, EDA, software design, and the C++ language.
Before you can break the rules, you have to know them. The C++ Standard gives us a beautiful, mathematically rigorous model of concurrency. We are taught that data races are undefined behavior, that atomic operations are indivisible, and that memory barriers stop the compiler and CPU from making a mockery of our logic. We are taught the hierarchy of progress guarantees—how lock-free and wait-free algorithms banish deadlocks, priority inversion, and convoying. By the textbook, lock-free is the obvious tool for high-performance concurrent code. This morning's talk is the textbook. This afternoon's talk—"Lock-free programming is dead. Long live lock-free programming!"—is what […]
For decades, lock-free programming has been the go-to optimization for the most contended parts of concurrent programs. The reasoning was simple: locks are slow under contention, so eliminate the locks. This made sense on the hardware of the time, and I should know—I've given several talks explaining how and why to do it. The hardware has changed. Modern CPUs are very, very good at locks. Specifically, they are highly optimized for the operations that make locks fast: cache line transfers, memory ordering, and speculative execution through lock acquisitions. So good, in fact, that the old advice requires a serious reckoning. […]
This talk dives into how the latest CPU advancements from Intel and AMD impact performance and code optimization. While not C++-specific, these changes are often more relevant for the C++ programmers who, in high-performance systems, often take direct control of memory management and utilization of computational resources. As processors evolve with more cores and complex features, understanding these changes is crucial for writing high-performance C++. We'll cover why optimizations that worked well on older hardware might not be as effective on new CPUs and how to adjust your C++ code to take full advantage of the latest processor features. We'll […]
This talk is about type erasure in C++ (I have to be specific because the term has a completely different meaning in other languages). The aim of this talk is to explain how type erasure works, and do it in a very simple and clear way. Type erasure is probably the closest C++ comes to “and then magic happens.” It’s a technique used to write a program (in a strictly typed language, no less) that doesn’t mention the types it works with. It is the pinnacle of abstraction in C++, and, like most abstractions, it’s much easier to show what […]
The Non-Uniform Memory Architecture (NUMA) systems are common in enterprise computing today: almost all high-end large-memory systems are NUMA machines, and even the most common mid-range servers (32 to 40 cores, under 500G of memory) are usually NUMA systems. For something so widely used, one would expect NUMA and its impact on program performance to be well understood. Sadly, it’s not. NUMA systems present a Non-Universal Menagerie of Attributes and their behavior is devilishly complex. Practical consequences range from “ignore the fact that it’s NUMA and you’re fine” to “the program runs much faster on 16 CPUs than on 32.” […]