3 ms·

It seems that the main issue that the authors of this proposal have with the current coroutines proposal in the committee is that that proposal effectively requ

It seems that the main issue that the authors of this proposal have with the current coroutines proposal in the committee is that that proposal effectively requires allocation for all coroutines, while offering promises that the optimizer will be able to avoid the allocation in common cases. This competing proposal makes allocation opt-in for various reasons, not the least of which is skepticism about how well the optimization will perform. (See "Implicit allocation violates the zero-overhead principle" in this document [1]). [1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0973r0.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p097...

RcouF1uZ4gsC 8y ago
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0981r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p098... The people that actually implement coroutines in the compilers actually think that eliding the allocation is very doable.
- pcwalton 8y ago
  Richard Smith, quoted in the document I linked as saying "I do not have any confidence this optimization would ever become reliable in the way that, say, certain forms of NRVO are," is the code owner of the clang frontend.
  - simias 8y ago
    It's also true that relying on the compiler to optimize some stuff away (instead of making the overhead explicitly opt-in) is not very C++-ish in nature.
    - Chabs 8y ago
      I'd like to introduce you to the wonderful world of templates.
      - bergesenha 8y ago
        Do you have any examples of templates incurring a runtime cost at -O0 compared to a “no templates” approach?
        deleted 8y ago
        [deleted]
        Chabs 8y ago
        Expression templates (ala boost::spirit) definitely come to mind. The callstack in a -O0 build can get very, very deep. Heck just using std::numeric_limits<int>::min() will incur a function call in -O0, but nobody cares since it gets optimized in -O1 and up. The same thing applies more and more as you invoke templates from templates, but, again, nobody cares since we are confident it'll get optimized/inlined easily. It's not nearly as prevalent in modern code since constexpr static variables are now a thing, but relying on these optimizations has historically been super important.
      - simias 8y ago
        But that's the thing, you have complete control over templates, there's no compiler magic involved. If you're unhappy with the way a template call sequence gets optimized you can tweak it completely. In your comment below you mention boost but that's kind of my point: boost is a completely optional third party library, not a built-in construct of the language like the coroutines discussed here. Boost might be relying on the compiler correctly optimizing some constructs but the C++ template mechanics themselves not so much.
    - TheCoelacanth 8y ago
      I would say the opposite, actually. Idiomatic C++ relies heavily on the compiler to optimize away copies, inline functions and objects, optimize away vtable lookups, etc.
      - simias 8y ago
        I mean yeah, at a very basic level you always expect the compiler to do the most obvious optimizations but the same could be said about C or any language that's higher level than assembly. It's not that you shouldn't expect the compiler to optimize your code, it's that you shouldn't be expected to write code in a sub-optimal way only to hope that the compiler will have your back. You can choose to use classes and inheritance without using virtual calls, which means that you won't have to use vtables at all, compiler or not. You can rely on the compiler to optimize return values but you can also use a return parameter and not rely on that at all. I'm not saying that it's a bad thing to do it any other way but I maintain that saying "just make things easy and let the compiler sort it out" is very much not how C++ has been designed so far, for better or worse.
- DannyBee 8y ago
  This is definitely wrong :) Besides Richard, who is the code owner of the clang frontend , chandler is the #5 contributor to LLVM (see here https://github.com/llvm-mirror/llvm/graphs/contributors https://github.com/llvm-mirror/llvm/graphs/contributors), and a quick trip to llvm-dev will tell you how much time he spends working on optimizations :) FWIW: The GCC folks i pinged were similarly unenamored with the idea of trying to elide allocation all the time. Personally, i've seen a bunch of these "required optimizations" over the years, and they rarely pan out without significant help. (IE required tail call optimization usually requires special marking/calling convention change, etc). Full disclosure: Chandler, Geoff, and Richard are in my org, and i am theoretically their boss's boss. I say theoretically because it's pretty meaningless - i'm not going to tell Richard how to do C++.
AndyKelley 8y ago
This is the main issue that zig has with LLVM's coroutines implementation, as well as: * buggy - we currently have to disable all optimizations in coroutine functions because mem2reg reverts correct coroutine frame spills back to invalid parameter references * compilation speed - llvm's coroutine splitting code is extraordinarily slow. I had a chat with Eddy B about how coroutines work in rust, and I think it's a much better approach. Rust does its own splitting in the frontend, and avoids LLVM coroutines in the IR. But yeah, non-guaranteed memory allocation elision is just not going to cut it. Especially if we need guaranteed memory allocation elision in debug builds where we don't have time to run any optimizers.

