Perbandingan kompiler C buatan Claude dengan GCC

• CCC (Claude’s C Compiler) yang sepenuhnya ditulis oleh Claude Opus 4.6 dari Anthropic dirilis dengan klaim dapat mengompilasi kernel Linux
• Sebagai kompiler mandiri yang ditulis dalam Rust, semua komponen dari frontend hingga linker diimplementasikan sendiri, tetapi kinerjanya dan kualitas optimisasinya jauh tertinggal dibandingkan GCC
• Dalam benchmark terhadap SQLite dan kernel Linux, CCC berhasil mengompilasi semua file C tanpa error, tetapi build gagal pada tahap linker karena lebih dari 40 ribu error undefined reference
• Performa eksekusi SQLite hingga 158.000 kali lebih lambat, ukuran biner lebih dari 3 kali lebih besar, dan opsi optimisasi (-O2 dan sebagainya) tidak efektif
• Fakta bahwa AI menghasilkan kompiler C yang lengkap memang bermakna secara teknis, tetapi efisiensi dan kompatibilitas yang layak untuk penggunaan nyata masih belum tercapai

---

Gambaran umum dan struktur CCC

• CCC adalah kompiler C yang sepenuhnya ditulis AI oleh Anthropic menggunakan Claude, dengan dukungan untuk x86-64, i686, AArch64, RISC-V 64
  • Ditulis dalam Rust, mencakup IR berbasis SSA, optimizer, code generator, assembler, linker, hingga pembuatan informasi debug DWARF
• Artikel ini menjelaskan pemisahan peran kompiler, assembler, dan linker, serta menyebut linker sebagai bagian paling kompleks dan paling berisiko memunculkan error
• Karena kernel Linux memakai ekstensi GCC dan linker script yang kompleks, kernel dinilai kurang cocok sebagai target pengujian awal, sehingga SQLite dipilih sebagai benchmark utama

Lingkungan dan metode pengujian

• GCC 14.2.0 dan CCC dibandingkan dalam kondisi yang sama pada dua VM berbasis Debian (6 vCPU, RAM 16GB)
• Item perbandingan: waktu kompilasi, ukuran biner, kecepatan eksekusi, penggunaan memori, stabilitas
• CCC menggunakan fitur gcc_m16 untuk mendelegasikan hanya kode boot 16-bit ke GCC, sementara sisanya diproses oleh CCC
• Benchmark SQLite dirancang berfokus pada CPU, menjalankan 42 operasi SQL dalam 10 tahap

Ringkasan hasil utama

• Kernel Linux 6.9: CCC berhasil mengompilasi seluruh 2.844 file C, tetapi gagal pada tahap linker dengan 40.784 error undefined reference
  • Penyebab error: relocation yang salah dan pembuatan simbol yang keliru pada section __jump_table dan __ksymtab
• Kompilasi SQLite: CCC 1,3 kali lebih lambat daripada GCC, ukuran biner 2,7~3 kali lebih besar, penggunaan memori 5,9 kali lebih tinggi
• Performa eksekusi SQLite: 737 kali lebih lambat dibanding GCC -O0, dan 1.242 kali lebih lambat dibanding -O2
  • Query sederhana 1~7 kali lebih lambat, sedangkan query nested loop hingga 158.000 kali lebih lambat
• Lolos semua 5 jenis crash test, menunjukkan akurasi fungsional telah tercapai

Penyebab penurunan performa

• Register spilling berlebihan: sebagian besar variabel lokal disimpan ke stack sehingga akses memori meningkat drastis
  • Pada fungsi sqlite3VdbeExec, lebih dari 100 variabel diproses melalui stack, dan panjang kode meningkat 3 kali lipat
• Opsi optimisasi tidak efektif: hasil -O0 dan -O2 benar-benar identik, dengan 15 pass SSA yang berjalan sama pada semua level
• Frame pointer rusak, sehingga debugging dengan GDB tidak memungkinkan
• Pembengkakan ukuran kode: biner SQLite berukuran 4,27MB, 2,78 kali lebih besar dibanding GCC, sehingga instruction cache miss meningkat
• Tabel simbol tidak dibuat: tidak ada simbol fungsi internal sehingga profiling tidak memungkinkan

Kekuatan dan keterbatasan CCC

• Kekuatan
  • Berhasil mengompilasi semua file C pada kernel Linux tanpa error
  • Menjamin akurasi dan stabilitas hasil SQLite, tanpa segfault
  • Mendukung antarmuka baris perintah yang kompatibel dengan GCC
• Keterbatasan
  • Kecepatan eksekusi turun secara ekstrem (hingga 158.000 kali)
  • Build kernel gagal karena ketidakcocokan linker
  • Ukuran biner dan penggunaan memori berlebihan
  • Tidak ada optimisasi dan informasi debug, opsi -O tidak efektif
  • Kecepatan kompilasi juga 25% lebih lambat daripada GCC

Masalah “Hello World”

