#compiler-optimization

How PHP optimises bytecode

OPcache trong PHP thường được gọi là cache nhưng thực tế nó không chỉ lưu trữ bytecode mà còn thực hiện chuỗi tối ưu hoá. Khi PHP biên dịch script, OPcache chèn mười lăm bước xử lý (passes) giữa trình biên dịch và trình thực thi để xây dựng lại bytecode. Những bước này bao gồm việc loại bỏ mã không dùng, gộp hằng số, tối ưu hoá vòng lặp và tái cấu trúc cây cú pháp. Nghiên cứu đo lường cho thấy chỉ một phần nhỏ bytecode sau các passes này còn sống sót vào thời gian chạy, phần lớn được thay đổi hoặc loại bỏ. Bài học là để hiểu hiệu suất PHP thực sự cần quan tâm đến các pass tối ưu hoá của OPcache chứ không chỉ dựa vào việc cache bytecode.

Để hiểu sâu hơn cách PHP tối ưu hoá bytecode và lợi ích thực tế của OPcache trong triển khai ứng dụng.

A field day for Gleam’s language server

Phiên bản Gleam v1.18.0 vừa được phát hành, mang đến cải tiến đáng kể cho Gleam’s language server, nâng cao trải nghiệm phát triển.

Nếu bạn đang làm việc với Gleam, bài viết này sẽ giúp bạn cập nhật những tính năng mới nhất trong phiên bản mới nhất của ngôn ngữ server, từ đó tối ưu hóa hiệu suất phát triển và tích hợp với các công cụ IDE hiệu quả hơn.

GCC Patch Adjusting AMD Zen 5 Misprediction Cost Nets 12% Win In Benchmark

Một kỹ sư AMD đã gửi một patch cho GCC nhằm tăng hệ số chi phí dự đoán nhánh sai lên ba lần trong các bảng chi phí của Zen 4 và Zen 5. Patch này giúp trình biên dịch đưa ra quyết định tối ưu hơn về việc sắp xếp lệnh và bỏ qua các nhánh có khả năng sai khi biên dịch với -O3 -march=native -flto. Kết quả là SPEC CPU's 544.nab_r chạy nhanh hơn 12% trên Zen 5 và 9% trên Zen 4 so với bản GCC trước khi打补丁. Patch hiện đang được thảo luận trên danh sách gửi thư GCC và dự kiến sẽ được hợp nhất vào GCC 17, có thể backport về GCC 16.3. Điều này cho thấy AMD vẫn thường tinh chỉnh bảng chi phí sau khi CPU ra mắt, trái với tiến bộ gần đây trong việc upstream các mục tiêu CPU mới như Zen 6 vào GCC 16.

Bài viết này cung cấp thông tin quan trọng về tối ưu hóa hiệu năng AMD Zen 5 thông qua điều chỉnh chi phí dự đoán sai nhánh trong GCC, giúp lập trình viên hiểu cách tối ưu hóa mã cho bộ xử lý mới.

Compile-Time Improvements in LLVM 23

LLVM 23 tập trung vào việc giảm thời gian biên dịch ở mức -O3, đạt được cải thiện trung bình 6,75% (10,53% cho sqlite3) nhờ hàng chục thay đổi kỹ thuật cụ thể. Các cải tiến bao gồm bảng băm DenseMap sử dụng linear probing và mảng bit nhỏ, hàm băm xxh3, tối ưu push_back của SmallVector, tái cấu trúc cây dominator bằng bump allocation, lặp qua thành phần kế thừa/predecessor dựa trên Use-based ranges, sửa đổi lưu trữ metadata, thay đổi các phân tích dựa trên khóa con trỏ thành phân tích dựa trên số khối, và tối ưu GlobalISel -O0 trên AArch64. Ngoài ra, việc áp dụng header đã biên dịch trước (precompiled headers) làm tăng tốc độ xây dựng LLVM/Clang khoảng 45%. Những bài học là đầu tư vào cấu trúc dữ liệu cấp thấp và hệ thống xây dựng có thể tạo ra lợi thế đo lường được, trong khi chi phí khởi động từ việc di chuyển động và phân tích tùy chọn toàn cầu của llvm::cl vẫn là thách thức cần giải quyết, với kế hoạch thay thế bằng TableGen trong LLVM 24. Đối với những lập trình viên đang cân nhắc đọc bài gốc, bài viết cung cấp các con số cụ thể và danh sách các thành phần đã được sửa đổi, giúp xác định nơi có thể áp dụng các tối ưu tương tự trong dự án của mình.

