Claude Code có renderer phức tạp hơn cả một game engine

Một trong những maintainer của Claude Code đã nói một câu cực kỳ hài hước trên Internet.

Tôi không ở đây để chê bai người này. Họ rõ ràng là chân thành và có thiện ý. Tôi từng nghĩ và nói ra những điều còn tệ hơn, với sự tự tin còn lớn hơn thế.

Nhưng… nó ngớ ngẩn đến mức nào? Rõ ràng việc so sánh Claude Code với Grand Theft Auto 6 là không công bằng. Tác giả có nói là một game engine nhỏ, và ngay cả một hình nộm rơm yếu ớt nhất cũng phải thừa nhận rằng họ không hề muốn so với một siêu bom tấn AAA.

Nhưng khi tôi thử đi xuống “hệ phân cấp” của các tựa game hiện đại để tìm một thứ tương đương, chẳng có gì cảm thấy hợp lý. Game hiện đại quá phức tạp để có thể đem ra so sánh một cách có ý nghĩa với một TUI (terminal UI). Chắc hẳn phải có một game nào đó khiến phép so sánh giữa Claude Code và một game engine trở nên hợp lý hơn.

Thế còn super mario 64 thì sao?

Super Mario 64. Một tượng đài năm 1996 và vẫn là huyền thoại năm 2026. Cộng đồng speedrun yêu thích nó vì điều khiển chính xác, số lượng glitch vừa đủ để khai thác, thiết kế màn chơi vượt thời gian. Và quan trọng với mục đích của chúng ta: nó chạy trên một cái N64 chết tiệt. Đúng vậy. Xem cấu hình này:

Những thế giới trong tranh tại lâu đài Peach tràn đầy sức sống, màu sắc và chuyển động — tất cả trên cấu hình khiêm tốn đó. Điều này có vẻ là một phép so sánh công bằng hơn. Vậy câu hỏi của chúng ta là:

Claude Code có đang phải thực hiện nhiều công việc hơn để tạo và render một khung hình đã được diff của nó so với việc Super Mario 64 từng phải làm để tạo và render một khung hình của thế giới 3D tuyệt đẹp nhưng còn sơ khai đó không?

So sánh táo với siêu nhân

Trước tiên, hãy nói rõ: đây không phải so sánh táo với táo, mà là táo với một chiến binh không gian siêu việt trong lý thuyết. Tức là khác loài hoàn toàn. Phần cứng hai chương trình này chạy trên đó khác nhau đến mức không thể khác hơn. Một loại phần cứng có thể giả lập loại kia bằng phần mềm, như một con búp bê matryoshka há hốc miệng.

Nhưng cả hai đều là hậu duệ của kiến trúc von Neumann, nên ta vẫn có thể so sánh chút ít, dù hơi liều lĩnh. Quan trọng hơn, cảm giác cho thấy chúng nên có gì đó tương đồng:

• SM64 render ở 320x240, tương đương kích thước terminal trên màn 27 inch 2K của tôi.
• Pipeline đồ họa của SM64 đơn giản hơn game hiện đại rất nhiều; ta có thể xem gần như toàn bộ như một khối compute và so với CPU rendering của Claude Code¹.
• Quan trọng nhất: chúng cảm giác tương đương ở mức độ “việc này khó đến đâu”.

SM64 chạy 30 FPS, Claude Code ~60 FPS. Nhưng điều này có thể gây hiểu lầm. Game Steam gần nhất của tôi, Deep Copy², khóa ở 60 FPS nhưng phần lớn thời gian là chờ GPU. Claude Code phải layout component, diff, rồi render. SM64 phải layout scene graph và render. Claude Code gọi network; SM64 phải swap dữ liệu trong VRAM cực hạn. Có lẽ ta đã tìm ra ví dụ phù hợp.

Nhưng… vẫn không ổn. Claude Code làm quạt của CPU 9950X tản nước³ của tôi rú lên — còn rú to hơn cả khi giả lập nguyên một N64. Nó chắc chắn không idle.

Vậy rốt cuộc claude code đang làm cái quái gì?

 ▐▛███▜▌
▝▜█████▛▘
 ▘▘   ▝▝

Tôi bảo Claude tự chạy perf stat -p PID -- sleep 3 trên chính nó để đo hiệu năng khi đang hoạt động. Độ nghiêm túc vừa đủ. Nó trả về:

Nó dùng CPU khoảng 26% thời gian — không ngủ, nhưng cũng không full tải. Có vẻ như đang chờ IO, điều hợp lý cho một chương trình terminal kết nối HTTP API phức tạp.

Chạy strace để xem syscall:

futex – cái tên rất hợp

sudo strace -f -c -p PID trong một khoảng thời gian hợp lý:

À. futex. Nền tảng của locking trên Linux. Claude Code dành 70% thời gian quay vòng ở đó.

Nhưng chờ futex không xấu. Vấn đề thật sự là sched_yield được gọi 89,000 lần. Các thread không chờ, mà đang quay vòng (spin), rồi nhường CPU cho nhau như ném củ khoai nóng.

cách chờ đúng

Thread chính và HTTP client nằm ở do_epoll_wait. Đó là cách đúng cho chương trình IO-bound: dùng primitive của OS để chờ (select, poll, epoll, io_uring…).

Nhưng Claude Code đang yield 89,000 lần. Điều này sai vì:

• Thread đang làm việc thì không yield.
• Thread đang chờ thì dùng primitive OS, không yield.

Hay chỉ là javascript?

Tôi thử so với amp:

Đó mới là cách chờ đúng. Số lượng syscall ít hơn rất nhiều.

Không phải ta đang nói về super mario 64 sao?

Đúng. Claude Code đã dùng 4.6 tỷ instruction trong 3 giây để:

• Theo dõi output process
• Re-render, diff, vẽ component tree
• Stream HTTP
• Gửi telemetry, feature flag, A/B test⁴

SM64 cần bao nhiêu instruction để render một frame?

Dù con số không chính xác, nó vẫn thấp hơn rất nhiều.

Nhưng ta không cần chỉnh lại nữa

Vì lúc này con số đã quá xấu hổ: Claude Code dùng nhiều hơn một bậc độ lớn instruction trong 33ms “frame” so với SM64 để render cả thế giới 3D.

Dù kiến trúc CPU hiện đại khác N64 rất nhiều (out-of-order execution, branch prediction, pipeline…), so sánh instruction vẫn nói lên điều gì đó.

Không ôm nhau, không rút kinh nghiệm

Claude Code churn ra nhiều instruction hơn SM64 chỉ để diff và vẽ text terminal.

Tôi hiểu: nó chạy trên HTTP, JIT phức tạp, terminal emulator, v.v…

Điều xấu hổ không phải là nó chậm. Mà là không ai điều tra 30,000 syscall sai mỗi giây trong một chương trình cực kỳ giá trị.

Có vẻ như kiến thức systems programming đã mai một. Vì tiền. Rất nhiều tiền.

Có nhiều tiền hơn ở application programming. Tại sao cải tiến hệ thống khi có thể xây frontier model trị giá nghìn tỷ đô?

Tôi không phán xét Anthropic. Đó là cách kiếm tiền. Và rồi bạn dùng tiền đó thuê những người giỏi ở Bun để sửa vấn đề hệ thống⁶.

Không biết vì sao TUI chậm thì không sao. Ưu tiên kiếm nghìn tỷ đô cũng không sao.

Nhưng… đừng giả vờ bạn đang xây dựng một game engine⁷.