क्या Rust std fs Python से धीमा है? नहीं, यह हार्डवेयर की समस्या है

क्या OpenDAL Python binding Python से धीमी है?

• OpenDAL एक data access layer है जो विभिन्न storage services से डेटा को कुशलता से प्राप्त करने में मदद करती है।
• ऐसी रिपोर्टें हैं कि OpenDAL की Python binding, Python खुद से भी धीमी है।
• यह परिकल्पना दी गई है कि इसके कारण Python का internal cache, file read acceleration, और PyO3 का अतिरिक्त overhead हो सकते हैं।

क्या OpenDAL Fs service Python से धीमी है?

• यह Rust, OpenDAL, Python, PyO3 जैसे कई तत्वों से जुड़ी समस्या है।
• पाया गया कि Rust में implemented OpenDAL fs service भी Python से धीमी है।

क्या Rust std fs Python से धीमा है?

• OpenDAL, std::fs के माध्यम से fs service को implement करता है।
• यह पुष्टि हुई कि Rust के std::fs का उपयोग करने वाला implementation भी Python से धीमा है।

क्या Rust std fs Python से धीमा है? सच में!?

• इस परिणाम पर सवाल उठाया गया कि Rust std fs, Python से धीमा है।
• strace का उपयोग करके system call analysis करना सीखा गया।
• strace के परिणामों के विश्लेषण के बाद भी, दोनों के mmap का उपयोग करने के बावजूद Python तेज क्यों है, इसका कारण नहीं मिल पाया।

यहाँ mmap का उपयोग क्यों किया जाता है?

• mmap का उपयोग सिर्फ फाइल को memory में map करने के लिए नहीं, बल्कि बड़े memory regions allocate करने के लिए भी होता है।
• malloc से memory मांगने पर glibc, mmap का उपयोग करके memory allocate करता है।

क्या Python, Rust जैसा ही memory allocator रखता है?

• Python, pymalloc नाम का memory allocator उपयोग करता है, जो छोटे allocations के लिए optimized है।
• pymalloc छोटे objects के लिए optimized है, और बड़े allocations के लिए PyMem_RawMalloc() और PyMem_RawRealloc() का उपयोग करता है।

क्या Rust default memory allocator के साथ Python से धीमा है?

• संदेह है कि mmap ही समस्या पैदा कर रहा है।
• पाया गया कि jemalloc पर स्विच करने के बाद Rust प्रोग्राम Python से तेज चलने लगा।

क्या Rust सिर्फ मेरे कंप्यूटर पर Python से धीमा है!

• Rust का Python से धीमा चलना केवल एक खास कंप्यूटर पर ही हो रहा था।
• CPU और memory के बारे में विस्तृत जानकारी दी गई है।
• CPU vulnerability mitigation features, Transparent Hugepage, और CPU core affinity को समायोजित करने पर भी परिणाम में कोई बदलाव नहीं आया।
• eBPF प्रोग्राम का उपयोग करके यह पुष्टि की गई कि system call स्तर पर भी Rust, Python से धीमा था।

क्या C Python से धीमा है?

• पाया गया कि C में implement किया गया version भी Python से धीमा है।

क्या C Python से धीमा है? बिना निर्दिष्ट offset के!

• memory region offset में अंतर पाया गया, और offset को समायोजित करके C प्रोग्राम की गति में सुधार किया गया।
• यह पुष्टि हुई कि AMD Ryzen CPU पर खास offset के बिना performance degradation होता है।

क्या AMD Ryzen 9 5900X बिना निर्दिष्ट offset के धीमा है!

• यह पुष्टि हुई कि यह CPU से जुड़ी समस्या है, और kernel developer भी चर्चा में शामिल हुआ।
• perf का उपयोग करके profiling में फिर पुष्टि हुई कि offset के बिना performance degradation होता है।

GN⁺ की राय: इस लेख का सबसे महत्वपूर्ण बिंदु यह है कि खास hardware environment में Rust और C, Python से धीमे चल सकते हैं, और इसका कारण memory allocation तथा CPU के कुछ विशेष व्यवहार हो सकते हैं। यह लेख software performance को प्रभावित करने वाले विभिन्न तत्वों की पड़ताल के जरिए दिखाता है कि hardware और software के बीच की interaction कितनी जटिल हो सकती है। ऐसी पड़ताल software engineering की दुनिया में उभरने वाली अप्रत्याशित समस्याओं को सुलझाने के लिए महत्वपूर्ण सीख देती है।

