哪个演员更快 static_cast<int> () 或 int()

Posted 2023-02-17

【中文标题】哪个演员更快 static_cast<int> () 或 int()

【英文标题】：which cast is faster static_cast<int> () or int()

【发布时间】：2009-10-22 17:28:05

【问题描述】：

尝试查看哪个转换更快（不一定更好）：新的 c++ 案例或老式的 C 样式转换。有什么想法吗？

【问题讨论】：

你总是可以写一个基准脚本。只需进行 1000 万次 static_cast 和 1000 万次 int 转换，看看哪个需要更长的时间。我的猜测是它们会编译成相同的汇编指令。

忽略他们几乎可以肯定在所有编译器上编译相同的事实，为什么这很重要？除非你知道性能问题，否则你写得要清楚，避免难以阅读的微优化，这些微优化无论如何都可能毫无意义。使用 static_cast().

C 风格转换是根据 C++ 风格转换定义的（C 风格转换可以转换为私有基...）。所以它们实际上是相当的。没有人比另一个人的性能提升。

对于它的价值，int(10.4) 不是 C 风格的强制转换，因为那不是有效的 C（它使用参数调用函数 int()）。 “C 风格”演员是(int)10.4。

@Chris：是的，但函数样式转换完全等同于与 C 样式转换。

【参考方案1】：

如果您将int() 与static_cast<int>() 的等效 功能进行比较，应该完全没有区别。

使用VC2008：

    double d = 10.5;
013A13EE  fld         qword ptr [__real@4025000000000000 (13A5840h)] 
013A13F4  fstp        qword ptr [d] 
    int x = int(d);
013A13F7  fld         qword ptr [d] 
013A13FA  call        @ILT+215(__ftol2_sse) (13A10DCh) 
013A13FF  mov         dword ptr [x],eax 
    int y = static_cast<int>(d);
013A1402  fld         qword ptr [d] 
013A1405  call        @ILT+215(__ftol2_sse) (13A10DCh) 
013A140A  mov         dword ptr [y],eax 

显然，100% 相同！

【讨论】：

这在我看来并不性感 :) 一个性感的人会使用 SSE 指令而不涉及 FPU :) （我认为 SSE 在 VC 中已经默认使用）。

@AndreyT 确实如此:) 答案中的代码是在调试模式下生成的。如果您尝试使用优化编译它，它确实使用 SSE 指令。

-1（如果可以的话）。不是很明显。你的回答证明只有在特定版本的VS2008中是一样的。

是否依赖于平台？不同的编译器可能会以不同的方式处理这两种类型的转换吗？

【参考方案2】：

没什么区别。

对于单一类型转换这样的基本构造，一旦两个构造具有相同的语义含义，它们的性能就会完全一样，并且为这些构造生成的机器码也将是相同的。

【参考方案3】：

我相信实际结果是由实现定义的。您应该在您的编译器版本中检查它。但我相信它会在大多数现代编译器中给出相同的结果。在 C++ 中，您不应该使用 C-cast，而是使用 C++ casts - 它可以让您在编译时发现错误。

【讨论】：

性能问题不是由实现定义的（事实上，该标准根本不要求任何性能，除了用于容器操作的 big-O）

【参考方案4】：

查看使用每种方法的程序集。如果不同，请使用分析器。

【参考方案5】：

它们是相同的，因为它是在编译时解决的，并且没有运行时开销。即使有一些差异，我也不会为这些微小的（甚至不是微的）优化操心太多。

【参考方案6】：

正如大多数人所说，人们希望这些速度应该相同，尽管您受编译器的摆布......这并不总是一个非常愉快的情况。继续阅读战争故事。

根据您的编译器和程序以float f; int i(f);、float f; int i = (int)f; 和float f; int i = static_cast<int>(f); 及其同类（包括涉及双精度、长整型和无符号类型的变体）的速度执行的处理器内核的特定型号，可能会非常糟糕慢 - 比您预期的要差一个数量级。编译器可能会发出改变内部处理器模式的指令，从而导致指令流水线被丢弃。这实际上是编译器优化元素中的一个错误。我已经看到有人遭受this analysis 中提到的排序 40 时钟周期成本的情况，此时您遇到了一个重大的、意想不到的和令人恼火的性能瓶颈，因为 AFAIK 没有完全令人愉悦、强大、通用的解决方案。有一些涉及汇编程序的替代方案，但 AFAIK 它们不会像强制转换那样将浮点数舍入为整数。如果有人知道更好，我很感兴趣。我希望这个问题是/将很快局限于遗留编译器/硬件，但你需要你的智慧。

附：我无法访问该链接，因为我的防火墙将其作为与游戏相关的内容加以阻止，但 a Google cache of it 足以证明其作者比我更了解它。

【参考方案7】：

当您的选择对代码影响不大时，我会选择对后来的程序员来说更熟悉的那个。让代码更容易被他人理解总是值得考虑的。在这种情况下，出于这个原因，我会坚持使用int(…)。

【讨论】：

为什么你会认为 int(...) 会更熟悉呢？它实际上似乎在 C 中无效，可能是 C++ 的“伪构造函数”调用。 - 另外，由于没有明确说明演员表的类型，为什么要让代码更容易理解？

演员阵容没有什么可玩的，因此应该很容易被发现。这就是 C++ 风格的强制转换。