パイプラインはメモリ使用量をどのように制限しますか?
ブライアン・カーニハンは、このビデオで、メモリ制限に基づいている小さな言語/プログラムに対する初期のベル研究所の魅力について説明しています 大きなマシンは64 Kバイト(MまたはGではなくK)であるため、個々のプログラムはあまり大きくできず、小さなプログラムを作成する傾向があり、次にパイプメカニズム、基本的に入出力のリダイレクトにより、あるプログラムを別のプログラムにリンクすることが可能になりました。 しかし、プログラム間でデータを転送するためにデータをRAMに保存する必要があるという事実を考慮すると、これがどのようにメモリ使用を制限するのか理解できません。 ウィキペディアから: ほとんどのUnixライクなシステムでは、パイプラインのすべてのプロセスが同時に開始されます[強調鉱山]、ストリームが適切に接続され、マシン上で実行されている他のすべてのプロセスとともにスケジューラーによって管理されます。これの重要な側面は、Unixパイプを他のパイプ実装とは別に設定することです。バッファリングの概念です。たとえば、送信プログラムは毎秒5000バイトを生成し、受信プログラムは毎秒100バイトしか受け入れられませんが、データが失われます。代わりに、送信プログラムの出力はバッファに保持されます。受信プログラムがデータを読み取る準備ができると、パイプラインの次のプログラムがバッファから読み取ります。Linuxでは、バッファーのサイズは65536バイト(64KB)です。必要に応じて、より大きなバッファを提供するために、bfrと呼ばれるサードパーティのオープンソースフィルターを使用できます。 これは小さなプログラムの目的を完全に無効にするため、さらに混乱します(ただし、それらは一定の規模までモジュール化されます)。 私の最初の質問(メモリの制限はサイズデータに依存する問題)の解決策として考えることができる唯一のことは、当時大きなデータセットが単に計算されておらず、実際の問題パイプラインは解決することでしたプログラム自体が必要とするメモリ量。しかし、Wikipediaの引用文の太字のテキストを考えると、これでも混乱します。1つのプログラムが一度に実装されないためです。 一時ファイルが使用されている場合、これは非常に理にかなっていますが、パイプがディスクに書き込まれないことは私の理解です(スワップが使用されない限り)。 例: sed 'simplesubstitution' file | sort | uniq > file2 sedファイルを読み込んで行ごとに吐き出しているのは明らかです。しかしsort、リンクされたビデオでBKが述べているように、完全に停止しているので、すべてのデータをメモリに読み込む必要がありますか(またはそれを行いますか?)、それはに渡されますuniq(私にとっては) -ラインアットアタイムプログラム。しかし、最初のパイプと2番目のパイプの間では、すべてのデータがメモリ内にある必要がありますか?