N-queens और मैट्रिक्स गुणा पर 20 प्रोग्रामिंग भाषाओं का बेंचमार्किंग
20 प्रोग्रामिंग भाषाओं पर N-queens और matrix multiplication के बेंचमार्क इस बात पर बहस छेड़ रहे हैं कि ऐसे परीक्षण वास्तव में क्या मापते हैं: कच्ची भाषा/runtime speed, compiler quality, या NumPy और BLAS जैसे ecosystems की ताकत। टिप्पणीकार बताते हैं कि naive, library-free implementations Python और अन्य dynamic languages को C, Julia, या Nim की तुलना में असंगत रूप से धीमा दिखा सकती हैं, और यह प्रश्न उठाते हैं कि क्या JIT warmup, memory layout, और non-idiomatic code नतीजों को skew करते हैं। कई लोगों का तर्क है कि ये microbenchmarks low-level performance characteristics समझने में उपयोगी हैं, लेकिन typical real-world workflows के बारे में कम बताते हैं, जहाँ optimized libraries, solvers, और domain-specific tools हावी होते हैं।
बेंचमार्क के लक्ष्य और कार्यप्रणाली
- बेंचमार्क में N-queens, matrix multiplication, sudoku, और bed coverage शामिल हैं, जिनमें ज़्यादातर हाथ से लिखी गई, “naive” implementations हैं, जो अक्सर Rosetta-शैली के उदाहरणों से प्रेरित हैं।
- कुछ लोग इसे तब उपयोगी मानते हैं जब आपको खुद एक नया algorithm implement करना हो और baseline भाषा/VM performance का आकलन करना हो।
- दूसरों का तर्क है कि code कई भाषाओं में suboptimal और non-idiomatic है, इसलिए नतीजे languages से ज़्यादा particular implementations के बारे में बता सकते हैं।
- JIT warmup और startup time को शामिल करना चाहिए या नहीं, इस पर बहस है; कुछ लोग मानते हैं कि “CLI से result तक” realistic है, जबकि अन्य warmed-up JITs चाहते हैं या AOT भाषाओं के compile time को भी जोड़ना चाहते हैं।
Libraries बनाम “pure language” performance
- एक प्रमुख thread NumPy, BLAS, या specialized tensor libs जैसी libraries को बाहर रखने पर विवाद करता है।
- एक पक्ष: benchmarks को बाहरी C/Fortran libraries के बिना languages की तुलना करनी चाहिए; नहीं तो आप सिर्फ FFI overhead माप रहे हैं।
- दूसरा पक्ष: idiomatic numerical Python, C#, आदि हमेशा ऐसी libraries का उपयोग करते हैं; pure-language matmul अवास्तविक है और वास्तविक-world performance को गलत दिखाता है।
- यह भी नोट किया गया है कि किसी भी भाषा में लगभग सभी high-performance matmul अंततः अत्यधिक optimized libraries पर निर्भर करते हैं, जिनमें अक्सर assembly भी होती है, और Python आम तौर पर तभी “fast” होता है जब वह इन्हीं को कॉल करता है।
Matrix multiplication की कठिनाई और BLAS
- कई टिप्पणियाँ इस बात पर ज़ोर देती हैं कि सचमुच BLAS-level matmul के लिए careful tiling, SIMD, cache/register-aware kernels, और कभी-कभी assembly की ज़रूरत होती है; compiler एक साधारण triple loop से >90% peak तक नहीं पहुँचेंगे।
- कुछ लोग दावा करते हैं कि विशिष्ट shapes/sparsity patterns के लिए आप C++/Nim-level control के साथ BLAS को match या beat कर सकते हैं; अन्य लोग इसका विरोध करते हैं, और प्रयोगों का हवाला देते हैं जहाँ hand-written code, substantial effort के बिना OpenBLAS से बहुत पीछे रहा।
- एक Nim project का उल्लेख किया गया है जिसके benchmarks multiple CPUs पर OpenBLAS और MKL के बराबर performance दिखाते हैं, जिसमें generated SIMD microkernels और custom threading का उपयोग किया गया है।
भाषा-विशिष्ट अवलोकन
- Rust: शुरुआती matmul
Vec<Vec>layout और bounds checks के कारण धीमा था; iterator-based या statically sized implementations अब C के बराबर हैं। - C#: शुरुआती matmul में rectangular arrays का उपयोग हुआ (हर access पर extra multiplications)। array-of-arrays पर स्विच करने से performance Java के करीब आती है; आगे SIMD (
Vector<T>/System.Numerics.Tensors) से और लाभ अपेक्षित हैं। - Swift: optimization के बाद matmul C/Rust के बराबर हो सकता है, लेकिन sudoku अभी भी धीमा है क्योंकि बहुत सारी heap allocations होती हैं और static arrays का अभाव है।
- Julia: शुरुआती matmul में गलत memory orientation थी और SIMD disabled था; fixed code C के करीब प्रदर्शन करता है।
- Mojo: matmul पर C से लगभग 2× धीमा, जिसे कुछ लोग ergonomics के लिहाज़ से स्वीकार्य मानते हैं, हालांकि अन्य इसे Julia की तुलना में verbose मानते हैं।
JIT, startup, और hardware
- कुछ लोग तर्क देते हैं कि JIT भाषाएँ cold runs में disadvantaged होती हैं; अन्य कहते हैं कि कई वास्तविक उपयोग (CLIs, builds) short-lived होते हैं, इसलिए cold performance महत्वपूर्ण है।
- ARM big.LITTLE systems यह सवाल उठाते हैं कि benchmarks performance cores पर चल रहे हैं या efficiency cores पर।
- Mono-, multi-threaded, और vectorization से जुड़ी details (जैसे OpenBLAS threading, AVX/AVX-512 usage, bounds checks) देखे गए अंतर को काफी प्रभावित करती हैं।
Charts और वैकल्पिक metrics
- Stacked bar charts तुलना को अस्पष्ट कर देते हैं जब कुछ languages (PHP, Ruby, Perl, pure CPython) बहुत धीमी हों; सुझावों में अलग charts, log scales, या ops/sec शामिल हैं।
- कुछ लोग gzipped source size या LOC जैसी अतिरिक्त metrics चाहते हैं ताकि expressiveness और code complexity प्रतिबिंबित हो; अन्य fair, human-centric size metric को परिभाषित करने की कठिनाई पर ध्यान देते हैं।
- कई टिप्पणीकार बड़े benchmark suites (जैसे Computer Language Benchmarks Game) की ओर इशारा करते हैं और अधिक real-world tasks (file I/O, JSON parsing, servers) की मांग करते हैं।