值语义与具有大数据结构的输出参数 [英] value semantics vs output params with large data structures

问题描述

2013主题演讲：Chandler Carruth：优化C ++的紧急结构

• 42:45
  
  您不需要输出参数，我们在C ++中有值语义。 ...任何时候你看到有人争辩说nonono我不会回报价值，因为副本会花费太多，一个工作在优化器的人说他们错了。好吧？我从来没有见过一段代码，其中的参数是正确的。 ...人们不了解价值语义对优化器的重要性，因为它完全澄清了混叠情况。

• 42:45
  You don't need output parameters, we have value semantics in C++. ... Anytime you see someone arguing that nonono I'm not going to return by value because copy would cost too much, someone working on an optimizer says they're wrong. All right? I have never yet seen a piece of code where that argument was correct. ... People don't realize how important value semantics are to the optimizer because it completely clarifies the aliasing scenarios.

任何人都可以在此答案的上下文中： http://stackoverflow.com/a/14229152

Can anyone put this in the context of this answer: http://stackoverflow.com/a/14229152

我听说重复，但是，对我来说，一个函数返回的东西是一个源。通过引用的输出参数将该特性从函数中移除，并且从函数中去除这种硬编码特性允许人们对外部进行管理，如何输出将被存储/重用。

I hear that being repeated on and on but, well, for me a function returning something is a source. Output parameters by reference take that characteristic out of a function, and removing such hard coded characteristic from a function allows one to manage outside instead, how output will be stored/reused.

我的问题是，即使在那个SO答案的上下文中，有一种方法来告诉，重构代码一些其他等效的方式，好了，现在看到，价值语义以这种方式不会失去对于输出参数版本，或Chandler评论具体针对一些设计的情况？ 我甚至看过Andrei Alexandrescu在演讲中辩论这一点，

My question is, even in the context of that SO answer, is there a way to tell, restructuring the code some other equivalent way, "ok now see, value semantics in this way doesn't lose for the output param version", or Chandler comments were specific to some contrived situations? I had even seen Andrei Alexandrescu arguing this in a talk and telling you can't escape using by ref output for better performance.

关于Andrei的意见，请参阅 Eric Niebler：Out Parameters，Move Semantics和Stateful Algorithms 。

For another take on Andrei's comments see Eric Niebler: Out Parameters, Move Semantics, and Stateful Algorithms.

推荐答案

这是一个夸大，泛化，一个笑话，或Chandler的完全合理的性能的想法（使用现代的C ++工具链/ libs）是不能接受我的程序。

It's either an overstatement, generalization, a joke, or Chandler's idea of "Perfectly Reasonable Performance" (using modern C++ toolchains/libs) is unacceptable to my programs.

我发现它的优化范围相当狭窄。由于程序中存在的实际复杂性和设计，不能忽略的惩罚超出了范围 - 堆分配是 getline 示例的一个例子。尽管您尝试减少它们，但是特定的优化可以或可以不总是适用于所讨论的程序。现实世界结构将引用可能出现别名的内存。你可以减少这种情况，但是相信你可以消除别名（从优化器的角度）是不现实的。

I find it a fairly narrow scope of optimizations. Penalties exist beyond that scope which cannot be ignored due to the actual complexities and designs found in programs - heap allocations were an example for the getline example. The specific optimizations may or may not always be applicable to the program in question, despite your attempts to reduce them. Real world structures will reference memory which may alias. You can reduce that, but it's not practical to believe that you can eliminate aliasing (from an optimizer's perspective).

当然，RBV可以是一个伟大的事情 - 不适合所有情况。即使你引用的链接指出了如何避免大量的分配/释放。

Of course, RBV can be a great thing - it's just not appropriate for all cases. Even the link you referenced pointed out how one can avoid a ton of allocations/frees. Real programs and the data structures found in them are far more complex.

在演讲中，他继续批评成员函数的使用（ref： S :: compute（））。当然，有一点要带走，但是是否真的合理地避免使用这些语言功能，完全是因为它使优化器的工作更容易？它会总是导致更多的可读程序？这些代码转换总是会导致可测量的更快的程序吗？不需要改变你的代码库所需的变化值得你投资的时间吗？有时。你可以拿走一些点，做出更明智的决定，影响你现有的或未来的代码库吗？是的。

Later in the talk, he goes on to criticize the use of member functions (ref: S::compute()). Sure, there is a point to take away, but is it really reasonable to avoid using these language features entirely because it makes the optimizer's job easier? No. Will it always result in more readable programs? No. Will these code transformations always result in measurably faster programs? No. Are the changes required to transform your codebase worth the time you invest? Sometimes. Can you take away some points and make better informed decisions which impact some of your existing or future codebase? Yes.

有时，它有助于细分您的程序执行的程度，或在C中的外观。

Sometimes it helps to break down how exactly your program would execute, or what it would look like in C.

优化器不会解决所有的性能问题，你不应该重写程序，假设你正在处理的程序是完全脑死亡和破碎的设计，也不应该相信使用RBV将总是导致完美合理性能。您可以利用新的语言功能，并使优化程序的工作更轻松，虽然有很多可以获得，通常有更重要的优化，投入你的时间。

The optimizer will not solve all performance problems, and you should not rewrite programs with the assumption that the programs you are dealing with are "completely brain dead and broken designs", nor should you believe that using RBV will always result in "Perfectly Reasonable Performance". You can utilize new language features and make the optimizer's job easier, though there is much to gain there are often more important optimizations to invest your time on.

建议的变更;理想情况下，在采用这些建议之前，您将衡量此类更改对实际执行时间的影响以及对源代码的影响。

It's fine to consider the proposed changes; ideally you would measure the impact of such changes in real world execution times and impact on your source code before adopting these suggestions.

对于您的示例：甚至复制+分配大型结构按价值可以有显着的成本。除了运行构造函数和析构函数（以及它们获取和拥有的资源的关联创建/清理，如你引用的链接中所指出的）之外，甚至像避免不必要的结构副本一样简单的事情可以节省大量的CPU如果使用引用（如果适用）的时间。结构副本可以像 memcpy 一样简单。这些都不是设计的问题;它们出现在实际的程序中，并且复杂性可以随着程序的复杂性而大大增加。减少某些内存的别名和其他优化值得的成本，并导致完全合理的性能？不总是。

For your example: Even copying+assigning large structures by value can have significant costs. Beyond the cost of running constructors and destructors (along with their associated creation/cleanup of the resources they acquire and own, as pointed out in the link you reference), even things as simple as avoiding unnecessary structure copies can save you a ton of CPU time if you use references (where appropriate). The structure copy may be as simple as a memcpy. These aren't contrived problems; they appear in actual programs and the complexity can increase greatly with your program's complexity. Is reducing aliasing of some memory and other optimizations worth the costs, and does it result in "Perfectly Reasonable Performance"? Not always.

这篇关于值语义与具有大数据结构的输出参数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！