4

Boost v1.59 の Boost.Context のドキュメントでは、次のパフォーマンス比較結果が報告されています。

+----------+----------------------+-------------------+-------------------+----------------+
| Platform |      ucontext_t      |    fcontext_t     | execution_context | windows fibers |
+----------+----------------------+-------------------+-------------------+----------------+
| i386     | 708 ns / 754 cycles  | 37 ns / 37 cycles | ns / cycles       | ns / cycles    |
| x86_64   | 547 ns / 1433 cycles | 8 ns / 23 cycles  | 16 ns / 46 cycles | ns / cycles    |
+----------+----------------------+-------------------+-------------------+----------------+

[リンク]

これらの実験のソース コードは GitHub でホストされていると思います。

私の質問は、ucontextのオーバーヘッドが Boost ライブラリの実装よりも 20 倍高いのはなぜですか? このような大きな違いが生じる明確な理由はわかりません。Boost の実装は、ucontext の実装者が見逃した低レベルのトリックを使用しているのでしょうか、それとも何か他のことがここで起こっているのでしょうか?

4

1 に答える 1

7

Boost のドキュメントには、Boost.context が非推奨のucontext_tインターフェイスよりも高速である理由が示されています。根拠セクションに、次の重要な注意事項があります。

注 UNIX システムでは、コンテキスト スイッチはシグナル マスクを保持しません。

そして、他の APIとの比較でmakecontextは:

ucontext_t は、多くの CPU サイクルを消費するシステム コールを含むコンテキスト スイッチ間のシグナル マスクを保持します。

示されているようswapcontextに、syscall とそれに伴うすべてのオーバーヘッドを必要とするシグナル マスクを保持します。まさにucontext_tそこが機能のポイントなので、見落としとは言えません。(シグナルマスクを保持したくない場合は、 と を使用できますsetjmp。longjmp)

ちなみに、これらのucontext_t関数は Posix エディション 6 で非推奨となり、エディション 7 で削除されました。これは、(1)makecontextインターフェイスが C の廃止された機能を必要とするため、C++ ではまったく利用できないためです。(2) インターフェースはめったに使用されません。(3) コルーチンは Posix スレッドを使用して実装できます。( Posix edition 6の注記を参照してください。) (明らかに、スレッドはコルーチンを実装するための理想的なメカニズムではありませんが、廃止された機能に依存するインターフェースでもありません。)

于 2015-10-25T16:50:00.773 に答える