什么时候不应该使用[[carries_dependency]]? [英] When should you not use [[carries_dependency]]?
问题描述
我发现了一些问题(例如这)，询问了[[carries_dependency]]的作用，而那不是我要问的问题在这里.
我想知道什么时候不应该使用它，因为我已经阅读了所有答案，这听起来像是您可以在各处粘贴此代码，并且神奇地得到相等或更快的代码.一条评论说代码可以相等或更慢，但是张贴者没有详细说明.
我想在任何函数返回值或参数(作为指针或引用，并且将在调用线程内传递或返回)上使用此函数的适当位置，并且不应在回调或线程入口点上使用它. /p>
有人可以评论我的理解并大致上说明何时，何时不使用它吗?
我知道有此如果有其他读者感兴趣，请就该主题进行讨论；它可能包含我的答案，但我还没有机会通读它.
因为我已阅读所有答案，听起来像可以抹灰 此代码无处不在，而且您会神奇地得到相等或更快的代码
获得更快的代码的唯一方法是当该注释允许省略围栏时.
因此它可能可能有用的唯一情况是:
- 您的程序在重要的频繁执行的代码中对原子加载操作使用消耗排序；
- 消费价值"不仅可以立即在本地使用，还可以传递给其他功能；
- 目标CPU为使用操作提供了特定的保证(与该操作之前的给定篱笆一样强大，仅用于该操作)；
- 编译器作者认真对待他们的工作:他们设法将消耗某种语言的高级语言转换为消耗CPU的水平，以便从CPU保证中受益.
这是可能获得可测量的更快代码的一堆必要条件.
(C ++社区的最新趋势是放弃发明一种在所有情况下都是安全的适当的编译方案，并为用户提供一种完全不同的方式来指示编译器生成使用"值的代码，具有更清晰，天真可转换的C ++代码.)
有评论说代码可以相等或更慢，但是张贴者 没有详细说明.
当然，您可以随意地将它们放在程序上的那种注释通常不能使代码更有效！那太容易了，而且也自相矛盾.
任一某些注释在您的代码上指定了一个约束，这是对编译器的承诺，并且您不能将其放置在任何与之不符的地方.保证代码中的代码(例如C ++中的noexcept，C中的restrict)，否则将以各种方式破坏代码(noexcept函数中的异常会停止程序，受限制的指针的别名会导致有趣的错误编译和错误的结果行为(以前没有定义行为)；然后编译器可以使用它以特定方式优化代码.
或者，该注释不会以任何方式限制代码，并且编译器无法依靠任何东西，并且注释不会再产生更多的优化机会.
如果您在某些情况下获得了更高效的代码，而又没有用注释破坏程序的代价，那么在其他情况下，您就可能必须获得效率更低的代码.通常，这是正确的，对于consume语义尤其如此. ，这将先前描述的内容限制在C ++构造的翻译中.
我想在任何函数返回或 参数，该参数是指针或引用，将被传递或 在调用线程中返回
不，唯一有用的情况是 ，当预期的调用函数可能使用消耗内存的顺序时.
I've found questions (like this one) asking what [[carries_dependency]] does, and that's not what I'm asking here.
I want to know when you shouldn't use it, because the answers I've read all make it sound like you can plaster this code everywhere and magically you'd get equal or faster code. One comment said the code can be equal or slower, but the poster didn't elaborate.
I imagine appropriate places to use this is on any function return or parameter that is a pointer or reference and that will be passed or returned within the calling thread, and it shouldn't be used on callbacks or thread entry points.
Can someone comment on my understanding and elaborate on the subject in general, of when and when not to use it?
EDIT: I know there's this tome on the subject, should any other reader be interested; it may contain my answer, but I haven't had the chance to read through it yet.
because the answers I've read all make it sound like you can plaster this code everywhere and magically you'd get equal or faster code
The only way you can get faster code is when that annotation allows the omission of a fence.
So the only case where it could possibly be useful is:
- your program uses consume ordering on an atomic load operation, in an important frequently executed code;
- the "consume value" isn't just used immediately and locally, but also passed to other functions;
- the target CPU gives specific guarantees for consuming operations (as strong as a given fence before that operation, just for that operation);
- the compiler writers take their job seriously: they manage to translate high level language consuming of a value to CPU level consuming, to get the benefit from CPU guarantees.
That's a bunch of necessary conditions to possibly get measurably faster code.
(And the latest trend in the C++ community is to give up inventing a proper compiling scheme that's safe in all cases and to come up with a completely different way for the user to instruct the compiler to produce code that "consumes" values, with much more explicit, naively translatable, C++ code.)
One comment said the code can be equal or slower, but the poster didn't elaborate.
Of course annotations of the kind that you can randomly put on programs simply cannot make code more efficient in general! That would be too easy and also self contradictory.
Either some annotation specifies a constrain on your code, that is a promise to the compiler, and you can't put it anywhere where it doesn't correspond an guarantee in the code (like noexcept in C++, restrict in C), or it would break code in various ways (an exception in a noexcept function stops the program, aliasing of restricted pointers can cause funny miscompilation and bad behavior (formerly the behavior is not defined in that case); then the compiler can use it to optimize the code in specific ways.
Or that annotation doesn't constrain the code in any way, and the compiler can't count on anything and the annotation does not create any more optimization opportunity.
If you get more efficient code in some cases at no cost of breaking program with an annotation then you must potentially get less efficient code in other cases. That's true in general and specifically true with consume semantic, which imposes the previously described constrained on translation of C++ constructs.
I imagine appropriate places to use this is on any function return or parameter that is a pointer or reference and that will be passed or returned within the calling thread
No, the one and only case where it might be useful is when the intended calling function will probably use consume memory order.
这篇关于什么时候不应该使用[[carries_dependency]]?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
