c - setjmp/longjmpにvolatileを使用した場合のパフォーマンスオーバーヘッド

Question

setjmp / longjmpを機能させるには、ローカル変数を揮発性として宣言する必要があります。誰かがそのコードを-O3でコンパイルしている場合、パフォーマンスに対する揮発性変数の影響はどのくらいになりますか。x86マルチコアプラットフォームでは、それは巨大なのか、それともほんの少しなのか？

私の意見では、その揮発性変数はまだキャッシュ可能であり、キャッシュからの読み取り/書き込みはとにかく非常に高速であるため、わずかなオーバーヘッドしか追加されません。意見？

Answer 1

簡単に言うと、すべてのセマンティクスはvolatileプラットフォーム/コンパイラに依存します。IA64アーキテクチャを備えたMSVCのような一部のコンパイラでは、volatileキーワードはコンパイラが操作を並べ替えることを防ぐだけでなく、取得/解放セマンティクスを使用して各読み取り/書き込み操作を実行します。つまり、メモリバリア操作が有効になります。一方、GCCは、揮発性メモリの場所への読み取り/書き込みの前後にコンパイラが操作を並べ替えることを防ぐだけです...ウィークメモリモデルを備えたプラットフォームでは、取得と解放のセマンティクスは、 MSVC。

x86では、厳密な順序のメモリモデルがあるため、volatileキーワードの使用によるメモリバリアの存在は問題になりません。したがって、主なペナルティは、実行可能な再順序付けやその他の最適化の欠如です。コンパイラによって。そうは言っても、それはあなたのコードがどのように見えるかに依存します。たとえば、コードにタイトループがあり、特定のvolatile修飾変数が実際にはループ不変条件である場合、それらのメモリ位置が非修飾として修飾された場合にコンパイラが実行できる最適化の一部を取得することはできません。volatile。

Answer 2

影響は、ローカル変数の数とコードがそれらをどのように処理するかによって異なります。の大きな影響の極端な例を作ることができると確信しています（たとえば、CPUキャッシュよりも大きい変数volatileの配列を宣言する）。volatile

実際には、すべての変数がである必要があるコードを維持したいと思う人はいないようvolatileです。つまり、含む関数setjmpはおそらく小さくなり、おそらくは内容だけが含まれることになりますsetjmp。この場合、volatile変数はほとんどまたはまったくなく、それらの「影響」は確かに小さいはずです。