Claude द्वारा बनाए गए C compiler की GCC से तुलना

• Anthropic के Claude Opus 4.6 द्वारा पूरी तरह लिखा गया CCC(Claude’s C Compiler) यह दावा करते हुए सार्वजनिक किया गया कि यह Linux kernel को compile कर सकता है
• Rust में लिखा गया standalone compiler, जिसमें frontend से linker तक सभी components सीधे implement किए गए हैं, लेकिन GCC की तुलना में performance और optimization quality काफी कम है
• SQLite और Linux kernel पर किए गए benchmark में CCC ने सभी C files को बिना error compile किया, लेकिन linker चरण में 40 हज़ार से अधिक reference errors के कारण build असफल रहा
• SQLite की execution performance अधिकतम 158,000 गुना धीमी थी, binary size 3 गुना से अधिक बड़ी थी, और optimization options (-O2 आदि) प्रभावहीन थे
• AI ने एक पूर्ण C compiler बनाया, यह तकनीकी रूप से महत्वपूर्ण है, लेकिन वास्तविक उपयोग के लिए आवश्यक efficiency और compatibility अभी भी अपर्याप्त है

---

CCC का अवलोकन और संरचना

• CCC, Anthropic द्वारा Claude का उपयोग करके बनाया गया पूरी तरह AI-लिखित C compiler है, जो x86-64, i686, AArch64, RISC-V 64 को support करता है
  • Rust में लिखा गया, इसमें SSA-आधारित IR, optimizer, code generator, assembler, linker, और DWARF debug information generation तक शामिल है
• इसमें compiler, assembler और linker की भूमिकाओं को अलग-अलग समझाया गया है, और linker को सबसे जटिल तथा error-प्रवण हिस्सा बताया गया है
• Linux kernel, GCC extensions और जटिल linker scripts का उपयोग करता है, इसलिए उसे शुरुआती test target के रूप में अनुपयुक्त माना गया; इसके बजाय SQLite को मुख्य benchmark चुना गया

टेस्ट वातावरण और विधि

• दो Debian-आधारित VM (6 vCPU, 16GB RAM) पर समान परिस्थितियों में GCC 14.2.0 और CCC की तुलना की गई
• तुलना के बिंदु: compile time, binary size, execution speed, memory usage, stability
• CCC ने gcc_m16 feature के जरिए केवल 16-bit boot code GCC को सौंपा, बाकी सब CCC ने संभाला
• SQLite benchmark CPU-केंद्रित रूप से डिज़ाइन किया गया था, जिसमें 42 SQL operations को 10 चरणों में चलाया गया

प्रमुख परिणामों का सार

• Linux kernel 6.9: CCC ने 2,844 C files सभी compile कर दीं, लेकिन linker चरण में 40,784 undefined reference errors के कारण असफल रहा
  • error का कारण: __jump_table, __ksymtab sections में गलत relocation और symbol generation
• SQLite compile: CCC, GCC से 1.3 गुना धीमा था, binary size 2.7~3 गुना, और memory usage 5.9 गुना थी
• SQLite execution performance: GCC -O0 की तुलना में 737 गुना, और -O2 की तुलना में 1,242 गुना धीमी
  • साधारण queries 1~7 गुना धीमी थीं, जबकि nested-loop queries अधिकतम 158,000 गुना धीमी थीं
• Crash tests के सभी 5 प्रकार पास हुए, यानी functional correctness सुनिश्चित हुई

प्रदर्शन गिरावट के कारण

• अत्यधिक register spilling: अधिकांश local variables को stack में store करने से memory access बहुत बढ़ गया
  • sqlite3VdbeExec function में 100 से अधिक variables stack पर संभाले गए, जिससे code length 3 गुना बढ़ गई
• Optimization options प्रभावहीन: -O0 और -O2 के परिणाम पूरी तरह समान थे; सभी levels पर 15 SSA passes एक जैसे चले
• Frame pointer corruption के कारण GDB debugging संभव नहीं थी
• Code size inflation: SQLite binary 4.27MB रही, जो GCC की तुलना में 2.78 गुना बड़ी थी, जिससे instruction cache misses बढ़ीं
• Symbol table का अभाव: internal function symbols न होने से profiling संभव नहीं थी

