Claude tarafından üretilen C derleyicisinin GCC ile karşılaştırması

• Anthropic’in Claude Opus 4.6 modeli tarafından tamamen yazıldığı belirtilen CCC (Claude’s C Compiler), Linux çekirdeğini derleyebildiği iddiasıyla yayımlandı
• Rust ile yazılmış bağımsız bir derleyici olan proje, frontend’den linker’a kadar tüm bileşenleri doğrudan uyguluyor; ancak GCC’ye kıyasla performans ve optimizasyon kalitesi belirgin biçimde düşük
• SQLite ve Linux çekirdeği üzerinde yapılan benchmark’larda CCC tüm C dosyalarını hatasız derledi, ancak linker aşamasında 40 binden fazla referans hatası nedeniyle derleme başarısız oldu
• SQLite çalışma performansı en fazla 158.000 kat daha yavaş, ikili dosya boyutu ise 3 kattan fazla büyük; ayrıca optimizasyon seçenekleri (-O2 vb.) etkisiz
• Yapay zekanın tam teşekküllü bir C derleyicisi üretmiş olması teknik açıdan anlamlı olsa da, gerçek kullanım için gerekli verimlilik ve uyumluluk seviyesi henüz yakalanmış değil

---

CCC’ye genel bakış ve mimarisi

• CCC, Anthropic’in Claude’u kullanarak oluşturduğu tamamen yapay zeka tarafından yazılmış bir C derleyicisi ve x86-64, i686, AArch64, RISC-V 64 desteği sunuyor
  • Rust ile yazılmış; SSA tabanlı IR, optimizer, code generator, assembler, linker ve DWARF debug bilgisi üretimi dahil
• Metinde derleyici, assembler ve linker rollerinin ayrımı anlatılıyor ve en karmaşık, hata üretmeye en açık bileşenin linker olduğu belirtiliyor
• Linux çekirdeği GCC uzantıları ve karmaşık linker script’leri kullandığı için ilk test hedefi olarak uygun görülmemiş; bunun yerine ana benchmark olarak SQLite seçilmiş

Test ortamı ve yöntem

• Aynı koşullardaki iki Debian tabanlı VM’de (6 vCPU, 16GB RAM) GCC 14.2.0 ile CCC karşılaştırıldı
• Karşılaştırma ölçütleri: derleme süresi, ikili dosya boyutu, çalışma hızı, bellek kullanımı, kararlılık
• CCC, gcc_m16 özelliği ile yalnızca 16 bit boot kodunu GCC’ye devrediyor, geri kalan kısmı CCC işliyor
• SQLite benchmark’ı CPU ağırlıklı olacak şekilde tasarlanmış ve 42 SQL işlemi 10 aşamada yürütülmüş

Başlıca sonuçların özeti

• Linux çekirdeği 6.9: CCC, 2.844 C dosyasının tamamını derledi ancak linker aşamasında 40.784 adet undefined reference hatası nedeniyle başarısız oldu
  • Hatanın nedeni: __jump_table, __ksymtab bölümlerinde yanlış relocation ve sembol üretimi
• SQLite derleme: CCC, GCC’den 1,3 kat daha yavaş; ikili dosya boyutu 2,7~3 kat, bellek kullanımı 5,9 kat
• SQLite çalışma performansı: GCC -O0’a kıyasla 737 kat, -O2’ye kıyasla 1.242 kat daha yavaş
  • Basit sorgular 1~7 kat, iç içe döngülü sorgular ise en fazla 158.000 kat daha yavaş
• Crash testi türlerinin 5’ini de geçti; işlevsel doğruluk sağlandı

Performans düşüşünün nedenleri

• Aşırı register spilling: yerel değişkenlerin çoğu stack üzerinde tutulduğu için bellek erişimi aşırı artıyor
  • sqlite3VdbeExec fonksiyonunda 100’den fazla değişken stack üzerinden işleniyor, kod uzunluğu 3 kat artıyor