RcouF1uZ4gsC 8y ago

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0981r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p098... The people that actually implement coroutines in the compilers actually think that eliding the allocation is very doable.

pcwalton 8y ago
Richard Smith, quoted in the document I linked as saying "I do not have any confidence this optimization would ever become reliable in the way that, say, certain forms of NRVO are," is the code owner of the clang frontend.
- simias 8y ago
  It's also true that relying on the compiler to optimize some stuff away (instead of making the overhead explicitly opt-in) is not very C++-ish in nature.
  - Chabs 8y ago
    I'd like to introduce you to the wonderful world of templates.
    - bergesenha 8y ago
      Do you have any examples of templates incurring a runtime cost at -O0 compared to a “no templates” approach?
      - deleted 8y ago
        [deleted]
      - Chabs 8y ago
        Expression templates (ala boost::spirit) definitely come to mind. The callstack in a -O0 build can get very, very deep. Heck just using std::numeric_limits<int>::min() will incur a function call in -O0, but nobody cares since it gets optimized in -O1 and up. The same thing applies more and more as you invoke templates from templates, but, again, nobody cares since we are confident it'll get optimized/inlined easily. It's not nearly as prevalent in modern code since constexpr static variables are now a thing, but relying on these optimizations has historically been super important.
    - simias 8y ago
      But that's the thing, you have complete control over templates, there's no compiler magic involved. If you're unhappy with the way a template call sequence gets optimized you can tweak it completely. In your comment below you mention boost but that's kind of my point: boost is a completely optional third party library, not a built-in construct of the language like the coroutines discussed here. Boost might be relying on the compiler correctly optimizing some constructs but the C++ template mechanics themselves not so much.
  - TheCoelacanth 8y ago
    I would say the opposite, actually. Idiomatic C++ relies heavily on the compiler to optimize away copies, inline functions and objects, optimize away vtable lookups, etc.
    - simias 8y ago
      I mean yeah, at a very basic level you always expect the compiler to do the most obvious optimizations but the same could be said about C or any language that's higher level than assembly. It's not that you shouldn't expect the compiler to optimize your code, it's that you shouldn't be expected to write code in a sub-optimal way only to hope that the compiler will have your back. You can choose to use classes and inheritance without using virtual calls, which means that you won't have to use vtables at all, compiler or not. You can rely on the compiler to optimize return values but you can also use a return parameter and not rely on that at all. I'm not saying that it's a bad thing to do it any other way but I maintain that saying "just make things easy and let the compiler sort it out" is very much not how C++ has been designed so far, for better or worse.
DannyBee 8y ago
This is definitely wrong :) Besides Richard, who is the code owner of the clang frontend , chandler is the #5 contributor to LLVM (see here https://github.com/llvm-mirror/llvm/graphs/contributors https://github.com/llvm-mirror/llvm/graphs/contributors), and a quick trip to llvm-dev will tell you how much time he spends working on optimizations :) FWIW: The GCC folks i pinged were similarly unenamored with the idea of trying to elide allocation all the time. Personally, i've seen a bunch of these "required optimizations" over the years, and they rarely pan out without significant help. (IE required tail call optimization usually requires special marking/calling convention change, etc). Full disclosure: Chandler, Geoff, and Richard are in my org, and i am theoretically their boss's boss. I say theoretically because it's pretty meaningless - i'm not going to tell Richard how to do C++.

AndyKelley 8y ago

This is the main issue that zig has with LLVM's coroutines implementation, as well as: * buggy - we currently have to disable all optimizations in coroutine functions because mem2reg reverts correct coroutine frame spills back to invalid parameter references * compilation speed - llvm's coroutine splitting code is extraordinarily slow. I had a chat with Eddy B about how coroutines work in rust, and I think it's a much better approach. Rust does its own splitting in the frontend, and avoids LLVM coroutines in the IR. But yeah, non-guaranteed memory allocation elision is just not going to cut it. Especially if we need guaranteed memory allocation elision in debug builds where we don't have time to run any optimizers.