[GN⁺]

Hacker News राय

• उलझाने वाले आधार-मान्यताओं पर राय

  एक उपयोगकर्ता इस बात पर भ्रम व्यक्त करता है कि लोग Python standard library की functions को pure Python में लिखा हुआ मानते हैं। Python की file reading methods और OpenDAL दोनों ही native code को wrap करने वाले Python wrappers हैं, इसलिए performance का अंतर दिलचस्प है, लेकिन इसे "Python से धीमा" कहना अजीब लगता है। उसका मानना है कि Python standard library की function implementations native code में हैं और हर एक optimized होगी। उसे इस बात पर आश्चर्य नहीं हुआ कि लेख का निष्कर्ष native code के काम करने के तरीके से जुड़ा था, और उसने माना कि कुछ जवाब चौंकाने वाले थे, लेकिन उलझी हुई शुरुआत के बावजूद यह बहुत दिलचस्प लेख था।

• CPU feature flags पर चर्चा

  दो dedicated CPU feature flags हैं, जो संकेत देते हैं कि REP STOS/MOV instructions memset/memcpy के लिए छोटे instruction sequence के रूप में तेज़ और उपयोग योग्य हैं। हर नई CPU generation के लिए optimized routines को हाथ से बनाना दशकों से चला आ रहा कष्ट है। यह सवाल उठाया गया कि क्या अब यह CPU निर्माताओं के timing test suite का हिस्सा नहीं होना चाहिए।

• संबंधित glibc bug link

  Zen 4 से जुड़े glibc bug का एक लिंक दिया गया।

• लेख पर सकारात्मक प्रतिक्रिया

  एक उपयोगकर्ता लेख पढ़कर std::fs के गलत उपयोग पर हँसने के लिए तैयार था, लेकिन उसने इसे rabbit hole और mystery की लगातार श्रृंखला बताते हुए कहा कि लेख बहुत अच्छी तरह लिखा गया है और बेहद दिलचस्प है।

• लेख की बहुत सराहना

  एक अन्य उपयोगकर्ता ने इसे इस सप्ताह पढ़े गए लेखों में सबसे दिलचस्प बताया और लेखन की बहुत प्रशंसा की।

• समस्या समाधान के लिए सुझाव

  एक स्पष्ट समाधान के तौर पर, "copy_user_generic" kernel method को बदलने के लिए patch भेजने का सुझाव दिया गया, ताकि यदि CPU को problematic पाया जाए और memory alignment slow bug को trigger करे, तो कोई दूसरा memory copy implementation इस्तेमाल किया जाए।

• Rust के default allocator की जानकारी

  यह जानकारी और संबंधित लिंक साझा किया गया कि 2018 तक Rust का default allocator jemalloc था।

• performance सुधार के लिए Rust developers की विचारणीय बातें

  यह जिज्ञासा जताई गई कि क्या Rust developers को jemallocator पर switch करके performance सुधारने पर विचार करना चाहिए, क्या यह ऐसा तरीका है जिससे सभी को मुफ्त में performance मिल सकती है, क्या C codebases भी इससे लाभ उठा सकती हैं, और क्या अभी भी कुछ performance table पर छूटी हुई है।

• AMD और Intel के CPU अंतर की व्याख्या

  समझाया गया कि AMD का string store तरीका Intel से अलग है, और CPU के L2 size को पार करने से पहले इसका उपयोग नहीं करना चाहिए। उस बिंदु के बाद string store का उपयोग फायदेमंद हो जाता है और इसे "DRAM speed" पर चलना चाहिए, लेकिन उच्च startup cost के कारण उस threshold तक पहुँचने से पहले 256-bit vector load/store का उपयोग करना चाहिए।

• लेख को सही लोगों तक पहुँचाने की बात

  एक उपयोगकर्ता ने बताया कि उसने यह लेख सही लोगों तक पहुँचा दिया है।