4

私は Grand Central Dispatch の大ファンで、最近は Callsdispatch_io_*ファミリーを見ています。この API がネットワーク I/O (低速、高レイテンシー) にどのように役立つかは簡単にわかります。dispatch_io_create_with_pathつまり、一種の存在は、ローカルファイルシステムでの使用を意味します。(はい、パスがリモート ネットワーク ファイル システム上のリソースを指している可能性があることはわかっていますが、いずれにせよ...) それをいじってdispatch_io_*みると、単純なブロッキングを使用する場合と比較して、使用するとかなりのオーバーヘッドが発生するように見えることがわかりました。 I/O 呼び出し ( read,writeなど）。この速度低下は主に、ブロックがキュー間でマーシャリングされるときに使用されるカーネル同期プリミティブによるものと思われます。私が試したサンプル ワークロード (非常に多くの I/O バウンド) では、速度低下が 10 倍にもなることがあります。dispatch_io1つには、おしゃべりな (小さな粒状の) I/O には決して勝てないように見えます。

単一のローカル物理ストレージ ボリュームを持つ単一のマシンの一般的なケースでは、I/O 要求はデバイス レベルで効果的にシリアル化されると思います。そこから、私は次の2つの考えに気づきました。

  • ワークロードが CPU バウンドの場合、定義上、データを処理するよりも速く読み書きできます。
  • ワークロードが I/O バウンドの場合 (この状況では、1 つのローカルの物理ボリューム) を使用してdispatch_ioも、ディスクのデータが高速になることはありません。

そこから、この API のスイート スポットは中間にあるのではないかと考えました。つまり、CPU バウンドと I/O バウンドの間で揺れ動くワークロードです。だから私はStackOverflowに尋ねると思いました。

dispatch_ioこれらの前提条件 (つまり、単一のマシン、単一のローカル物理ディスク) を使用することでパフォーマンスが大幅に向上する「実際の」ワークフローを説明する最初の回答を受け入れます。

4

1 に答える 1

7

ローカル ファイルシステムからのディスパッチ I/O の主な使用例は、大きなファイルの非同期 IO、または同時に読み書きされる多数のファイルの非同期 IO です (特に、ファイルの内容をインクリメンタルに処理できる場合)。

ローカル ファイルシステムからのディスパッチ I/O は、レイテンシに対するスループットに対して最適化されました (たとえば、実際の IO syscall の前にチャンキングとアドバイザリ読み取りを実行して、カーネルとドライバーを介した IO パスのパイプラインとスループットを最適化します)。

バックグラウンド スレッドでの IO syscall の非同期実行を考えると、ディスパッチ IO は、特に他の IO アクティビティが進行中でない場合に、ブロッキング syscall で実行される小さなファイル IO のレイテンシーを超えることはありません。

WWDC11 の GCD セッションでは、ディスパッチ I/O についてある程度詳しく説明し、さまざまなサイズの多数のファイルを読み取るための read() システムコールを直接使用した場合のスループットの向上の例を比較しています。

于 2013-01-21T01:24:43.113 に答える