LLVM 23 mang lại cải thiện đáng kể về thời gian biên dịch với các tối ưu hóa cụ thể, giúp lập trình viên xây dựng và triển khai ứng dụng nhanh hơn.

Pointer Provenance— The Hidden Identity of Every C Pointer

Bối cảnh: Trong ngôn ngữ C, con trỏ thường được xem như chỉ là một giá trị địa chỉ bộ nhớ. Nguyên nhân kỹ thuật: Các nhà phát triển nhận ra rằng mỗi con trỏ còn mang theo một “identity” ẩn—pointer provenance—định nghĩa cách nó được tạo, truyền và truy cập. Hệ quả: Nhận diện này giải thích tại sao alias analysis hoạt động, tại sao một số hành vi lại là undefined behavior và giúp compiler tối ưu hoá hiệu suất mà không vi phạm semantics. Điều đáng học: Khi hiểu pointer provenance, bạn có thể viết code an toàn hơn, tránh các lỗi khó phát hiện và tận dụng tối đa các tối ưu hoá của trình biên dịch. Đề xuất: Nếu bạn muốn sâu hơn vào cách trình biên dịch áp dụng khái niệm này để tạo code nhanh hơn, bài gốc cung cấp ví dụ chi tiết và các công cụ phân tích.

Pointer provenance giải thích cách compiler tối ưu hóa mã C và xác định hành vi không xác định qua định danh ẩn của con trỏ.

Why compiling Rust to WebAssembly is slow

Compiling Rust to WebAssembly with debug info is slower than it should be. Sometimes unbearably slower.

C++ Insights Episode 77: RVO, NRVO, std::move EXPLAINED

Tập mới của C++ Insights (số 77) giải thích chi tiết về RVO, NRVO và std::move. Video trả lời thắc mắc từ khán giả về kỹ thuật tối ưu trả về giá trị (return-value optimization) trong C++.

Lập trình viên nên đọc để hiểu rõ về RVO (Return Value Optimization) và NRVO (Name Return Value Optimization), hai kỹ thuật tối ưu hóa hiệu suất quan trọng trong C++ giúp giảm chi phí tạo và sao chép đối tượng khi trả về giá trị từ hàm, từ đó cải thiện hiệu suất chương trình.

Rust and the Case of the Redundant Comparison

Bài viết kể về quá trình phát hiện và sửa lỗi trình biên dịch Rust khi sinh ra lệnh so sánh thừa trong Vec::clear(), nguyên nhân do khác biệt so với phương pháp set_len(0) nhanh hơn trong thư viện hyper, và cách khắc phục bằng pattern SetLenOnDrop để vượt qua hạn chế phân tích alias của LLVM. Quá trình bao gồm biên dịch Rust từ nguồn, viết test codegen, tham gia review PR và merge qua bors, kết quả được tích hợp trong Rust 1.30.

Những lập trình viên muốn tối ưu hóa hiệu suất cho các ứng dụng sử dụng Vec hoặc thậm chí là các thư viện như hyper sẽ tìm hiểu cách Rust xử lý các trường hợp như Vec::clear() để tránh lỗi hiệu suất do so sánh thừa và áp dụng các giải pháp hiệu quả hơn như SetLenOnDrop.

Tail-call optimization in C is relatively recent [LWN.net]

Tối ưu hóa gọi đuôi (TCO) trong C từng không được hỗ trợ do quy ước gọi hàm truyền thống, nhưng từ năm 2001 (GCC) và gần đây hơn (Clang), tính năng này đã được cải thiện đáng kể nhờ các nghiên cứu như Copy-and-Patch Compilation. Gần đây, cả GCC và Clang đã hỗ trợ TCO đầy đủ, mở ra triển vọng mới cho các dự án như Gforth và cả cộng đồng Python.

