Linux pipes की गति कितनी तेज़ है? (2022)

• Linux में Unix pipe के implementation और pipe के ज़रिए data लिखने और पढ़ने वाले test program को optimize करने के तरीकों की पड़ताल
• शुरुआती program का throughput लगभग 3.5GiB/s था, और कई optimizations के जरिए इसे 20 गुना बढ़ाया गया
• ये optimizations Linux के perf tool से program की profiling करके हासिल किए गए
• लेख को ~35GiB/s की रफ़्तार से pipe में output धकेलने वाले optimized FizzBuzz program से प्रेरणा मिली
• pipe के आंतरिक काम करने के तरीके, उनसे लिखना और पढ़ना धीमा क्यों होता है, और vmsplice व splice system calls performance कैसे बेहतर करते हैं—इस पर गहराई से चर्चा
• Linux paging और huge pages के उपयोग से program के तेज़ version तक कैसे पहुँचा जा सकता है, इस पर चर्चा
• अंतिम optimization में polling को busy loop से बदलना शामिल है
• test Intel Skylake i7-8550U CPU और Linux 5.17 पर किए गए
• लेख विस्तार से बताता है कि memory निश्चित आकार के टुकड़ों यानी pages से कैसे बनी होती है, और CPU page tables का उपयोग करके virtual addresses को physical addresses में कैसे बदलता है
• लेख इस अवलोकन के साथ समाप्त होता है कि program में huge pages पर स्विच करने से performance लगभग 50% बेहतर होती है
• लेख CPU में huge pages के उपयोग और Translation Lookaside Buffer (TLB) misses को कम करने के तरीकों पर चर्चा करता है, जिससे performance बेहतर हो सकती है
• kernel code यह मानकर चलता है कि struct page मौजूदा architecture के standard-size page को दर्शाता है। huge pages के मामले में, "head" struct page में वास्तविक physical page की जानकारी होती है, जबकि लगातार आने वाले "tail" pages में केवल head page की ओर इशारा करने वाला pointer होता है
• हाल के kernel (5.17 के बाद) में struct folio नाम का नया type शामिल है, जो head page को स्पष्ट रूप से पहचानता है। इससे runtime पर यह जाँचने की ज़रूरत कम होती है कि struct page head page है या tail page, और performance बेहतर होती है
• लेख synchronization cost से बचने के लिए busy loop की अवधारणा पर चर्चा करता है। इसमें vmsplice से अनुरोध किया जाता है कि जब pipe में लिखा न जा सके तो वह लौट आए, और तैयार होने तक busy loop चलती रहे। इससे 25% तक performance gain मिल सकता है, लेकिन इसकी कीमत यह है कि vmsplice के तैयार होने तक एक CPU core पूरी तरह व्यस्त रहता है
• लेखक लेख में शामिल मुख्य विषयों का सार देते हैं: zero-copy operations, ring buffer, paging और virtual memory, synchronization overhead
• लेखक यह भी स्वीकार करते हैं कि कई अन्य options और details पर चर्चा नहीं की गई, क्योंकि वे या तो प्रासंगिक नहीं थे या उनकी रुचि का विषय नहीं थे
• लेख को पाठकों से अच्छी प्रतिक्रिया मिली, क्योंकि उन्हें यह उपयोगी और रोचक लगा

[GN⁺]

Hacker News की राय

• Linux pipe की गति पर लेख, जो vmsplice पर केंद्रित है, जो दो processes के बीच एक mini shared memory mechanism की तरह काम करता है
• vmsplice का उपयोग पढ़ने और लिखने के समय buffers को सावधानी से संभालने की मांग करता है, और यह जटिल है, लेकिन efficient हो सकता है
• रिपोर्ट के अनुसार Linux pipe का standard implementation आदर्श गति की तुलना में 20 गुना धीमा है
• लेख को अच्छा प्रतिसाद मिला, और पाठकों ने इसकी जानकारीपूर्ण प्रकृति की प्रशंसा की
• एक पाठक ने बताया कि Linux pipe deterministic behavior बना सकते हैं, और आगे पढ़ने के लिए एक बाहरी स्रोत लिंक किया
• pipe, socket, file और memory के ऊपर abstraction देने वाली data processing libraries के बारे में सवाल उठाया गया, और इस पर चर्चा हुई कि क्या वे लेख में बताई गई optimizations को implement करती हैं
• लेख में splice() और vmsplice() जैसे API का उल्लेख है, और कहा गया है कि इन्हें अधिकांश programs में इस्तेमाल करना कठिन है, इसलिए इनका उपयोग कम होता है
• Linux pipe की गति की तुलना सिस्टम के भीतर एक single core की गति से की गई है; kernel एक program के stdout से दूसरे program के stdin तक उसी physical memory page को map कर देता है, जिससे काम zerocopy या कम अनुकूलित स्थिति में तेज onecopy बन जाता है
• लेख page table की अवधारणा को perf का उपयोग करके किए गए performance analysis से जोड़ता है, और throughput के लिए इसके महत्व पर जोर देता है
• एक पाठक ने Cygwin pipe implementation के साथ अपना अनुभव साझा किया और Linux की तुलना में इसकी धीमी गति का उल्लेख किया
• माना गया कि Linux pipe की गति cat, sed, awk, cut, grep, uniq, jq जैसे commands को बार-बार चलाने और जोड़ने के लिए पर्याप्त है