• Segera setelah dirilis, muncul isu “Hello world does not compile”
  • Gagal pada tahap preprocessing karena tidak dapat menemukan stddef.h dan stdarg.h
  • Menjadi topik hangat di GitHub dengan lebih dari 288 reaksi dan sekitar 200 komentar
  • Sebagian pengguna menilai ini “terlihat seperti tugas kompiler tingkat mahasiswa S1”

Kesimpulan

• CCC adalah kasus pembuktian bahwa AI dapat menghasilkan kompiler C yang lengkap
  • Berhasil memproses semua file C pada kernel Linux tanpa error dan menjalankan SQLite dengan benar secara fungsional
• Namun, tidak cocok untuk penggunaan nyata
  • Performa eksekusinya sangat rendah, dan fitur linker, optimisasi, serta debugging masih belum matang
• Sebagai pencapaian riset ini bermakna, tetapi untuk kompiler produksi, alat yang ada seperti GCC dan Clang tetap esensial

[roxie]

Oh, jadi asal-usul meme "Hello world does not compile" ada di sini ya wkwk

[fantajeon]

Awalnya suasananya mirip seperti Go.

[chcv0313]

Kalau terus disuruh memperbaikinya dalam loop, bukankah pada akhirnya akan muncul compiler yang lebih unggul?

[t7vonn]

Sepertinya pencapaian yang patut diapresiasi adalah bahwa ini sudah mencapai level tugas mahasiswa S1..

[GN⁺]

Opini Hacker News

• Perdebatan ini menunjukkan dengan jelas sudut pandang pro dan kontra terhadap agen coding LLM
  Pihak yang mendukung berkata, “menakjubkan bisa membuat compiler yang berjalan hanya dalam beberapa jam”, sementara pihak yang menolak berkata, “kalau tidak benar-benar bekerja, itu tidak berarti”
  Ada skeptisisme bahwa semakin kompleks codebase-nya, semakin lemah agen tersebut, dan terhadap klaim berulang bahwa “generasi berikutnya akan memperbaikinya”
  Anthropic mengatakan telah mengompilasi kernel Linux, tetapi kenyataannya gagal, yang memperlihatkan kesenjangan antara ekspektasi AI yang dibesar-besarkan dan realitas

  • Ini mengingatkan pada insiden OCaml ‘vibe coded’ baru-baru ini
    Lulus pengujian dan menghasilkan output yang tampak benar sama sekali berbeda dengan kode yang memiliki kualitas yang dapat dipelihara
  • Setiap kali logika “model generasi berikutnya akan memperbaiki semuanya” diulang, rasanya menjengkelkan
  • Mungkin kita butuh halaman wiki C2 tentang “sufficiently smart LLM”
  • Perdebatan ini terasa seperti melihat proses perkembangan SpaceX
    Awalnya “hanya bisa menulis fungsi kecil”, lalu “tidak bisa mengompilasi Linux”, lalu “belum setara GCC”, sehingga standar terus bergeser
    Namun melihat kecepatan perkembangannya, rasanya cukup menambahkan beberapa insinyur compiler untuk bisa cepat menyusul
  • Compiler C adalah hasil dari akumulasi kode selama 50 tahun
    Karena itu, masih diragukan apakah LLM benar-benar bisa menyelesaikan masalah yang sepenuhnya baru

• Anthropic menulis di blog bahwa kernel Linux juga bisa boot di x86, tetapi tampaknya hanya RISC-V yang benar-benar berhasil
  Posting resmi mengatakan x86/ARM/RISC-V semuanya berhasil,
  tetapi dokumentasi repo hanya mencantumkan pengujian RISC-V

  • Mungkin CCC bisa berjalan jika static keys atau DKMS dinonaktifkan

• Menarik melihat besarnya penurunan performa pada C yang tidak dioptimalkan
  Pada build SQLite3, CCC 12 kali lebih lambat, dan versi yang dioptimalkan 20 kali lebih lambat
  Ini menunjukkan betapa besarnya hasil optimisasi yang dicapai GCC

  • Kecepatan C masih berasal dari sifat bahasa yang terhubung langsung dengan hardware
    Tetapi compiler dengan register shuffling yang parah kehilangan keterkaitan itu dan terasa seperti Python
  • Compiler dengan optimisasi rendah seperti TCC pun jauh lebih cepat daripada CCC
    Cukup mengejutkan bahwa CCC bahkan lebih lambat daripada -O0

• Hanya karena CCC mengompilasi semua file C kernel tanpa error bukan berarti hasilnya normal atau benar
  Sekadar lulus pengujian SQLite tidaklah cukup

  • Tidak adanya error bukan berarti kompilasinya benar. Mengirim ke /dev/null juga tidak menghasilkan error
  • Menurut tulisan yang terlihat di LinkedIn, CCC mengabaikan const, dan juga membiarkan redefinisi tipe atau konversi yang salah
    Dengan kata lain, demi target “lulus pengujian”, ia memakai trik dengan mengompilasi kode yang tidak valid

