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

แชร์
ฝัง
  • เผยแพร่เมื่อ 29 ก.ย. 2016
  • CppCon.org
    -
    Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/cppcon/cppcon2016
    -
    False.
    Compilers do optimize atomics, memory accesses around atomics, and utilize architecture-specific knowledge. My hobby is to encourage compilers to do more of this, programmers to rely on it, and hardware vendors to give us new atomic toys to optimize with. Oh, and standardize yet more close-to-the-metal concurrency and parallelism tools.
    But, you say, surely volatile always means volatile, there’s nothing wrong with my benign races, nothing could even go wrong with non-temporal accesses, and who needs 6 memory orderings anyways‽ I’m glad you asked, let me tell you about my hobby…
    -
    JF Bastien
    Jest-in-Time Compiler, template
    JF Bastien is a compiler engineer, currently focusing on performance and security to bring portable, fast and secure code to the Web. JF is a member of the C++ standards committee, where his mechanical engineering degree serves little purpose. He’s worked on startup incubators, business jets, flight simulators, CPUs, dynamic binary translation, systems, and compilers.
    -
    Videos Filmed & Edited by Bash Films: www.BashFilms.com
    *-----*
    Register Now For CppCon 2022: cppcon.org/registration/
    *-----*

ความคิดเห็น • 13

  • @Bourg
    @Bourg 7 ปีที่แล้ว +14

    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: th-cam.com/video/9hJkWwHDDxs/w-d-xo.html
    As well as Hans' talk: th-cam.com/video/M15UKpNlpeM/w-d-xo.html

  • @hanneshauptmann
    @hanneshauptmann 7 ปีที่แล้ว +11

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

    • @Bourg
      @Bourg 7 ปีที่แล้ว +12

      The reports of my caffeination are greatly exaggerated.

  • @johnwoolverton1570
    @johnwoolverton1570 7 ปีที่แล้ว

    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
      @Bourg 7 ปีที่แล้ว

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

  • @andreicheremukhin8869
    @andreicheremukhin8869 7 ปีที่แล้ว

    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
      @Bourg 7 ปีที่แล้ว +4

      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.

  • @Fetrovsky
    @Fetrovsky 7 ปีที่แล้ว

    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
      @ZeceDeZero 7 ปีที่แล้ว +1

      or use intrinsics

    • @Bourg
      @Bourg 7 ปีที่แล้ว +3

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

  • @PopescuAlexandruCristian
    @PopescuAlexandruCristian 7 ปีที่แล้ว +1

    -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
      @Bourg 7 ปีที่แล้ว +16

      ⚫ "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
      @PopescuAlexandruCristian 7 ปีที่แล้ว

      -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.