Nếu bạn đang làm việc với các hàm tái sử dụng nhiều lần, vòng lặp đệ quy sâu hoặc cần tối ưu hóa hiệu suất cho các ứng dụng yêu cầu tính năng này, bài viết sẽ giúp bạn hiểu rõ cách Tail-call Optimization đã được cải thiện trong C và những hạn chế trước đây, từ đó giúp bạn lựa chọn cách viết mã hiệu quả hơn.

Counting the days, revisited

Bài viết phân tích tối ưu thuật toán chuyển đổi ngày Dương lịch sang Julian Day numbers (rata die), đề xuất bắt đầu năm từ tháng Ba để đơn giản hóa xử lý năm nhuận, giới thiệu công thức tháng-ngày nhanh hơn bằng m*979/32 thay thế m*153/5, khuyến nghị dùng u32 thay int để đảm bảo phép chia Euclid chính xác, trình bày phương pháp kiểm tra năm nhuận dựa trên chia hết cho 25 và 16, và kết thúc bằng biểu thức bitwise 30 | (m ^ (m >> 3)) tính độ dài tháng chỉ biên dịch thành hai lệnh ARM.

Lập trình viên nên đọc bài này để tìm hiểu cách tối ưu hóa thuật toán chuyển đổi ngày Gregorian thành ngày Julian hiệu quả hơn, giúp giảm thiểu thời gian tính toán và tối ưu hóa hiệu suất cho ứng dụng sử dụng trong các trường hợp yêu cầu tính toán ngày chính xác và nhanh chóng.

Steel Bank Common Lisp version 2.6.7

Release notes covering multiple recent versions of Steel Bank Common Lisp (SBCL), from version 2.5.3 through 2.6.7. Highlights include a new SB-MANUAL contrib module embedding the SBCL manual in docstrings for interactive exploration, AVX512 and ARM64 SIMD support, LoongArch architecture support, Windows ARM64 support, numerous compiler bug fixes (miscompilations, infinite loops, type derivation errors), and a wide range of performance optimizations including reduced consing, improved type inference, faster arithmetic operations, and better SIMD utilization for UTF-8 processing.

The inliner is yielding benefits for ZJIT

ZJIT’s new method inliner helps us specialize even megamorphic block invocations.

Running DOOM On A Custom CPU Built From Scratch

Hai nhà phát triển đã thiết kế một CPU tùy chỉnh từ đầu ở cấp độ cổng logic, triển khai trên FPGA, rồi port thành công game DOOM chạy trên đó. Ban đầu chỉ đạt 0,7 FPS, nhưng sau khi tăng tốc độ xung nhịp, tối ưu bộ nhớ và điều chỉnh compiler, hiệu suất tăng lên 15-20 FPS. Dự án còn yêu cầu xây dựng các thiết bị ngoại vi như giao diện bàn phím, đầu ra HDMI và bộ định thời phần cứng, với mục tiêu đạt 30 FPS để trải nghiệm mượt mà.

Những kiến thức về kiến trúc CPU từ cơ bản đến thậm chí là thiết kế logic từ đầu sẽ giúp bạn hiểu rõ hơn về giới hạn và tiềm năng của hệ thống máy tính, từ đó có thể tối ưu hóa hiệu suất hoặc phát triển các giải pháp giải quyết vấn đề không chỉ trong game mà cả trong các ứng dụng thực tế.

Lucky Code

A deep dive into how a seemingly cosmetic C code style change — using *lwr++ = x instead of *lwr = x; lwr++ — causes Clang to generate branchless csel instructions on ARM (and cmov on x86), resulting in a 6x speedup for a custom Quicksort implementation. The post shows the full branchless Quicksort with sorting networks, compares the generated assembly with and without branches, and notes that GCC does not exhibit this behavior, consistently generating the slower branch-based version.