CppCon 2016: JF Bastien “No Sane Compiler Would Optimize Atomics"

[@Bourg]

My references and slides are here: github.com/jfbastien/no-sane-compiler I had a think-o in my slides: "want a release store (there is no release store)" should have been "release load". At the beginning I refer to Fedor's talk: kzbin.info/www/bejne/b5mtnIqtfal3rtU As well as Hans' talk: kzbin.info/www/bejne/g2KYhn6mg9Gjm68

[@hanneshauptmann]

Finally a motivated and easy to understand man who can talk nice and interesting. He drank enough coffee ! :D

[@Bourg]

The reports of my caffeination are greatly exaggerated.

[@andreicheremukhin8869]

You are saying that 'this a horrible example, don't write this code...' at the slide 'Simple Usage' 11:00, but it seems you don't give any explanation why. Did I miss something?

[@Bourg]

The spinloop is very naive. There are cases where it's a good idea to use such a spinloop, but you're probably better off with std::condition_variable until you measure performance. Fedor's talk had more information on benchmarking such code, and explains some of the tradeoffs.

[@johnwoolverton1570]

I'm guessing the two other atomic talks he refers to in the beginning are, The Speed of Concurrency: Is Lock-Free Faster?, Fedor Pikus and Using Weakly Ordered Atomics Correctly. by Hans Boehm but neither have been posted yet so we'll just have to wait and see.

[@Bourg]

Correct. I'll update with links once they are.

[@Fetrovsky]

If I'm in AMD64 and I want to read the contents of CR3, or store a new value in CR2, I may neeed to drop an assemby line.

[@ZeceDeZero]

or use intrinsics

[@Bourg]

Agreed: you're entirely in implementation-defined land where atomics aren't the right tool.

[@PopescuAlexandruCristian]

-Regarding your need to optimize atomic operations, no company that uses C++ as a language cares about the C++ memory model, we don't have that many target platforms(ARM and AMD64, the rest are in maintenance or dead) we care about performance and we can get performance because we have domain specific knowledge, we know what to ignore and get viable results, don't break code for 3% on some benchmark with no real world value. -All real software out there has at least some inline assembly in it because we can get better performance then the compiler, we have domain/problem specific knowledge, we don't care about correct results in all situations, we care about correct results for our data. -No real software is 100% without undefined/unspecified behavior. -We will send a bug report if we find something that bother us, but we need to ship code today, actually we have the same relation with you people that you have with the hardware guys, we get a response in 5-10 months.

[@Bourg]

⚫ "no company that uses C++ as a language cares about the C++ memory model" I've worked at two large companies that do. Your experience evidently varies, but "no company" is an overstatement. ⚫ "we don't have that many target platforms" when I worked on Chrome, the V8 engine supported 9 target architectures. ⚫ "we can get performance because we have domain specific knowledge" so does the compiler, and it often has more than most programmers do. Good on you if you know better. ⚫ "don't break code for 3% on some benchmark with no real world value" have you watched the talk? I address that specific claim (spoiler: I agree). ⚫ "All real software out there has at least some inline assembly in it because [...]" I disagree. Some programs do, sometimes for good reasons and sometimes for bad reasons (I mention a few in my talk). Using assembly or C++ doesn't make you software more "real" than, say, pure JavaScript programs. ⚫ "No real software is 100% without undefined/unspecified behavior" sure. What's your point? ⚫ "we get a response in 5-10 months" not my experience, sorry yours differs. Try again?

[@PopescuAlexandruCristian]

-By "no company that uses C++ as a language cares about the C++ memory model" I meant to say that most projects have a specific target, people don't target abstract platforms, it may be undefined/unspecified behavior in the c++ model but if it works on the target platform and it's faster it's fair game. -Regarding the third point, in your talk you said you wan't break code with defined behavior on the c++ model, that's the problem, you shouldn't break any code that is defined for the given platform. -By real code has inline assembly, I meant code made with c++ in commercial software, and I didn't meant it as a marker for "code greatness" but as a sad reality. -You said that while you worked on Chrome V8 you had 9 targets, well most companies don't have that, I do believe that you situation is an exception. Also I assume that effort was not equally distributed for all those platforms.