setjmp/longjmp 使用 volatile 的性能开销
要使 setjmp/longjmp 正常工作，您需要将局部变量声明为 volatile。如果有人使用 -O3 编译代码，那么 volatile 变量对性能的影响有多大。在 x86 多核平台上它会很大还是很小？
在我看来，它只会增加一点点开销，因为该易失性变量仍然可以被缓存，并且从缓存中读取/写入无论如何都非常快。意见？
For setjmp/longjmp to work, you need to declare local variables as volatile. If someone is compiling its code with -O3, how much would be the impact of volatile variables on performance . Would it be huge or only a tiny bit on an x86 multicore platform?
In my opinion, it would only add tiny bit of overhead, because that volatile variable could still be cached and reading/writing from cache is quite fast anyway. Opinions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
顺便说一句，易失性的语义完全取决于平台/编译器。在某些具有 IA64 架构的编译器（例如 MSVC）上，
volatile关键字不仅可以防止编译器重新排序操作，还可以使用获取/释放语义执行每个读/写操作，这意味着存在内存-屏障操作生效。另一方面，GCC 仅阻止编译器在读/写易失性内存位置之前/之后重新排序操作...在具有弱内存模型的平台上，获取-释放语义不会像它们那样得到维护MSVC。现在在 x86 上，由于其严格排序的内存模型，使用
volatile关键字导致的内存屏障的存在不再是问题，因此主要的缺点就是缺乏重新编译器可以执行的排序和其他优化。话虽如此，这将取决于您的代码的外观。例如，如果您的代码中有一个紧循环，并且某些易失性限定的变量实际上是循环不变式，则您将无法获得编译器可以执行的一些优化，如果这些内存位置被认定为非易失性的。As a quick aside, the semantics of
volatileall depend on the platform/compiler. On some compilers like MSVC with IA64 architecture, thevolatilekeyword not only prevents the compiler from re-ordering operations, it also performs each read/write operation with acquire/release semantics, meaning there is a memory-barrier operation in effect. GCC on the other-hand only prevents the compiler from re-ordering operations before/after the read/write to the volatile memory location ... on platforms with weak-memory models, the acquire-release semantics are not maintained like they are with MSVC.Now on x86, because of its strict-ordering memory model, the presence of memory barriers from the use of the
volatilekeyword aren't an issue, so the main penalty will simply be the lack of re-ordering and other optimizations that can be performed by the compiler. That being said, it will then depend on what your code looks like. For instance, if you have a tight-loop in your code, and certainvolatile-qualified variables are actually loop-invariants, you're not going to get some of the optimizations that the compiler could do if those memory locations were qualified as non-volatile.影响取决于局部变量的数量以及代码对它们执行的操作。我相信人们可以编造一个极端的例子来说明 易失性 的巨大影响（例如声明一个大于 CPU 缓存的易失性变量数组）。
似乎在实践中没有人愿意维护所有变量都必须是
易失性的代码。这意味着包含setjmp的函数可能会很小，可能只包含setjmp内容。在这种情况下，将有很少或没有易失性变量，并且它们的“影响”确实应该很小。The impact depends on the number of local variables and whatever the code does with them. I am sure one could make up an extreme example for a huge impact of
volatile(e.g. declaring an array ofvolatilevariables larger than CPU cache).It seems that in practice no one wants to maintain code in which all variables have to be
volatile. That means that the function containingsetjmpis probably going to be small, probably containing just thesetjmpstuff. In this case, there will be little or novolatilevariables, and their "impact" should indeed be small.