• Optimizasyon seçenekleri etkisiz: -O0 ve -O2 sonuçları tamamen aynı; 15 SSA pass’i tüm seviyelerde aynı şekilde çalışıyor
• Frame pointer bozulması nedeniyle GDB ile debug yapılamıyor
• Kod boyutu şişmesi: SQLite ikilisi 4.27MB ile GCC’ye göre 2,78 kat daha büyük, bu da instruction cache miss oranını artırıyor
• Sembol tablosu üretilmiyor: iç fonksiyon sembolleri olmadığından profiling yapılamıyor

CCC’nin güçlü yönleri ve sınırları

• Güçlü yönleri
  • Linux çekirdeğinin tüm C dosyalarını hatasız derleyebilmesi
  • SQLite sonuçlarında doğruluk ve kararlılığın sağlanması, segfault olmaması
  • GCC uyumlu komut satırı arayüzü desteği
• Sınırları
  • Çalışma hızında aşırı düşüş (en fazla 158.000 kat)
  • Linker uyumsuzluğu nedeniyle çekirdek derlemesinin başarısız olması
  • Aşırı ikili boyutu ve bellek kullanımı
  • Optimizasyon ve debug bilgisinin eksikliği, -O seçeneklerinin etkisiz olması
  • Derleme hızı da GCC’ye göre %25 daha yavaş

“Hello World” sorunu

• Yayımlanmasının hemen ardından “Hello world does not compile” sorunu ortaya çıktı
  • stddef.h, stdarg.h bulunamadığı için preprocessing aşamasında başarısız oldu
  • GitHub’da 288’den fazla tepki ve 200’ün üzerinde yorum alarak gündem oldu
  • Bazı kullanıcılar bunu “lisans düzeyinde bir derleyici ödevi gibi” diye değerlendirdi

Sonuç

• CCC, yapay zekanın tam teşekküllü bir C derleyicisi üretebildiğini gösteren bir örnek
  • Linux çekirdeğinin tüm C dosyalarını hatasız işliyor ve SQLite’ı işlevsel olarak doğru şekilde çalıştırıyor
• Ancak gerçek kullanım için uygun değil
  • Çalışma performansı son derece düşük ve linker, optimizasyon, debugging işlevleri tamamlanmamış durumda
• Araştırma açısından anlamlı bir başarı olsa da, pratik kullanım için GCC, Clang gibi mevcut araçlar hâlâ vazgeçilmez

[roxie]

Hello world does not compile mem'inin kaynağı burasıymış demek, haha

[fantajeon]

İlk başta biraz Go havasına benziyor.

[chcv0313]

Sürekli döngüye sokup düzeltmesini söylerseniz, günün birinde daha üstün bir derleyici çıkmaz mı?

[t7vonn]

Sanırım bunu, lisans öğrencisi ödevi seviyesine kadar ulaşmış olmasına verilen bir anlam olarak görmek gerek..

[GN⁺]

Hacker News görüşleri

• Bu tartışma, LLM kodlama ajanları hakkındaki hem olumlu hem olumsuz bakışları iyi gösteren bir örnek. Destekleyenler “birkaç saat içinde çalışan bir derleyici yaptı, inanılmaz” derken, karşı çıkanlar “çalışmıyorsa bir anlamı yok” diyor. Kod tabanı karmaşıklaştıkça ajanların daha da zayıflaması ve “bir sonraki nesil düzeltir” şeklindeki tekrarlayan iddialar şüpheyle karşılanıyor. Anthropic Linux çekirdeğini derlediğini söyledi ama gerçekte başarısız oldu; bu da yapay zekaya dair abartılı beklentilerle gerçeklik arasındaki farkı ortaya koyuyor.

  • Bu durum yakın zamandaki OCaml ‘vibe coded’ olayı'nı hatırlatıyor. Testleri geçmek ve dışarıdan doğru görünen çıktı üretmek ile, o kodun bakımı yapılabilir bir kaliteye sahip olması tamamen farklı şeyler.
  • “Sonraki nesil model her şeyi düzeltecek” mantığı her tekrarlandığında sinir bozucu oluyor.
  • Belki de “sufficiently smart LLM” için bir C2 wiki sayfası gerekecek.
  • Bu tartışma biraz SpaceX’in gelişim sürecini izlemek gibi. Önce “yalnızca küçük fonksiyonlar yazabiliyor”, sonra “Linux’u derleyemiyor”, ardından da “GCC seviyesinde değil” denerek çıta sürekli kaydırılıyor. Ama ilerleme hızına bakınca, birkaç derleyici mühendisi eklense bile hızla arayı kapatacakmış gibi görünüyor.
  • C derleyicisi, 50 yıl boyunca birikmiş kodun ürünü. Bu yüzden LLM’lerin gerçekten tamamen yeni problemleri çözebileceği hâlâ kuşkulu.

