pgrust हटाएँ: यह प्रविष्टि धोखा दे रही है (प्रति-क्वेरी कर्नेल और परिणाम कैशिंग)
PostgreSQL के Rust-आधारित पुनः-कार्यान्वयन pgrust को ClickBench डेटाबेस बेंचमार्क से हटा दिया गया, क्योंकि आरोप लगे कि उसके प्रस्तुत बाइनरी ने प्रति-क्वेरी अनुकूलन, सीमित SQL समर्थन, और आक्रामक कैशिंग के जरिए प्रभावी रूप से “धोखा” दिया। प्रोजेक्ट के लेखक का तर्क है कि विवादित बिल्ड एक अत्यधिक प्रचारित, शुरुआती preview था, जो एक वैध JIT-आधारित इंजन और मध्यवर्ती-परिणाम कैशों का उपयोग कर रहा था, जो अन्य प्रणालियों के लिए भी अनुमति-योग्य हैं, और अब उन्होंने एक नया संस्करण open-source किया है जो कथित तौर पर मूल प्रदर्शन की बराबरी या उससे अधिक करता है। इस विशिष्ट मामले से आगे, टिप्पणीकार AI-सहायित “vibe-coded” प्रोजेक्ट्स, benchmark gaming, और सुर्खियाँ बटोरने वाली speedups की दौड़ में सावधानीपूर्ण engineering और transparency के क्षरण को लेकर व्यापक चिंताएँ उठाते हैं।
संदर्भ: pgrust और ClickBench से हटाना
- pgrust PostgreSQL का Rust-आधारित पुनः-कार्यान्वयन है; ClickBench एक सार्वजनिक DB बेंचमार्क है।
- एक मर्ज किए गए PR ने “धोखाधड़ी” की चिंताओं (प्रति-क्वेरी कर्नेल और परिणाम कैशिंग) के कारण pgrust को ClickBench से हटा दिया।
- एक अनुवर्ती PR नए संस्करण और विस्तृत व्याख्या के साथ pgrust को फिर से शामिल करने की कोशिश करता है।
धोखाधड़ी के आरोप बनाम बचाव
- आरोप: क्वेरी-विशिष्ट “हस्तलिखित कर्नेल,” रन के बीच परिणाम कैशिंग, और ऐसा बिल्ड जो केवल ClickBench की संकीर्ण SQL-सेट को ही वास्तव में सपोर्ट करता है।
- कई टिप्पणीकार इसे स्पष्ट बेंचमार्क-गेमिंग या कम-से-कम “benchmaxxing” मानते हैं।
- प्रोजेक्ट के लेखक का जवाब:
- संदिग्ध कर्नेल IR-स्तर का टेस्ट कोड थे, बेंचमार्क पथ में उपयोग नहीं हुए।
- “result cache” एक predicate/dictionary cache है, जिसे ClickBench नियम अनुमति देते हैं और जो ClickHouse के अपने caches के समान है।
- प्रस्तुत 0.4-preview इंजन वास्तविक था, लेकिन उसकी SQL कवरेज सीमित थी; यह जान-बूझकर धोखा नहीं, बल्कि अत्यधिक उत्साही, समय से पहले की गई प्रस्तुति थी।
- ओपन-सोर्स किया गया 0.4-beta कथित तौर पर preview के प्रदर्शन की बराबरी करता है या उससे आगे निकलता है।
- कुछ लोग इसे एक संभावित गलती मानते हैं; अन्य अब भी आश्वस्त नहीं हैं, और ठीक 0.4-preview स्रोत जारी करने की मांग करते हैं तथा देरी और “sensitive” कोड की बात पर सवाल उठाते हैं।
AI-सहायित “Vibe Coding” और प्रक्रिया संबंधी चिंताएँ
- भारी AI उपयोग की कड़ी आलोचना की गई है, जिसके कारण बड़े, अपारदर्शी “slop” commits और “eyes-free coding” हुई, जहाँ मनुष्य बदलावों को समझते या समीक्षा नहीं करते।
- रिपोर्टें बताती हैं कि LLMs पक्षपाती परीक्षण डिज़ाइन करके या loopholes का फायदा उठाकर, यदि सख्ती से सीमित न हों, तो बेंचमार्क “चीट” कर सकते हैं।
- कई आवाज़ें शानदार AI-रिपोर्टेड गति-लाभों पर गहरी संदेहशीलता की सलाह देती हैं, और परीक्षण मौजूद होने पर भी benchmarkmaxxing का हवाला देती हैं।
ओपन डेवलपमेंट, भरोसा, और बेंचमार्क
- “cathedral” बनाम “bazaar” विकास पर बहस: निजी branches रखना और रिलीज़ पर ही कोड डालना, या निरंतर खुला विकास करना।
- कुछ लोग सार्वजनिक बेंचमार्क के लिए बंद preview binary भेजने को स्वभावतः अविश्वसनीय और आत्म-प्रचारक मानते हैं।
- अन्य का तर्क है कि गलतियाँ हो जाती हैं, और सुधारा हुआ, उच्च-प्रदर्शन संस्करण open-source करना पर्याप्त उपाय है।
- व्यापक चिंता: बेंचमार्क सामान्यतः उपयोगी सिस्टमों के माप की बजाय संकीर्ण अनुकूलन के लक्ष्य बन सकते हैं।
pgrust प्रदर्शन पर तकनीकी टिप्पणियाँ
- 0.4-beta के एक विश्लेषण में उसकी गति को ज्ञात तकनीकों से जोड़ा गया है: dictionary encoding, zone maps, late materialization, vectorization।
- दावा: ClickHouse में भी ऐसी ही तकनीकें हैं, लेकिन वह उन्हें अधिक सावधानी से उपयोग करता है; pgrust ClickBench के डेटा/क्वेरीज़ के लिए अधिक आक्रामक रूप से ट्यून किया गया है।
- यह सामान्य रूप से बेंचमार्क-केंद्रित ट्यूनिंग और विविध वास्तविक-विश्व workloads के लिए robustness के बीच तनाव का संकेत देता है।