追加読書

ブライアン・カーニガンが説明します。この動画初期のBell Labsが小さな言語/プログラムに魅力を感じたのは、メモリの制約によるものです。

大きなマシンは64キロバイト（MやGではなくK）を持っているため、個々のプログラムは非常に大きくできないため、小さなプログラムを書くのは自然な傾向があり、基本的には入力出力であるパイプメカニズムがあります。リダイレクトを使用すると、あるプログラムを別のプログラムにリンクできます。

ただし、プログラム間で転送するには、データをRAMに保存する必要があることを考慮すると、これがメモリ使用量を制限する方法はわかりません。

~からウィキペディア:

ほとんどのUnixシリーズシステムではパイプラインのすべてのプロセスが同時に開始されます。、対応するストリームは、適切に接続され、マシン上で実行される他のすべてのプロセスとともにスケジューラによって管理されます。 Unixパイプを他のパイプ実装と区別する重要な側面は、バッファリングの概念です。たとえば、送信者は毎秒5000バイトを生成できますが、受信者はデータを失うことなく1秒あたり100バイトしか許可できません。代わりに、送信プログラムの出力がバッファに格納されます。受信プログラムがデータを読み取る準備が整うと、パイプラインの次のプログラムはバッファからデータを読み取ります。 Linuxでは、バッファサイズは65536バイト（64KB）です。必要に応じて、bfrというオープンソースのサードパーティ製フィルタを使用してより大きなバッファを提供できます。

これはアプレットの目的を完全に崩壊させるので、私をさらに混乱させます（たとえ特定の規模でモジュール化されても）。

最初の問題（メモリ制限がデータサイズに依存する問題）を解決するために私が考えることができる唯一の方法は、大規模なデータセットが当時まったく計算されず、実際の問題はパイプラインです。 。しかし、Wikipediaの引用に太字で表示されている内容を見ると、これさえ私を混乱させます。なぜなら、プログラムは一度に1つずつ実装されていないからです。

これはすべて一時ファイルを使用する場合は意味がありますが、パイプは（スワップを使用しない限り）ディスクに書き込まないことです。

例:

sed 'simplesubstitution' file | sort | uniq > file2

sedファイルを1行ずつ読み、吐き出すことは明らかです。ただし、sortリンクされたビデオではBKが述べたようにピリオドなので、すべてのデータをメモリに読み込む必要があります（それともそうですか？）。それからに渡す必要があります。uniq（私の考えには）一度に1行になります。プログラム。ただし、最初のパイプと2番目のパイプの間には、すべてのデータがメモリに存在する必要があります。そうですか？