Visual Studio 2017 VC++ 平台工具集 v141 比 v100 慢，为什么？答案

【问题标题】：Visual Studio 2017 VC++ platform toolset v141 slower than v100, why?Visual Studio 2017 VC++ 平台工具集 v141 比 v100 慢，为什么？
【发布时间】：2018-09-26 18:13:23
【问题描述】：

我正在重写一些 S3TC 算法，并且在分析我正在测试的优化时，我使用的是 vs2010。在我写完代码后，决定在平台工具集 v141 上对其进行分析。将单独的解决方案和项目文件克隆为原始的克隆，并将解决方案加载到 vs2017 中。将分析项目重新定位到平台工具集 v141、Windows SDK 10，清理并重建所有内容，做了几次......

分析是由于 Release 版本的性能下降而导致的，而 Debug 版本的值与 vs2010 调试非常相似。 Release 版本的实测下降约为 11% 并保持不变。检查项目属性中的优化。一切都与vs2010完全相同。之后，我重新定位到平台工具集 v100，离开 Windows SDK 10 并重新构建所有内容。分析结果与 vs2010 分析结果相同。回到 v141，性能下降了约 11%。这告诉我，与 v100 平台工具集相比，平台工具集 v141 的 c/c++ 编译器效率较低。

有没有人遇到过这种情况，并发现了新一代编译器出现这种行为的原因？

是否对两者的代码进行了预处理和比较，并找出 v141 缺少什么？

这是 MS 编译器团队中优秀编码人员的垮台，还是我在这里遗漏了什么？

【问题讨论】：

我听说 Microsoft 在其 C++ 库中添加了针对 Spectre 等推测执行漏洞的缓解措施。这些可能会影响性能。
您使用什么进行分析 - 是用于 VS10 exe 的 VS10 分析器和用于 VS17 exe 的 VS17 分析器还是独立的分析器
当然是独立的分析器，否则如何正确测量它；）它涉及大量测试> 1 百万，输出或结果平均标准。结果中的偏差以及最小和最大偏差。

标签： c visual-studio optimization compiler-optimization

【解决方案1】：

针对 CPU 中的推测执行的漏洞利用最近出现在新闻中，著名的例子是 Spectre 和 Meltdown。

解决这些问题的一种方法是在编译器中

Understanding the performance impact of Spectre and Meltdown mitigations on Windows Systems

“以下是 [Microsoft] 迄今为止发现的摘要：

•Windows 10 在较新的芯片上（配备 Skylake、Kabylake 或更新 CPU 的 2016 年代 PC）上，基准测试显示出个位数的减速，但我们预计大多数用户不会注意到变化，因为这些百分比以毫秒为单位反映.

•Windows 10 在较旧的芯片上（2015 年代的具有 Haswell 或更旧 CPU 的 PC）上，一些基准测试显示更明显的减速，我们预计一些用户会注意到系统性能下降。

•如果 Windows 8 和 Windows 7 安装在较旧的芯片上（2015 年配备 Haswell 或更旧 CPU 的 PC），我们预计大多数用户会注意到系统性能下降。

•启用缓解措施以隔离 Windows Server 实例中不受信任的代码时，任何芯片上的 Windows Server（尤其是在任何 IO 密集型应用程序中）都会显示出更显着的性能影响。这就是为什么您要谨慎评估每个 Windows Server 实例的不受信任代码的风险，并在您的环境中平衡安全性与性能之间的权衡。”

因此，使用包含这些缓解措施的编译器重新编译的程序很可能会受到较小的性能影响。

【讨论】：

基准测试在同一台 PC 上执行，如果硅微码是原因，则在两个测试中应该是相同的。你不同意吗？否则我不明白这一点，因为被攻击者可以简单地提供受影响的 vc 库以及他的攻击程序，并绕过上面的补丁，如果补丁是在 vc 库（或编译器）中提供的。同样，上述攻击需要了解 CPU 特定的 OP 才能从 CPU 发出缓存，这需要发出汇编代码，所以如果编写这样的代码，我会直接输入 asm 代码。
所以我认为上面的答案不应该是这样。我什至不确定您是如何知道这两者甚至相关的？由于我的问题与在不同编译器中编译的纯代码有关，并且这些漏洞利用了 CPU 架构，而这些架构不能简单地通过修补编译器来修补（我认为攻击者也会在将其部署到荒野之前测试他的程序是否可以正常工作）。
btw 发现 microsoft 在与幽灵 (/Qspectre) 相关的编译器中所做的操作：docs.microsoft.com/en-us/cpp/build/reference/… 您可以提供此开关以减少可能从 CPU 缓存中发出的程序数据。 “默认情况下，/Qspectre 选项处于关闭状态。” ;) 所以情况并非如此。
你有没有考虑过微软在编译他们的 C 支持 DLL 时可能有这个选项？否则，如果一个主应用程序是在它打开的情况下编译的，而库是在它关闭的情况下编译的，那将是一个大漏洞。我想你可以假设有多个版本，类似于调试开/关是不同的版本。但我怀疑不是。
"true I didn't" 话虽这么说，我正在分析我编写的一段代码不使用任何标准库功能，并且应该编译为相同的机器代码表示或更好较新的编译器，而不是更差的编译器。我可以使用 IDA 来分解真正的差异，但我认为有人已经知道它是什么。看看我这周是否有足够的时间来挖掘差异。现在我在 ~1.5GBps DXT1、~1GBps DXT5 的情况下，从解压缩代码中挤出 ~23% 的速度越来越少，因此平台工具集 v141 的减速可以忽略不计。