Brian Kernighan menjelaskan dalam video ini ketertarikan awal Bell Labs terhadap bahasa/program kecil yang didasarkan pada keterbatasan memori
Sebuah mesin besar akan menjadi 64 k-byte–K, bukan M atau G–dan itu berarti setiap program individu tidak bisa menjadi sangat besar, dan ada kecenderungan alami untuk menulis program kecil, dan kemudian mekanisme pipa, pada dasarnya memasukkan pengalihan output, memungkinkan untuk menautkan satu program ke program lainnya.
Tapi saya tidak mengerti bagaimana ini bisa membatasi penggunaan memori mengingat fakta bahwa data harus disimpan dalam RAM untuk dikirim antar program.
Dari Wikipedia:
Di sebagian besar sistem mirip Unix, semua proses pipeline dimulai pada saat yang sama [emphasis mine] , dengan alirannya terhubung dengan tepat, dan dikelola oleh penjadwal bersama dengan semua proses lain yang berjalan di mesin. Aspek penting dari hal ini, memisahkan pipa Unix dari implementasi pipa lainnya, adalah konsep buffering:misalnya program pengirim dapat menghasilkan 5000 byte per detik, dan program penerima mungkin hanya dapat menerima 100 byte per detik, tetapi tidak datanya hilang. Sebagai gantinya, output dari program pengirim disimpan di buffer. Ketika program penerima siap membaca data, maka program berikutnya di dalam pipeline membaca dari buffer. Di Linux, ukuran buffer adalah 65536 byte (64KB). Filter pihak ketiga open source yang disebut bfr tersedia untuk menyediakan buffer yang lebih besar jika diperlukan.
Hal ini semakin membingungkan saya, karena ini sama sekali mengalahkan tujuan program kecil (walaupun mereka akan bersifat modular hingga skala tertentu).
Satu-satunya hal yang dapat saya pikirkan sebagai solusi untuk pertanyaan pertama saya (keterbatasan memori menjadi masalah tergantung pada ukuran data) adalah bahwa kumpulan data besar tidak dihitung saat itu dan saluran pipa masalah sebenarnya yang dimaksudkan untuk dipecahkan adalah jumlah memori yang dibutuhkan oleh program itu sendiri. Tetapi mengingat teks yang dicetak tebal dalam kutipan Wikipedia, saya malah bingung:karena satu program tidak diimplementasikan pada satu waktu.
Semua ini akan sangat masuk akal jika file temp digunakan, tetapi menurut pemahaman saya bahwa pipa tidak menulis ke disk (kecuali swap digunakan).
Contoh:
sed 'simplesubstitution' file | sort | uniq > file2
Jelas bagi saya bahwa sed sedang membaca dalam file dan meludahkannya baris demi baris. Tapi sort , seperti yang dinyatakan BK dalam video tertaut, adalah titik, jadi semua data harus dibaca ke dalam memori (atau bukan?), lalu diteruskan ke uniq , yang (menurut saya) akan menjadi program satu baris setiap kali. Tapi antara pipa pertama dan kedua, semua data harus ada di memori, bukan?
Jawaban yang Diterima:
Data tidak perlu disimpan di RAM. Pipes memblokir penulisnya jika pembaca tidak ada atau tidak bisa mengikuti; di Linux (dan sebagian besar implementasi lainnya, saya bayangkan) ada beberapa buffering tetapi itu tidak diperlukan. Seperti yang disebutkan oleh mtraceur dan JdeBP (lihat jawaban yang terakhir), versi awal pipa buffer Unix ke disk, dan ini adalah bagaimana mereka membantu membatasi penggunaan memori:pipa pemrosesan dapat dipecah menjadi program kecil, yang masing-masing akan memproses beberapa data , dalam batas buffer disk. Program kecil membutuhkan lebih sedikit memori, dan penggunaan pipa berarti pemrosesan dapat diserialkan:program pertama akan berjalan, mengisi buffer outputnya, ditangguhkan, kemudian program kedua akan dijadwalkan, memproses buffer, dll. Sistem modern adalah perintah besarnya lebih besar dari sistem Unix awal, dan dapat menjalankan banyak pipa secara paralel; tetapi untuk data dalam jumlah besar, Anda masih akan melihat efek yang serupa (dan varian dari teknik semacam ini digunakan untuk pemrosesan "data besar").
Dalam contoh Anda,
sed 'simplesubstitution' file | sort | uniq > file2
sed membaca data dari file seperlunya, lalu tulis sepanjang sort siap untuk membacanya; jika sort belum siap, blok tulis. Data memang tinggal di memori pada akhirnya, tapi itu khusus untuk sort , dan sort siap untuk menangani masalah apa pun (ini akan menggunakan file sementara jika jumlah data yang akan disortir terlalu besar).
Anda dapat melihat perilaku pemblokiran dengan menjalankan
strace seq 1000000 -1 1 | (sleep 120; sort -n)
Ini menghasilkan cukup banyak data dan menyalurkannya ke proses yang tidak siap untuk membaca apa pun untuk dua menit pertama. Anda akan melihat sejumlah write operasi berjalan, tetapi sangat cepat seq akan berhenti dan menunggu selama dua menit, diblokir oleh kernel (write panggilan sistem menunggu).