CCC की ताकत और सीमाएँ

• ताकत
  • Linux kernel की सभी C files को बिना error compile किया
  • SQLite के परिणामों में correctness और stability सुनिश्चित रही, segfault नहीं हुआ
  • GCC-compatible command-line interface support करता है
• सीमाएँ
  • execution speed में अत्यधिक गिरावट (अधिकतम 158,000 गुना)
  • linker incompatibility के कारण kernel build विफल
  • binary size और memory usage बहुत अधिक
  • optimization और debug information का अभाव, -O options प्रभावहीन
  • compile speed भी GCC से 25% धीमी

“Hello World” समस्या

• सार्वजनिक होने के तुरंत बाद “Hello world does not compile” issue सामने आया
  • stddef.h, stdarg.h नहीं मिलने के कारण preprocessing चरण में विफलता हुई
  • GitHub पर 288 से अधिक प्रतिक्रियाएँ और लगभग 200 comments आए, जिससे यह चर्चा का विषय बन गया
  • कुछ users ने इसे “undergraduate-level compiler assignment” जैसा बताया

निष्कर्ष

• CCC, इस बात का प्रमाण है कि AI एक पूर्ण C compiler बना सकता है
  • इसने Linux kernel की सभी C files को बिना error संभाला और SQLite को functional रूप से सही चलाया
• लेकिन वास्तविक उपयोग के लिए यह उपयुक्त नहीं है
  • execution performance बहुत खराब है, और linker, optimization, debugging features अधूरे हैं
• शोध उपलब्धि के रूप में यह महत्वपूर्ण है, लेकिन production-grade compiler के रूप में GCC, Clang जैसे मौजूदा tools अभी भी अनिवार्य हैं

[roxie]

अच्छा, तो Hello world does not compile मीम की शुरुआत यहीं से हुई थी lol

[fantajeon]

शुरुआत में इसका माहौल कुछ हद तक Go जैसा लगता है।

[chcv0313]

अगर इसे लगातार लूप में चलाकर सुधारते रहने को कहा जाए, तो क्या कभी न कभी इससे भी बेहतर compiler नहीं निकल आएगा?

[t7vonn]

लगता है कि इसे कम से कम undergraduate assignment level तक तो पहुँचा हुआ मानने में ही इसकी अहमियत है..

[GN⁺]

Hacker News की राय

• यह बहस LLM coding agents को लेकर पक्ष और विपक्ष, दोनों तरह के नज़रियों का अच्छा उदाहरण है
  समर्थक कहते हैं, “सिर्फ कुछ घंटों में काम करने वाला compiler बना दिया, यह चौंकाने वाला है,” जबकि विरोधी कहते हैं, “अगर वह सही से काम नहीं करता तो उसका कोई मतलब नहीं।”
  जैसे-जैसे codebase जटिल होता है, agent उतना कमज़ोर पड़ता दिखता है, और “अगली generation इसे ठीक कर देगी” जैसी बार-बार दोहराई जाने वाली बात पर भी संदेह है।
  Anthropic ने कहा था कि उसने Linux kernel compile किया, लेकिन वास्तव में वह असफल रहा, और इससे AI को लेकर बढ़ा-चढ़ाकर बनाई गई उम्मीदों और हक़ीक़त के बीच का फ़ासला सामने आता है।

  • इससे हाल की OCaml ‘vibe coded’ घटना याद आती है
    tests पास कर लेना और ऊपर-ऊपर से सही output दे देना, और code का maintenance योग्य quality वाला होना — ये दोनों बिल्कुल अलग बातें हैं।
  • हर बार जब “अगली generation का model सब ठीक कर देगा” वाली दलील दोहराई जाती है, तो झुंझलाहट होती है।
  • शायद “sufficiently smart LLM” नाम का एक C2 wiki page होना चाहिए।
  • यह बहस कुछ हद तक SpaceX की प्रगति जैसी लगती है
    पहले कहा गया “सिर्फ छोटे functions लिख सकता है”, फिर “Linux compile नहीं कर सकता”, फिर “GCC स्तर तक नहीं पहुँचता” — इस तरह लक्ष्य-रेखा लगातार खिसकती रही।
    लेकिन प्रगति की रफ़्तार देखें तो लगता है कि कुछ compiler engineers जोड़ दिए जाएँ, तो यह तेज़ी से बराबरी कर सकता है।
  • C compiler, 50 साल में जमा हुए code का नतीजा है।
    इसलिए LLM सचमुच पूरी तरह नई समस्याएँ हल कर सकता है या नहीं, इस पर अभी भी सवाल है।