• Ada tulisan yang mengatakan “compiler adalah tahap termudah”, tetapi kenyataannya linker adalah bagian yang paling rumit
  Ribuan encoding instruksi x86-64 dan detail layout ELF adalah hal yang sulit ditangani AI

  • Ada juga bantahan bahwa proses linking lebih mirip penerapan aturan, sedangkan assembler lebih mirip pattern matching
    Selain itu, perhitungan seperti “1 iterasi 4 kali lebih lambat → 1 miliar iterasi 158.000 kali lebih lambat” tidak masuk akal
  • Ada juga orang yang mengatakan Claude membuat x86 assembler dan linker sekaligus untuknya
    Banyak instruksi memang masih hilang, tetapi katanya cukup sampai level tinggal mengisi tabel data
  • Setahu saya, yang dibuat Anthropic hanyalah compiler, bukan sampai linker

• Mengejutkan melihat betapa cepatnya ekspektasi manusia berubah
  Lima tahun lalu, mengatakan “AI membuat compiler C dari prompt bahasa Inggris” akan terdengar seperti lelucon yang absurd

  • Tetapi perlu juga dipikirkan seberapa besar kode itu bergantung pada source compiler yang sudah ada
  • Jika hasil seperti ini muncul tanpa konteks, kemungkinan besar pada dasarnya hanyalah copy-pasta yang kompleks
  • Perkembangan seperti ini memang mengagumkan, tetapi menjadikannya dasar untuk memprediksi kedatangan AGI adalah generalisasi yang tergesa-gesa
  • Pada akhirnya, saya rasa ini hanya menunjukkan bahwa Overton window telah bergeser
  • Tetap saja, fakta bahwa model ini dilatih dengan biaya miliaran dolar dan pada keseluruhan internet tidak bisa diabaikan

• Saya tidak paham dengan sinisme berlebihan di HN
  Membuat compiler C untuk tiga arsitektur juga sulit bagi manusia, dan
  bahkan jika hanya sampai level lulus SQLite, itu tetap pencapaian besar untuk proyek sekelas akhir pekan
  Kebanyakan perusahaan pada kenyataannya tidak membuat compiler berperforma tinggi, melainkan lem kode untuk logika bisnis
  Masalahnya bukan pada teknologinya sendiri, melainkan pada sikap orang yang menggunakannya

  • Namun jika mempertimbangkan biaya token $20k dan keterlibatan beberapa orang, menyebutnya “proyek akhir pekan” jelas berlebihan
  • Fakta bahwa CCC mengabaikan error saat mengompilasi, dan bahkan pengujian SQLite pun tidak lengkap, adalah masalah serius
  • Kode buatan LLM masih sulit diperbaiki dan tetap memiliki keterbatasan karena struktur yang rapuh
  • Pada akhirnya, masalahnya bukan teknologinya, melainkan orang-orang yang membesar-besarkan capaian AI
  • Ungkapan “sour grapes” juga terasa tidak cocok dalam konteks ini

• Performa 158.000 kali lebih lambat di SQLite adalah inti persoalannya
  Parsing adalah masalah yang mudah; yang benar-benar sulit adalah tahap alokasi register dan optimisasi
  Membandingkannya dengan GCC memang tidak terlalu bermakna, tetapi fakta bahwa LLM membuat compiler seperti ini sendiri sudah mengejutkan
  Target berikutnya adalah mengurangi selisih dengan GCC dari 158.000 kali menjadi sekitar 100 kali

  • Namun perhitungan angka ini sulit dipercaya
    Jika tiap iterasi 12 kali lebih lambat, totalnya juga seharusnya 12 kali lebih lambat; jadi 158.000 kali tampak seperti kesalahan atau salah paham
    Verifikasinya juga kurang apakah pengujian SQLite benar-benar berjalan dengan benar
  • Ada kemungkinan besar LLM telah mempelajari source code GCC atau Clang
    Meski begitu, tetap aneh jika performanya serendah ini
  • Ada juga pendapat bahwa parsing C lebih sulit dari yang dibayangkan
    Tulisan C bukan bahasa yang sepenuhnya dapat di-parse layak dijadikan referensi

• Seperti kritik bahwa “jika 1 iterasi 8 kali lebih lambat, maka 1 miliar kali iterasi tetap hanya 8 kali lebih lambat”,
  angka 158.000 kali itu secara logis tidak masuk akal
  Mungkin register spilling membanjiri cache L3, atau ada bug yang membuat kode tak perlu ikut dieksekusi

  • Melihat versi GCC selesai hanya dalam 0,047 detik, klaim “1 miliar iterasi” juga sulit dipercaya

• Membuat compiler C memang sulit bahkan bagi manusia,
  tetapi sulit menganggap ini sebagai bukti kecerdasan LLM
  Ini adalah masalah yang sudah sangat dikenal, dan banyak implementasi serta dokumentasinya sudah ada dalam data pelatihan
  Dengan kata lain, LLM tidak menciptakan desain baru, melainkan menggabungkan ulang pola yang sudah ada
  Meski begitu, alat seperti ini tetap berguna, dan
  yang benar-benar mengesankan nantinya bukanlah model yang menyalin OSS yang ada, melainkan model yang menawarkan pendekatan baru