Skip to content
0:00 / 0:00

#atomics#memorymodel#volatile

C++ and Beyond 2012: Herb Sutter - atomic Weapons 2 of 2

alexsmail

7.9K subscribers • 3 videos on Hallway

YouTube
  • Recommended by 2 people: 2 on Hacker News.
  • Presented by Herb Sutter, C++ committee chair

Advanced. Deep dive for people who know the field.

29K views8 years ago2 recommendations

Systems programmingProgramming languagesC++Concurrency and parallelismMemory management

Herb Sutter delivers a deep dive into the C++11 memory model, atomics, memory ordering, and the modern meaning of volatile.

channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyond-2012-Herb-… Download the slides. 1drv.ms/b/s!Aq0V7yDPsIZOgcI0y2P8R-VifbnTtw Abstract: This session in one word: Deep. It's a session that includes topics I've publicly said for years is Stuff You Shouldn't Need To Know and I Just Won't Teach, but it's becoming achingly clear that people do need to know about it. Achingly, heartbreakingly clear, because some hardware incents you to pull out the big guns to achieve top performance, and C++ programmers just are so addicted to full performance that they'll reach for the big red levers with the flashing warning lights. Since we can't keep people from pulling the big red levers, we'd better document the A to Z of what the levers actually do, so that people don't SCRAM unless they really, really, really meant to. Topics Covered: * The facts: The C++11 memory model and what it requires you to do to make sure your code is correct and stays correct. We'll include clear answers to several FAQs: "how do the compiler and hardware cooperate to remember how to respect these rules?", "what is a race condition?", and the ageless one-hand-clapping question "how is a race condition like a debugger?" * The tools: The deep interrelationships and fundamental tradeoffs among mutexes, atomics, and fences/barriers. I'll try to convince you why standalone memory barriers are bad, and why barriers should always be associated with a specific load or store. * The unspeakables: I'll grudgingly and reluctantly talk about the Thing I Said I'd Never Teach That Programmers Should Never Need To Now: relaxed atomics. Don't use them! If you can avoid it. But here's what you need to know, even though it would be nice if you didn't need to know it. * The rapidly-changing hardware reality: How locks and atomics map to hardware instructions on ARM and x86/x64, and throw in POWER and Itanium for good measure – and I'll cover how and why the answers are actually different last year and this year, and how they will likely be different again a few years from now. We'll cover how the latest CPU and GPU hardware memory models are rapidly evolving, and how this directly affects C++ programmers. For more information see alexsmail.blogspot.com/2017/11/c-and-beyond-2012-herb-sutter…

Why it's here

2 people recommend this

What people say. Highly recommended as one of the best and most thorough explanations of low-level concurrency, atomics, and memory barriers.

NobodyNadaon Hacker News • Recommends

On “C++ Memory Model: Migrating from x86 to ARM”

For a more in depth introduction to the topic with a lot of practical code examples, I highly recommend Herb Sutter’s excellent talk: Part 1 link Part 2 link to this video

chc4on Hacker News • Recommends

On “Rust Atomics and Locks (2023)”

"Is Parallel Programming Hard, And, If So, What Can You Do About It?" is one of the best books about atomics and concurrency, and my #2 recommendation. link My #1 actually isn't a book at all, but the two "atomic Weapons" talks by Herb Sutter, which are extremely good. link link to this video

u/Nervous_Recursionin r/C_Programming • Mentions

On “Where can one learn about Std threads, Atomic operations, lock free / wait free programming as well as distributed parallel programming where each core has its own memory space that is total mem / total core in C?”

The C11 memory model is essentially the same as the C++11 one, so if you are starting from scratch, learn why it was designed that way and the principles behind, it is equally valid for C. The following talk from Herb Sutter is very good: * link to this video * link to this video It's not so much about each language implementation themselves (he only cites the memory models of Java, C++ and C and some subtle differences), but explains why you need to care about defining this memory model in the first place in the context of concurrency. It was delivered at a C++ con but don't let it stop you, it's a good material to get into this subject IMO.

oconnor663on Hacker News • Mentions

On “Ways to break your systems code using volatile (2010)”

Herb Sutter's (three hour long!) Atomic Weapons talk goes over the modern meaning of volatile towards the end: link to this video

NobodyNadaon Hacker News • Mentions

On “Ask HN: What does one look for in a laptop these days?”

…o spend 10 years and billions of dollars to make a high-performance non-x86 chip.) Some examples: - x86 guarantees strong memory ordering on multi-processor systems, which adds completely unnecessary overhead to every memory access. arm64 uses a weak memory model instead, providing atomic instructions with relaxed or acquire/release semantics (see link to this video for a more detailed discussion). This significantly improves performance all around the board, but especially with reference counting operations (which are extremely common and often a bottleneck in code written in ObjC/Swift): link > fun fact: retaining and releasing an NSObject takes ~30 nanoseconds on current gen Intel, and ~6.5 nanose…

cowtoolson Hacker News • Mentions

On “Ask HN: Can competitors catch up to Apple Silicon?”

I would imagine that any implementation of x86 would have to bear the weight of reverse-compatibility. With reverse comparability, the bad design decisions just compound, for example complicated stuff like memory synchronization link to this video

mlindneron Hacker News • Mentions

On “Rust Atomics and Locks: Low-Level Concurrency in Practice”

…ns are exactly as cheap as acquire and release operations. Or, rather, that ARM64 Acquire, Release, and AcqRel operations are as expensive as SeqCst. Unlike x86-64, however, Relaxed operations are relatively cheap, as they don’t result in stronger ordering guarantees than necessary. However in Herb Sutter's talk (specifically the second half here: link to this video ) he says that ARMv8 Acquire/Release/AcqRel operations are cheaper than SeqCst. This book seems to claim that x64 is somehow superior to ARMv8, which from my understanding is completely wrong.…