• Anthropic ने blog में कहा था कि x86 पर भी Linux kernel boot हुआ, लेकिन वास्तव में सिर्फ RISC-V सफल हुआ लगता है।
  official post में x86/ARM/RISC-V तीनों के काम करने की बात कही गई,
  लेकिन repo docs में सिर्फ RISC-V test का ज़िक्र है।

  • शायद CCC, static keys या DKMS जैसी चीज़ें disable करने पर काम कर सके।

• unoptimized C में performance गिरावट का स्तर देखना दिलचस्प है।
  SQLite3 build में CCC 12 गुना धीमा है, और optimized version 20 गुना धीमा है।
  यह दिखाता है कि GCC ने optimization के मामले में कितनी बड़ी उपलब्धि हासिल की है।

  • C की speed आज भी hardware से उसके सीधे रिश्ते की वजह से आती है।
    लेकिन अगर compiler में register shuffling बहुत ज़्यादा हो, तो यह रिश्ता टूट जाता है और प्रदर्शन Python जैसा लगने लगता है।
  • TCC जैसे low-optimization compiler भी CCC से काफ़ी तेज़ हैं।
    CCC का -O0 से भी धीमा होना अप्रत्याशित था।

• सिर्फ इसलिए कि CCC ने kernel की सभी C files बिना error के compile कर दीं, यह नहीं मान लेना चाहिए कि उसने सही output दिया।
  सिर्फ SQLite tests पास कर लेना काफ़ी नहीं है।

  • error न आना, सही compile होने का प्रमाण नहीं है। /dev/null में भेजने पर भी error नहीं आता।
  • LinkedIn पर देखी गई एक पोस्ट के मुताबिक, CCC const को नज़रअंदाज़ करता है, और type redefinition या गलत conversion को भी ऐसे ही पास कर देता है।
    यानी “tests पास कराना” लक्ष्य पाने के लिए उसने invalid code को भी compile कर देने वाली चाल अपनाई।

• कुछ लेखों में कहा गया कि “compiler सबसे आसान चरण है,” लेकिन असल में linker सबसे जटिल हिस्सा है।
  x86-64 की हज़ारों instruction encodings, ELF का बारीक layout वगैरह AI के लिए संभालना कठिन है।

  • इसका जवाब यह भी दिया गया कि linking ज़्यादा नियम लागू करने जैसा काम है, और assembler ज़्यादा pattern matching जैसा।
    साथ ही, “1 iteration में 4 गुना धीमा → 1 अरब iterations में 158,000 गुना धीमा” जैसी गणना का कोई मतलब नहीं बनता।
  • किसी ने कहा कि Claude ने उसके लिए x86 assembler और linker एक साथ बना दिया था।
    कई instructions गायब थे, लेकिन बात बस data tables भरने तक की रह गई थी।
  • मेरी जानकारी में Anthropic ने compiler बनाया था, linker नहीं।

• यह हैरान करने वाला है कि इंसानों की expectations कितनी जल्दी बदल जाती हैं।
  5 साल पहले तक “AI अंग्रेज़ी prompt से C compiler बना देगा” जैसी बात बेहद बेतुका मज़ाक लगती।

  • लेकिन यह भी सोचना चाहिए कि वह code मौजूदा compilers के source पर कितना निर्भर था।
  • अगर ऐसा नतीजा बिना संदर्भ के सामने आता, तो शायद यह असल में जटिल copy-pasta ही होता।
  • यह प्रगति निश्चित रूप से चौंकाने वाली है, लेकिन इसके आधार पर AGI के आने की भविष्यवाणी करना जल्दबाज़ी में सामान्यीकरण है।
  • अंततः यह बस Overton window के खिसकने जैसा लगता है।
  • हाँ, लेकिन अरबों डॉलर की training cost और पूरे internet पर training होने वाली बात को नज़रअंदाज़ नहीं किया जा सकता।

