क्या Rust, C से तेज़ है?
(steveklabnik.com)- Rust और C के performance की तुलना एक जटिल सवाल है, जो इस बात पर निर्भर करती है कि “सभी शर्तें समान हैं” की परिभाषा क्या है
- Inline assembly के मामले में दोनों भाषाएँ एक जैसा assembly code बना सकती हैं, इसलिए भाषा स्वयं के स्तर पर speed का कोई अंतर नहीं है
- Struct memory layout में Rust field reordering के ज़रिए आकार को छोटा कर सकता है, लेकिन
#[repr(C)]attribute के साथ C जैसा ही layout भी संभव है - Runtime checks और developer behavior के अंतर की वजह से वास्तविक projects में code structure और performance अलग हो सकते हैं
- निष्कर्षतः भाषा की अपनी सीमाओं के कारण performance का कोई अंतर नहीं है, और नतीजे project व developer factors के अनुसार बदलते हैं
समस्या की रूपरेखा और मान्यताओं की अस्पष्टता
- Reddit पर उठाया गया “अगर शर्तें समान हों, तो क्या Rust, C से तेज़ हो सकता है?” यही शुरुआती सवाल है
- “सभी शर्तें समान हैं” यह वाक्य ही language comparison में परिभाषित करना बहुत कठिन है
- Performance comparison केवल language differences पर नहीं, बल्कि code shape, developer decisions, और compiler optimizations पर भी निर्भर करती है
Inline assembly की तुलना
- Rust language level पर inline assembly को support करता है, जबकि C इसे compiler extension के रूप में लागू करता है
- दोनों भाषाओं में
rdtsccommand इस्तेमाल करने वाला एक जैसा उदाहरण लिखा जा सकता है rustc 1.87.0औरclang 20.1.0से बना assembly output पूरी तरह समान रूप में निकलता है
- दोनों भाषाओं में
- यह उदाहरण language performance difference नहीं दिखाता, लेकिन यह साबित करता है कि Rust, C के बराबर low-level control दे सकता है
Struct layout का अंतर
- Rust structs field reordering के जरिए memory usage को optimize कर सकते हैं
- उदाहरण में Rust struct 16 bytes का है, जबकि वही C struct 24 bytes का निकलता है
- C में वही आकार पाने के लिए field order को manually बदलना पड़ता है
- Rust में
#[repr(C)]attribute का उपयोग करके C जैसा ही memory layout मजबूर किया जा सकता है
सामाजिक और developer factors
- Rust के safety checks की वजह से कुछ मामलों में developers ज़्यादा aggressive optimization आज़मा सकते हैं
- Mozilla के Stylo project में C++ के साथ parallelization की दो कोशिशें असफल रहीं, लेकिन Rust में इसे सफलतापूर्वक लागू किया गया
- एक ही project में भी language और developer skill के आधार पर final code की performance और stability बदल सकती है
- शुरुआती developer, expert, और language proficiency के अंतर के कारण “एक ही काम” का परिणाम अलग हो सकता है, इसलिए सरल तुलना मुश्किल है
Compile time और runtime checks
- Rust के कई safety checks compile time पर किए जाते हैं, लेकिन कुछ runtime checks के रूप में बने रहते हैं
- उदाहरण के लिए
array[0]access पर Rust bounds check करता है, जबकि C नहीं करता - Rust में
get_unchecked()का उपयोग करने पर C जैसा ही behavior मिल सकता है
- उदाहरण के लिए
- अगर compiler safety साबित कर सके, तो दोनों भाषाओं में checks को optimization से हटाया जा सकता है
- ये अंतर code लिखने के तरीके को प्रभावित करते हैं, और आखिरकार performance difference पैदा कर सकते हैं
निष्कर्ष
- अगर यह मान भी लिया जाए कि C “सबसे तेज़ भाषा” है, तब भी ऐसा कोई कारण नहीं है कि Rust समान स्तर की performance न दे सके
- भाषा की अंतर्निहित सीमाओं से ज़्यादा project की प्रकृति, developer capability, time constraints जैसे बाहरी variables performance का अंतर तय करते हैं
- इसलिए “क्या Rust, C से तेज़ है?” यह सवाल language comparison से ज़्यादा engineering context का सवाल है
9 टिप्पणियां
एम्बेडेड में तो hardware cache line size तक को ध्यान में रखकर coding की जाती है। बात शायद इस पर है कि programmer language के ऊपर रहकर extreme optimization कहाँ तक कर सकता है, और standard library व compiler performance का भी मुद्दा होगा। वैसे भी दोनों low-level को support करते हैं, इसलिए थोड़ा-बहुत overhead का फर्क शायद बहुत मामूली स्तर का ही होगा। इसलिए यह बहुत meaningful बहस नहीं लगती.. अगर extreme optimization चाहिए, तो आखिरकार इंसानी दखल ज़रूरी होता है। compiler उतना perfect नहीं है जितना हम सोचते हैं।
मुझे लगता है कि Rust, C की बजाय C++ का विकल्प बनेगा। C लगभग एकमात्र (शायद आख़िरी) ऐसी भाषा है जिसमें आप काफ़ी हद तक अनुमान लगा सकते हैं कि compiler कौन-सा code बनाएगा…
zig भी बुरा नहीं है... sobs
लिखते-लिखते AI-समरी वाली शैली हो गई T_T
क्या आपने यह जानबूझकर नहीं किया था? हाहा
यह compiler की क्षमता पर निर्भर करता है.
अगर उसी code को assemble करके देखें, तो पता चल जाएगा.
लगता है ffmpeg वाले अंकल लोग सोचते हैं कि Rust, C से तेज़ नहीं है lol https://www.memorysafety.org/blog/rav1d-perf-bounty/
Hacker News की राय
संक्षेप में, अधिकतम गति लगभग समान है, लेकिन वास्तविक कोड में अंतर बड़ा होता है
खासकर multithreading एक बड़ा फ़ैक्टर है। Rust में thread इस्तेमाल करें या न करें, सभी global variables thread-safe होने चाहिए, और borrow checker memory access को shared या mutable में से किसी एक तक सीमित करता है
इसलिए Rust में multithreaded code लिखना लगभग डिफ़ॉल्ट जैसा हो जाता है। दूसरी ओर C में thread बनाना ही platform compatibility समस्याओं या debugging risk की वजह से बोझिल हो सकता है
C में thread build करना मुश्किल नहीं है, लेकिन Rust के
std::thread::spawn(move || { ... });से ज़्यादा झंझट हैmemory safety से ज़्यादा असर भाषा के concurrency model का पड़ता है। Go memory-safe न होते हुए भी
go f()से आसानी से parallelize कर देता हैव्यक्तिगत रूप से, मैंने Go में heisenbug ज़्यादा देखे हैं
#pragma omp forकी एक लाइन से C में भी आसानी से parallelize किया जा सकता हैRust के traits की वजह से तेज़ और लचीली abstractions बनाई जा सकती हैं
C में macro या function pointers से इसकी नकल की जा सकती है, लेकिन Rust में caller dynamic dispatch या static dispatch चुन सकता है
embedded environments में function pointers cache को खराब कर देते हैं और performance घटाते हैं, जबकि Rust traits inline optimization की अनुमति देते हैं, इसलिए कहीं ज़्यादा efficient हैं
Rust हो या C, आख़िरकार सब कुछ byte level पर संभालना पड़ता है, और आजकल binary patching tools भी इतने बेहतर हो गए हैं कि उनका इस्तेमाल आसान है
Box<dyn Trait>लिखा जाए, तो caller पर dynamic dispatch थोपा जाता हैimpl Traitइस्तेमाल करने पर caller के पास विकल्प बचा रहता हैमेरी राय में Rust, C, और C++ लगभग एक ही low-level language family के हैं, इसलिए performance का अंतर बहुत मामूली है
Rust के strict aliasing rules optimization के लिए फ़ायदेमंद हैं, और C/C++ का UB(undefined behavior) performance के लिए मौजूद है
साथ ही Rust और C++ के generics C से कहीं ज़्यादा शक्तिशाली हैं, इसलिए उदाहरण के लिए
qsort()की जगह template-based sorting में inline optimization आसान होती हैमुझे लगता है भाषाओं के बीच ऐसी speed debates ज़्यादातर बेमानी होती हैं
भाषा से ज़्यादा compiler implementation performance तय करता है
Rust, C, और C++ तीनों low-level languages हैं, लेकिन “तेज़” का मतलब क्या है, यह महत्वपूर्ण है
क्या बात expert द्वारा optimize किए गए code की अधिकतम speed की हो रही है, या औसत developer के budget के भीतर तेज़ code लिख पाने की संभावना की—यह अलग बात है
लेकिन हाथ से optimization करने पर भाषा का अंतर लगभग गायब हो जाता है
फिर भी Rust को तेज़ code लिखना आसान बनाने वाली भाषा होने के कारण थोड़ा फ़ायदा है
मुझे लगता था Rust की सबसे बड़ी ताकत multithreading और stack allocation है
ownership model की वजह से C/C++ की तुलना में ज़्यादा चीज़ें stack पर रखी जा सकती हैं, जिससे malloc/free overhead कम होता है
ऐसे विषयों पर बहस अक्सर भावनात्मक हो जाती है, इसलिए ठोस आँकड़ों से ज़्यादा सोचने के तरीकों का अंतर सामने लाना उद्देश्य था
किसी भाषा की “speed” पर बात करते समय दो चीज़ें देखनी चाहिए
Rust और C में runtime checks लगभग नहीं के बराबर हैं, इसलिए वे Python या JS से तेज़ हैं
लेकिन Rust aliasing information को बेहतर ढंग से पहुँचाता है, इसलिए optimization की ज़्यादा गुंजाइश हो सकती है
debug mode में यह Ruby जितना धीमा हो सकता है, लेकिन release mode में C-स्तर की speed देता है
C की तुलना में C++ या Rust में compile-time features ज़्यादा समृद्ध हैं, इसलिए तेज़ code लिखना आसान होता है
उदाहरण के लिए यह code C में लगभग असंभव है
C में re2c जैसे external tools की ज़रूरत पड़ती है
assembly C standard का हिस्सा नहीं है, इसलिए उसकी Rust से सीधी तुलना करना मुश्किल है, और Rust की प्रकृति उल्टा GCC project के ज़्यादा क़रीब लगती है
कौन-सी भाषा “तेज़” है, यह अंततः implementation और context पर निर्भर करता है
भाषा की अपनी speed से ज़्यादा, compiler और hardware के संयोजन का असर होता है
औसतन कौन-सी भाषा सबसे तेज़ है, यह तो नहीं पता, लेकिन मेरा मानना है कि बिखराव C++ में सबसे ज़्यादा होगा।