ブライアン・カーニハンは、このビデオで、メモリ制限に基づいている小さな言語/プログラムに対する初期のベル研究所の魅力について説明しています

大きなマシンは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番目のパイプの間では、すべてのデータがメモリ内にある必要がありますか？

データをRAMに保存する必要はありません。パイプは、リーダーがそこにいなかったり、追いつけない場合、ライターをブロックします。Linux（および他のほとんどの実装では、私が想像します）では、いくつかのバッファリングがありますが、それは必須ではありません。mtraceurとJdeBPで述べたように（参照後者の答えを）、Unixの初期バージョンはディスクへのパイプをバッファリングし、これがメモリ使用量を制限するのに役立ちました：処理パイプラインは、ディスクバッファの制限内で、それぞれがデータを処理する小さなプログラムに分割できました。小さなプログラムはメモリの消費が少なく、パイプを使用することで処理のシリアル化が可能になりました。最初のプログラムが実行され、その出力バッファーがいっぱいになり、中断され、次に2番目のプログラムがスケジュールされ、バッファーが処理されます。初期のUnixシステムよりもはるかに大きく、多くのパイプを並行して実行できます。しかし、大量のデータに対しては、同様の効果が見られます（そして、この種の手法の変形が「ビッグデータ」処理に使用されます）。

あなたの例では、

sed 'simplesubstitution' file | sort | uniq > file2

sedfile必要に応じてデータsortを読み取り、読み取り準備ができる限り書き込みます。sort準備ができていない場合、書き込みはブロックされます。データは最終的に実際にメモリに保存されますが、これはに固有のものsortでありsort、あらゆる問題に対処する準備ができています（ソートするデータ量が大きすぎる場合は一時ファイルを使用します）。

実行することにより、ブロック動作を確認できます

strace seq 1000000 -1 1 | (sleep 120; sort -n)

これにより、かなりの量のデータが生成され、最初の2分間は何も読み取る準備ができていないプロセスにパイプされます。多くのwrite操作が実行されますが、非常に迅速seqに停止し、カーネルによってブロックされた2分間の経過をwrite待機します（システムコールが待機します）。

しかし、プログラム間でデータを転送するためにデータをRAMに保存する必要があるという事実を考慮すると、これがどのようにメモリ使用を制限するのか理解できません。

これが基本的なエラーです。Unixの初期のバージョンは、RAMにパイプデータを保持していませんでした。彼らはそれらをディスクに保存しました。パイプにはiノードがありました。パイプデバイスと呼ばれたディスクデバイスに。システム管理者は、/etc/config（特に）どのディスク上のどのボリュームがパイプデバイスであり、どのボリュームがルートデバイスであり、どのダンプデバイスであるかを指定する名前のプログラムを実行しました。

保留中のデータの量は、ディスク上のiノードの直接ブロックのみがストレージに使用されるという事実によって制約されていました。パイプからの読み取りには通常のファイルの読み取りに使用されたアルゴリズムとほぼ同じアルゴリズムが使用されたため、このメカニズムによりコードがより簡単になりました。

このメカニズムは、1980年代半ばから後半にかけて他のメカニズムに置き換えられました。SCO XENIXは「高性能パイプシステム」を取得し、iノードをインコアバッファに置き換えました。4BSDは、名前のないパイプをソケットペアにしました。AT＆Tは、STREAMSメカニズムを使用してパイプを再実装しました。

そしてもちろん、sortプログラムは入力の32KiBチャンクの限られた内部ソート（または32KiBが利用できない場合に割り当てることができるより小さなメモリ）を実行し、ソートされた結果を中間stmX??ファイルに書き込み、そこで/usr/tmp/外部的にソートされて最終を提供します出力。

参考文献

• Steve D. Pate（1996）。「プロセス間通信」。UNIX Internals：A Practical Approach。アディソン・ウェスリー。ISBN 9780201877212。
• モーリス・J・バッハ（1987）。「ファイルシステムのシステムコール」。 Unixオペレーティングシステムの設計。プレンティスホール。ISBN 0132017571。
• スティーブンV.イアハート（1986）。「config（1M）」。 Unixプログラマーズマニュアル：3.システム管理機能。ホルト、ラインハート、ウィンストン。ISBN0030093139。23〜28ページ。

部分的には正しいですが、偶然です。

この例では、すべてのデータは実際にパイプの「間に」読み込まれている必要がありますが、メモリ（仮想メモリを含む）に常駐する必要はありません。の通常の実装でsortは、一時ファイルにパーシャルソートを実行してマージすることにより、RAMに収まらないデータセットをソートできます。ただし、すべての要素を読み取る前にソートされたシーケンスを出力できない可能性があることは事実です。それはかなり明白です。そのため、はい、sort最初からすべてを読み取った（そして、おそらく一時ファイルを部分的にソートした）後、2番目のパイプへの出力を開始できます。ただし、必ずしもすべてをRAMに保持する必要はありません。

ただし、これはパイプの動作とは関係ありません。パイプには名前を付けることができます（従来はすべて名前が付けられていました）。つまり、ファイルのようにファイルシステム内に場所を持っていることを意味します。そして、それは、パイプが昔々、ファイルであったものです（最適化として、物理メモリの可用性が許す限り書き込みが合体します）。

今日、パイプはデータがコピーされる小さな有限サイズのカーネルバッファーであり、少なくとも概念的にはそうなっています。カーネルがそれを支援できる場合、VMトリックを再生することでコピーが省略されます（たとえば、通常、ファイルからパイプすると、他のプロセスが読み取るために同じページを使用できるようになるため、最終的には2つのコピーではなく読み取り操作のみとなり、とにかく、バッファキャッシュで既に使用されているよりも多くのメモリが必要です。状況によっては、100％ゼロコピーが発生することもあります。

パイプが小さく、有限サイズである場合、これは未知の（おそらく大量の）データ量に対してどのように機能しますか？それは簡単です。これ以上収まらない場合、書き込みは再びスペースができるまでブロックします。

多くの単純なプログラムの哲学は、かつてメモリが非常に不足していたときに最も役に立ちました。なぜなら、小さなステップで、一度に1つずつ作業できるからです。最近では、柔軟性が増していることを除けば、その利点はあえて言えません。
ただし、パイプは非常に効率的に実装されているため（そうでなければなりませんでした！）