• Anthropic blogunda x86 üzerinde de Linux çekirdeğinin açıldığını söylemişti, ama gerçekte yalnızca RISC-V başarılı olmuş gibi görünüyor. Resmi gönderi'de x86/ARM/RISC-V’nin hepsinin çalıştığı söylense de, repo dokümanında yalnızca RISC-V testi var.

  • Muhtemelen CCC, static keys ya da DKMS gibi özellikler devre dışı bırakılırsa çalışabilir.

• Optimize edilmemiş C’nin performans kaybı ilginç bulunuyor. SQLite3 derlemesinde CCC 12 kat, optimize sürüm ise 20 kat daha yavaş. Bu da GCC’nin ne kadar büyük bir optimizasyon başarısı sunduğunu gösteriyor.

  • C’nin hızı hâlâ donanımla doğrudan bağlantılı olan dil özelliklerinden geliyor. Ama register shuffle’ı aşırı olan bir derleyici bu bağı kaybedip Python gibi hissettiriyor.
  • TCC gibi düşük optimizasyonlu derleyiciler bile CCC’den çok daha hızlı. CCC’nin -O0'dan bile yavaş olması şaşırtıcı bulundu.

• CCC’nin çekirdekteki tüm C dosyalarını hatasız derlemiş olması, normal bir çıktı ürettiği anlamına gelmiyor. Sadece SQLite testlerini geçmek yeterli değil.

  • Hata çıkmaması, derlemenin doğru olduğu anlamına gelmez. /dev/null'a gönderince de hata çıkmaz.
  • LinkedIn’de görülen bir paylaşıma göre CCC, const'u yok sayıyor, tür yeniden tanımlarını ya da hatalı dönüşümleri de olduğu gibi geçiriyor. Yani “testleri geçmek” hedefi uğruna geçersiz kodu bile derleyen bir hile kullanmış sayılıyor.

• Bazı yazılarda “derleyici en kolay aşama” denmiş olsa da, gerçekte en karmaşık bölüm bağlayıcı. x86-64’ün binlerce komut kodlaması, ELF’in ayrıntılı düzeni gibi konular yapay zekanın başa çıkması zor alanlar.

  • Buna karşı çıkanlar, bağlama sürecinin daha çok kural uygulamaya, assembler’ın ise desen eşleştirmeye benzediğini söylüyor. Ayrıca “1 iterasyonda 4 kat yavaşsa, 1 milyar iterasyonda 158.000 kat yavaş olur” hesabının da mantıksız olduğu belirtiliyor.
  • Claude’un x86 assembler ve bağlayıcıyı tek seferde oluşturduğunu söyleyen biri de var. Eksik komut çoktu ama yalnızca veri tablolarını doldurmak yeterli olacak düzeydeymiş.
  • Anthropic’in yaptığı şeyin yalnızca derleyici olduğu, bağlayıcıyı kapsamadığı da söyleniyor.