• HN का अतिरंजित निंदक रवैया समझ नहीं आता।
  तीन architectures को target करने वाला C compiler बनाना इंसानों के लिए भी कठिन है,
  और SQLite पास कर लेने भर का स्तर भी weekend project के हिसाब से बड़ी उपलब्धि है।
  ज़्यादातर कंपनियाँ high-performance compiler नहीं, बल्कि business logic के लिए code glue बनाती हैं — हक़ीक़त यही है।
  समस्या तकनीक से ज़्यादा उसे इस्तेमाल करने वालों के रवैये में है।

  • लेकिन $20k token cost और कई लोगों की भागीदारी को देखें, तो “weekend project” कहना बढ़ा-चढ़ाकर बोलना है।
  • CCC का errors नज़रअंदाज़ करके compile कर देना, और SQLite tests भी पूरी तरह ठोस न होना, गंभीर समस्या है।
  • LLM से बना code ठीक करना मुश्किल होता है, और उसका ढाँचा भुरभुरा होता है — इस अर्थ में इसकी सीमाएँ अब भी हैं।
  • आखिरकार समस्या तकनीक नहीं, बल्कि AI की उपलब्धियों को बढ़ा-चढ़ाकर पेश करने वाले लोग हैं।
  • “sour grapes” वाला मुहावरा इस संदर्भ में ठीक नहीं बैठता।

• SQLite में 158,000 गुना धीमा प्रदर्शन ही असली मुद्दा है।
  parsing आसान समस्या है; असली कठिनाई register allocation और optimization stage में है।
  GCC से तुलना करना बेमानी है, लेकिन LLM का ऐसा compiler बना देना अपने आप में चौंकाने वाली बात है।
  अगला लक्ष्य GCC से अंतर को 158,000 गुना से घटाकर 100 गुना के स्तर तक लाना होना चाहिए।

  • लेकिन इस संख्या-गणना पर भरोसा करना मुश्किल है।
    अगर हर iteration 12 गुना धीमा है, तो कुल भी 12 गुना धीमा होना चाहिए; 158,000 गुना वाली संख्या गलती या गलतफ़हमी लगती है।
    SQLite test सच में सही तरह चल रहा है या नहीं, इस पर भी पर्याप्त पुष्टि नहीं है।
  • संभव है कि LLM ने GCC या Clang के source code पर training ली हो।
    फिर भी performance इतनी कम होना सवाल पैदा करता है।
  • यह भी कहा गया कि C parsing सोचे से ज़्यादा कठिन है।
    संदर्भ के लिए यह लेख देखें: C पूरी तरह parse की जा सकने वाली भाषा नहीं है।

• जैसे यह कहा गया, “अगर 1 iteration 8 गुना धीमा है, तो 1 अरब बार दोहराने पर भी वह सिर्फ 8 गुना ही धीमा रहेगा,”
  उसी तरह 158,000 गुना वाली संख्या तार्किक रूप से सही नहीं लगती।
  शायद register spilling ने L3 cache पर भारी दबाव डाला हो, या फिर कोई bug हो जिसकी वजह से बेकार का code चल रहा हो।

  • GCC version का 0.047 सेकंड में ख़त्म होना देखें, तो “1 अरब iterations” वाला दावा भी भरोसेमंद नहीं लगता।

• C compiler बनाना इंसानों के लिए भी कठिन है,
  लेकिन इसे LLM की बुद्धिमत्ता का प्रमाण मानना मुश्किल है।
  यह पहले से अच्छी तरह जाना हुआ problem है, और इसकी ढेरों implementations और documentation training data में शामिल रही होंगी।
  यानी LLM ने कोई नई design नहीं बनाई, बल्कि मौजूदा patterns को फिर से जोड़ा है।
  फिर भी ऐसे tools उपयोगी हैं,
  और सच में प्रभावशाली क्षण वह होगा जब model मौजूदा OSS की नकल करने के बजाय नई approaches पेश करेगा।