- CCC (Claude’s C Compiler) do Claude Opus 4.6 của Anthropic viết hoàn toàn đã được công bố với tuyên bố có thể biên dịch nhân Linux
- Đây là một trình biên dịch độc lập viết bằng Rust, tự triển khai mọi thành phần từ frontend đến linker, nhưng hiệu năng và chất lượng tối ưu hóa kém hơn GCC rất nhiều
- Trong các benchmark với SQLite và nhân Linux, CCC biên dịch toàn bộ các tệp C mà không có lỗi, nhưng thất bại khi build ở giai đoạn linker với hơn 40.000 lỗi tham chiếu
- Hiệu năng chạy SQLite chậm hơn tối đa 158.000 lần, kích thước nhị phân lớn hơn hơn 3 lần, và các tùy chọn tối ưu hóa (
-O2 v.v.) không có tác dụng
- Việc AI tạo ra được một trình biên dịch C hoàn chỉnh là điều có ý nghĩa về mặt kỹ thuật, nhưng mức hiệu quả và khả năng tương thích đủ để dùng thực tế vẫn chưa đạt
Tổng quan và cấu trúc của CCC
- CCC là trình biên dịch C do AI viết hoàn toàn mà Anthropic tạo ra bằng Claude, hỗ trợ x86-64, i686, AArch64, RISC-V 64
- Viết bằng Rust, bao gồm IR dựa trên SSA, bộ tối ưu hóa, bộ sinh mã, assembler, linker, và cả phần tạo thông tin gỡ lỗi DWARF
- Bài viết giải thích tách biệt vai trò của compiler, assembler và linker, đồng thời cho rằng linker là phần phức tạp nhất và dễ phát sinh lỗi nhất
- Vì nhân Linux sử dụng các mở rộng của GCC và linker script phức tạp nên không phù hợp làm đối tượng thử nghiệm ban đầu; thay vào đó SQLite được chọn làm benchmark chính
Môi trường và phương pháp thử nghiệm
- So sánh GCC 14.2.0 và CCC trong cùng điều kiện trên hai máy ảo dựa trên Debian (6 vCPU, 16GB RAM)
- Các hạng mục so sánh: thời gian biên dịch, kích thước nhị phân, tốc độ thực thi, mức sử dụng bộ nhớ, độ ổn định
- CCC dùng tính năng
gcc_m16 để chỉ giao phần mã khởi động 16-bit cho GCC, còn lại xử lý bằng CCC
- Benchmark SQLite được thiết kế theo hướng nặng CPU, thực hiện 42 phép toán SQL qua 10 giai đoạn
Tóm tắt các kết quả chính
- Nhân Linux 6.9: CCC biên dịch được toàn bộ 2.844 tệp C, nhưng thất bại ở giai đoạn linker với 40.784 lỗi
undefined reference
- Nguyên nhân lỗi: relocation sai và tạo symbol sai trong các section
__jump_table, __ksymtab
- Biên dịch SQLite: CCC chậm hơn GCC 1,3 lần, kích thước nhị phân lớn gấp 2,7~3 lần, mức dùng bộ nhớ cao gấp 5,9 lần
- Hiệu năng chạy SQLite: chậm hơn GCC -O0 737 lần, và chậm hơn GCC -O2 1.242 lần
- Các truy vấn đơn giản chậm hơn 1~7 lần, còn truy vấn vòng lặp lồng nhau chậm hơn tối đa 158.000 lần
- Vượt qua cả 5 loại crash test, cho thấy tính đúng đắn chức năng đã được đảm bảo
Nguyên nhân suy giảm hiệu năng
- Spill thanh ghi quá mức: phần lớn biến cục bộ bị lưu lên stack, khiến truy cập bộ nhớ tăng quá nhiều
- Trong hàm
sqlite3VdbeExec, hơn 100 biến được xử lý qua stack, làm độ dài mã tăng gấp 3
- Tùy chọn tối ưu hóa không hoạt động: kết quả của
-O0 và -O2 hoàn toàn giống nhau, 15 pass SSA chạy giống nhau ở mọi mức
- Frame pointer bị hỏng, khiến không thể gỡ lỗi bằng GDB
- Kích thước mã phình to: nhị phân SQLite đạt 4,27MB, lớn gấp 2,78 lần GCC, làm tăng lỗi trượt instruction cache
- Không tạo bảng symbol: không có symbol cho các hàm nội bộ nên không thể profiling
Điểm mạnh và giới hạn của CCC
- Điểm mạnh
- Biên dịch toàn bộ các tệp C của nhân Linux mà không có lỗi
- Đảm bảo độ chính xác và độ ổn định của kết quả SQLite, không xảy ra segfault
- Hỗ trợ giao diện dòng lệnh tương thích GCC
- Giới hạn
- Tốc độ thực thi suy giảm cực mạnh (tối đa 158.000 lần)
- Không tương thích linker nên build nhân thất bại
- Kích thước nhị phân và mức dùng bộ nhớ quá lớn
- Thiếu tối ưu hóa và thông tin gỡ lỗi, tùy chọn
-O không có tác dụng
- Tốc độ biên dịch cũng chậm hơn GCC 25%
Vấn đề “Hello World”
- Ngay sau khi công bố đã xuất hiện issue “Hello world does not compile”
- Không tìm thấy
stddef.h, stdarg.h nên thất bại ở giai đoạn tiền xử lý
- Trên GitHub, chủ đề này thu hút hơn 288 phản ứng và khoảng hơn 200 bình luận
- Một số người dùng đánh giá rằng “trông giống bài tập làm trình biên dịch ở bậc đại học”
Kết luận
- CCC là một trường hợp chứng minh AI có thể tạo ra trình biên dịch C hoàn chỉnh
- Nó xử lý toàn bộ các tệp C của nhân Linux mà không lỗi và chạy SQLite đúng về mặt chức năng
- Tuy nhiên, không phù hợp để sử dụng thực tế
- Hiệu năng chạy cực thấp, còn các chức năng linker, tối ưu hóa và gỡ lỗi đều chưa hoàn thiện
- Có ý nghĩa như một thành tựu nghiên cứu, nhưng với tư cách trình biên dịch dùng trong công việc thực tế, các công cụ hiện có như GCC và Clang vẫn là lựa chọn thiết yếu
5 bình luận
Thì ra đây là nguồn gốc của meme "Hello world does not compile" haha
Lúc đầu không khí khá giống với cờ vây.
Nếu cứ để nó lặp đi lặp lại và bảo sửa liên tục, chẳng phải đến lúc nào đó sẽ ra một trình biên dịch còn tốt hơn sao?
Có lẽ nên xem trọng ý nghĩa ở chỗ nó đã đạt tới mức bài tập của sinh viên đại học..
Ý kiến trên Hacker News
Cuộc tranh luận lần này cho thấy rất rõ cả hai góc nhìn ủng hộ và phản đối đối với LLM coding agent
Bên ủng hộ nói “thật đáng kinh ngạc khi chỉ trong vài giờ đã làm ra được một compiler chạy được”, còn bên phản đối nói “nếu không hoạt động đúng thì chẳng có ý nghĩa gì”
Codebase càng phức tạp thì agent càng yếu, và nhiều người cũng hoài nghi với lập luận lặp đi lặp lại rằng “thế hệ tiếp theo sẽ sửa được”
Anthropic nói đã compile được Linux kernel, nhưng trên thực tế lại thất bại, cho thấy khoảng cách giữa kỳ vọng bị thổi phồng về AI và thực tế
Việc vượt qua test và cho ra output bề ngoài có vẻ đúng là một chuyện, còn việc code đó có chất lượng đủ để bảo trì lại là chuyện hoàn toàn khác
Ban đầu là “chỉ viết được hàm nhỏ”, sau đó là “không compile nổi Linux”, rồi tiếp đến là “chưa đạt mức GCC”, tức là tiêu chuẩn cứ liên tục bị dời đi
Nhưng nhìn vào tốc độ tiến bộ thì có vẻ chỉ cần thêm vài kỹ sư compiler là có thể nhanh chóng đuổi kịp
Vì vậy vẫn còn nghi ngờ liệu LLM có thể giải quyết các vấn đề hoàn toàn mới hay không
Anthropic nói trong blog rằng Linux kernel có thể boot trên cả x86, nhưng thực tế có vẻ chỉ thành công trên RISC-V
Bài đăng chính thức nói là x86/ARM/RISC-V đều được,
nhưng tài liệu trong repo chỉ có test cho RISC-V
Mức suy giảm hiệu năng của C không tối ưu hóa là điều khá thú vị
Trong bản build SQLite3, CCC chậm hơn 12 lần, còn bản tối ưu hóa thì chậm hơn 20 lần
Điều này cho thấy GCC đã đạt được nhiều thành quả tối ưu hóa đến mức nào
Nhưng nếu compiler shuffle register quá nhiều thì mối liên hệ đó biến mất và hiệu năng sẽ giống như Python
CCC còn chậm hơn cả -O0, điều này khá bất ngờ
Việc CCC compile được mọi file C trong kernel mà không báo lỗi không có nghĩa là nó tạo ra kết quả hợp lệ
Chỉ vượt qua test SQLite thì vẫn chưa đủ
/dev/nullcũng đâu có lỗiconst, và cả việc định nghĩa lại kiểu hay ép kiểu sai cũng cứ thế cho quaTức là để đạt mục tiêu “vượt qua test”, nó đã dùng mẹo compile cả code không hợp lệ
Có bài viết nói “compiler là giai đoạn dễ nhất”, nhưng trên thực tế linker mới là phần phức tạp nhất
Hàng nghìn kiểu mã hóa lệnh của x86-64, cùng layout chi tiết của ELF, là những thứ AI khó xử lý
Ngoài ra, phép tính kiểu “1 vòng lặp chậm hơn 4 lần → 1 tỷ vòng lặp chậm hơn 158.000 lần” là vô lý
Dù còn thiếu nhiều lệnh, nhưng chỉ ở mức cần điền thêm bảng dữ liệu là xong
Thật đáng ngạc nhiên khi kỳ vọng của con người thay đổi nhanh đến vậy
Nếu là 5 năm trước, câu “AI tạo ra C compiler bằng prompt tiếng Anh” hẳn sẽ bị xem là một trò đùa quá lố
Không hiểu nổi sự hoài nghi quá mức của HN
Việc làm ra một C compiler cho ba kiến trúc khác nhau vốn đã khó ngay cả với con người,
và chỉ cần đạt mức vượt qua SQLite thôi cũng đã là một thành quả rất ấn tượng ở quy mô dự án cuối tuần
Phần lớn công ty ngoài kia thực tế không cần compiler hiệu năng cao, mà cần lớp code keo dán cho business logic
Vấn đề không nằm ở bản thân công nghệ mà ở thái độ của những người sử dụng nó
Điểm cốt lõi là hiệu năng trên SQLite chậm hơn 158.000 lần
Parsing là bài toán tương đối dễ, còn phần thực sự khó là register allocation và giai đoạn tối ưu hóa
So sánh trực tiếp với GCC thì không có nhiều ý nghĩa, nhưng việc LLM làm ra được compiler kiểu này tự thân nó đã rất đáng kinh ngạc
Mục tiêu tiếp theo là kéo khoảng cách với GCC từ 158.000 lần xuống còn khoảng 100 lần
Nếu mỗi vòng lặp chỉ chậm hơn 12 lần thì tổng thể cũng chỉ nên chậm hơn 12 lần; 158.000 lần có vẻ là lỗi hoặc hiểu nhầm
Cũng chưa có đủ xác minh rằng bài test SQLite thực sự chạy đúng
Dù vậy mà hiệu năng vẫn thấp đến thế thì cũng khá khó hiểu
Có thể tham khảo bài C không phải là một ngôn ngữ có thể parse hoàn toàn
Như nhận xét “nếu 1 vòng lặp chậm hơn 8 lần thì 1 tỷ vòng lặp cũng chỉ chậm hơn 8 lần”,
con số 158.000 lần rõ ràng không hợp logic
Có thể do register spilling đã làm tràn L3 cache, hoặc có bug khiến code thừa bị thực thi
Làm C compiler vốn đã khó cả với con người,
nhưng khó xem đây là bằng chứng cho trí tuệ của LLM
Đây là một bài toán đã quá nổi tiếng, với vô số implementation và tài liệu đã nằm trong dữ liệu huấn luyện
Nói cách khác, LLM không sáng tạo ra thiết kế mới mà chỉ tái tổ hợp các mẫu có sẵn
Dù vậy, các công cụ như thế này vẫn hữu ích,
và điều thực sự ấn tượng sẽ là khi xuất hiện model không chỉ sao chép OSS sẵn có mà còn đề xuất được cách tiếp cận mới