• İnsanların beklentilerinin ne kadar hızlı değiştiği şaşırtıcı. 5 yıl önce “yapay zeka İngilizce prompt ile C derleyicisi yapıyor” demek akıl dışı bir şaka gibi gelirdi.

  • Ama o kodun mevcut derleyicilerin kaynak koduna ne kadar bağımlı olduğu da düşünülmeli.
  • Böyle bir sonuç bağlam olmadan ortaya çıktıysa, aslında karmaşık bir copy-pasta olma ihtimali de var.
  • Bu ilerleme etkileyici olsa da, buradan AGI’nin geldiği sonucunu çıkarmak aceleci bir genelleme olur.
  • Sonuçta sadece Overton window kaymış olabilir.
  • Yine de onlarca milyar dolarlık eğitim maliyetini ve tüm internetin eğitim verisi olarak kullanıldığını göz ardı etmek mümkün değil.

• HN’deki aşırı sinizmi anlamak zor. Üç mimariyi hedefleyen bir C derleyicisi yapmak insanlar için bile zor, SQLite’ı geçecek düzeyde olsa bile hafta sonu projesi ölçeğinde önemli bir başarı sayılır. Şirketlerin çoğu yüksek performanslı derleyiciler değil, iş mantığı için kod yapıştırıcısı üretiyor. Sorun teknolojinin kendisinden çok onu kullanan insanların tavrında.

  • Ama 20 bin dolarlık token maliyeti ve birden fazla kişinin dahil olması hesaba katıldığında “hafta sonu projesi” tanımı abartılı kalıyor.
  • CCC’nin hataları görmezden gelerek derleme yapması ve SQLite testlerinin bile tam olmaması ciddi sorunlar.
  • LLM’nin ürettiği kodun düzeltilmesinin zor olması ve kırılgan bir yapıya sahip bulunması nedeniyle sınırlar hâlâ ortada.
  • Sonuçta asıl sorun teknoloji değil, yapay zeka başarılarını aşırı pazarlayan insanlar.
  • “sour grapes” ifadesinin bu bağlamda uygun olmadığı da söyleniyor.

• SQLite’ta görülen 158.000 kat daha yavaş performans asıl mesele. Parsing kolay taraf; gerçekten zor olan kısım register allocation ve optimizasyon aşaması. GCC ile karşılaştırmak çok anlamlı değil ama LLM’nin böyle bir derleyici üretmiş olması yine de şaşırtıcı. Sonraki hedef, GCC ile arasındaki farkı 158.000 kattan 100 kat seviyesine indirmek olmalı.

  • Ancak bu sayı hesabı güvenilir görünmüyor. Her iterasyon 12 kat yavaşsa toplamın da 12 kat yavaş olması gerekir; 158.000 kat sonucu bir hata ya da yanlış anlama gibi duruyor. SQLite testinin gerçekten doğru çalışıp çalışmadığı da yeterince doğrulanmış değil.
  • LLM’nin GCC ya da Clang kaynak kodlarını eğitim sırasında görmüş olması muhtemel. Buna rağmen performansın bu kadar düşük olması soru işareti yaratıyor.
  • C parsing’in sanıldığından daha zor olduğuna dikkat çekenler de var. C tamamen parse edilebilir bir dil değildir yazısına bakılması öneriliyor.

• “1 iterasyonda 8 kat yavaşsa, 1 milyar kez tekrar edilse de sadece 8 kat yavaş olur” eleştirisinde olduğu gibi, 158.000 katlık sayı mantıksal olarak tutarlı görünmüyor. Muhtemelen register spilling L3 cache’i ezip geçmiş olabilir ya da gereksiz kodun çalışmasına yol açan bir bug vardır.

  • GCC sürümünün 0,047 saniyede bitmesi, “1 milyar iterasyon” iddiasını da pek güvenilir kılmıyor.

• C derleyicisi yapmak insanlar için de zor, ama bunu LLM’nin zeka kanıtı olarak görmek güç. Bu zaten iyi bilinen bir problem ve sayısız uygulama ile belge eğitim verisinde yer alıyor. Yani LLM yeni bir tasarım icat etmekten çok mevcut kalıpları yeniden birleştirmiş durumda. Buna rağmen bu tür araçlar yine de faydalı, gerçekten etkileyici olan şey ise mevcut OSS’yi kopyalamak değil, yeni yaklaşımlar öneren modellerin ortaya çıkması olacaktır.