Python में `a + b` को चलाने में C की कितनी पंक्तियाँ लगती हैं
Python का सरल expression `a + b` C code और runtime machinery की बड़ी मात्रा को छिपाता है, जिसमें dynamic dispatch, magic methods, arbitrary-precision integers, और hash-based attribute lookup शामिल हैं। टिप्पणीकार इसे इस प्रश्न के लिए एक शुरुआत की तरह उपयोग करते हैं कि CPython, JIT-based runtimes (जैसे V8, LuaJIT, या PyPy) की तुलना में अपेक्षाकृत धीमा क्यों है, और वे object dynamism, C API, तथा security-focused hashing जैसी design choices की ओर इशारा करते हैं। कई लोगों का मानना है कि Python fast C या C++ libraries के चारों ओर “glue” के रूप में उत्कृष्ट है, न कि एक high-performance compute engine के रूप में, और पर्याप्त speedups के लिए superficial tweaks के बजाय गहरे architectural changes की आवश्यकता होगी.
मूल प्रश्न का दायरा
- कई लोग नोट करते हैं कि लेख वास्तव में यह नहीं बताता कि
a + bके लिए “C की कितनी पंक्तियाँ” चलती हैं। - कुछ का तर्क है कि यह धारणा ही ठीक से परिभाषित नहीं है: एक बार
__add__/__radd__जैसी operator overloading की अनुमति हो जाए, तोa + bमनमाने रूप से जटिल काम कर सकता है। - अन्य सुझाव देते हैं कि कम से कम code coverage या profiling से एक ठोस run मापा जा सकता है, लेकिन वह भी path- और input-dependent होगा।
Dynamic dispatch, magic methods, और जटिलता
- चर्चा इस बात पर ज़ोर देती है कि CPython में साधारण operations के पीछे भी कितनी machinery होती है: object model, type slots के माध्यम से dynamic dispatch, magic
__dunder__methods, descriptors, और iteration के लिए exceptions। - JS या Lua जैसी भाषाओं की तुलना में, Python साधारण objects पर “magic” को अधिक व्यापक रूप से expose करता है, जिससे aggressive optimization और JITing कठिन हो जाती है।
- builtins (जैसे
int) को subclass करना और custom descriptors specialization को और जटिल बनाते हैं।
Performance, JITs, और design trade-offs
- कई commenters का तर्क है कि CPython जानबूझकर performance-focused नहीं है; यह simplicity और C interop के लिए optimize करता है, और Python को fast native libraries के ऊपर “glue” के रूप में देखना सबसे अच्छा है।
- अन्य लोग जवाब देते हैं कि दूसरी dynamic भाषाएँ (JS, LuaJIT, Smalltalk, Ruby JITs) दिखाती हैं कि पर्याप्त engineering से high performance संभव है।
- इस पर बहस है कि top-tier JIT के रास्ते में Python की language design मुख्य बाधा है या C API और ecosystem।
- हालिया faster-CPython काम और external JITs (PyPy, Pyston) का उल्लेख किया गया है; अब तक के सुधारों को वास्तविक लेकिन JS की JIT क्रांति की तुलना में modest माना जाता है।
Hashing, security, और speed
- एक side thread उन दावों पर लौटता है कि Python के hash function को बदलने से performance दोगुनी हो सकती है।
- कई commenters इससे असहमत हैं: string hashes cached होते हैं, symbol names interned होते हैं, और जिन benchmarks ने बड़े wins दिखाए थे उन्हें अवास्तविक कहा गया।
- Python का randomized SipHash (पुराने FNV के बजाय) मुख्यतः HashDoS resistance के लिए है; वास्तविक workloads में performance impact छोटा दिखाई देता है।
- integers के लिए identity hashing पर भी चर्चा होती है; यह hash table implementation से interact करता है और कुछ integer distributions के साथ pathologies पैदा कर सकता है।
C बनाम Python ergonomics और “सीधे C क्यों नहीं”
- कुछ लोग सुझाव देते हैं कि सीधे C का उपयोग करना “आसान” हो सकता है, लेकिन अन्य Python के बहुत कम boilerplate और built-in big-int support पर ज़ोर देते हैं।
- उदाहरण दिखाते हैं कि arbitrary-precision arithmetic को लागू करने में Python की कितनी कम पंक्तियाँ लगती हैं, जबकि समान behavior और safety के लिए C या C++ में बहुत अधिक पंक्तियाँ चाहिए होती हैं।