#compiler-optimization

This Week In Security: New Spectre Attacks, Crushing Quantity Of Linux Vulns, Google Gets Too Much AI, And Hacking Lawnmowers

Một nghiên cứu học thuật mới phát hiện ra các tấn công Spectre-v2 đang được hồi sinh qua các JIT compiler như SpiderMonkey, eBPF và GraalVM, khai thác mã tự sửa đổi và các instruction đã lưu trong cache. Trong một bản cập nhật gần đây, Linux kernel đã vá hơn 1,200 lỗ hổng bảo mật, tiếp tục xu hướng "AI Vulnpocalypse". Google tạm ngừng chương trình thưởng lỗ hổng mã nguồn mở do nhận lượng lớn báo cáo lỗi AI chất lượng thấp, sẽ xem xét lại vào năm 2027. Nhiều sự kiện khác bao gồm Asos bị ransomware qua tài khoản Snowflake bị xâm phạm, lỗi trên robot cắt cỏ Mammotion cho phép truy cập dữ liệu 337,000 khách hàng và camera trực tiếp, cùng với việc lấy chứng chỉ TLS giả cho domain Google ccTLD qua nhà đăng ký bị hack.

Arch-specific SIMD in Go

Go 1.27 giới thiệu các API vector SIMD đặc thù kiến trúc dưới dạng experimental. API này được phát triển để tận dụng tối đa sức mạnh xử lý song song của các instruction set như AVX-512, NEON, hay SSE2 trên kiến trúc cụ thể. Việc tùy biến theo kiến trúc giúp tăng hiệu năng lên đến 3-4 lần cho các phép tính số học trên vector. Điều đáng học là cách Go cân bằng giữa tính di động và tối ưu hóa hiệu năng, cho phép lập trình viên lựa chọn mức độ tùy chỉnh phù hợp với nhu cầu ứng dụng.

Go 1.27 giới thiệu API vector SIMD cụ thể cho kiến trúc giúp tối ưu hóa hiệu năng ứng dụng.

I'm Looking for My Next Role

Một chuyên gia compiler với kinh nghiệm dẫn dắt đội ngũ phát triển YJIT - JIT compiler hiện đang được tích hợp trong CRuby và áp dụng tại các công ty lớn như Shopify, GitHub, Stripe. Người này có bằng PhD về JIT compilation và type analysis, từng làm việc tại Apple với GPU compiler, nghiên cứu AI tại Mila với Bengio, Paull, và Precup, gần nhất là xây dựng PyTorch/ONNX compiler cho startup ML systems. Với hơn 2,500 trích dẫn học thuật và 13 bài báo được bình duyệt, họ đang tìm kiếm vị trí compiler, systems, ML systems hoặc nghiên cứu tại Montreal hoặc remote. Bài viết chi tiết sẽ cung cấp thêm thông tin về kỹ năng cụ thể và định hướng sự nghiệp phù hợp với ứng viên tiềm năng.

Lập trình viên nên đọc bài này để cơ hội làm việc với chuyên gia JIT compiler hàng đầu trong lĩnh vực phát triển hệ thống và học máy.

How PHP generates machine code

PHP JIT không được kích hoạt trong cài đặt mặc định, vì nó phải thực thi đủ lâu để bù đắp chi phí biên dịch. Trên bộ test gồm 177 test cases, function JIT thua cuộc do không bù được thời gian biên dịch. Trong khi đó, tracing JIT chứng tỏ hiệu quả khi thời gian chạy đủ dài để vượt qua chi phí ban đầu. Đây là bài học quan trọng về trade-off giữa chi phí biên dịch và thời gian thực thi khi implement JIT compiler.

Bài viết này giúp lập trình viên hiểu khi nào nên bật JIT trong PHP để tối ưu hiệu suất ứng dụng.

How an MIT research project became a global programming language

Bài viết mô tả cách Julia, một ngôn ngữ lập trình ra đời từ một dự án nghiên cứu tại MIT, đã phát triển từ ý tưởng học thuật thành công cụ được sử dụng rộng rãi. Nguyên nhân

Bài viết cho bạn hiểu ngôn ngữ Julia từ dự án nghiên cứu MIT trở thành công cụ phổ biến toàn cầu với hơn 1 triệu người dùng.

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.

What a JIT Can't Know

A deep technical comparison examines why Roundhouse, a tool that reads a Rails application and transpiles it to plain Ruby ahead of time, beats both YJIT and ZJIT on the Lobsters Rails benchmark by over 4x, and why the gains multiply rather than overlap. The piece profiles where time goes in Rails versus Roundhouse's output (SQL statement preparation, Active Record overhead, routing/dispatch, allocations) and argues that a JIT can only make existing work cheaper per instruction, while a whole-application specializer like Roundhouse can decide some work doesn't need doing at all (static SQL, fixed relations, preload trees, callback resolution). It also shares early results from Roundhouse's new 'futamura' target, which keeps real Active Record objects and gems intact while statically specializing what it can prove, estimating a 2.5-3x ceiling for that approach versus 4x for full lowering.

PGO or not PGO this is the dilemma. Step 2

Profile-guided optimization (PGO) là kỹ thuật biên dịch hai lần, nơi lần đầu ghi lại các bộ đếm thực thi trên mỗi đường control flow trong quá trình training, sau đó lần thứ hai sử dụng dữ liệu này để tối ưu hóa inlining, branch layout, hot/cold function splitting và các kỹ thuật khác. Nguyên nhân kỹ thuật đằng sau hiệu quả của PGO là shape of control flow được exercise trong training quan trọng hơn các giá trị thực tế của data, điều này giải thích tại sao MySQL Test Run với coverage rộng có thể chuyển hiệu quả sang production performance dù workload không giống TPCC. Hệ quả là PGO có thể cải thiện đáng kể hiệu năng ứng dụng bằng cách tập trung tối ưu hóa vào các code path thực tế được sử dụng nhiều. Điều đáng học là việc chọn workload training phù hợp - không cần giống production nhưng cần coverage control flow tốt - sẽ quyết định hiệu quả của PGO, với các thử nghiệm cho thấy cải thiện hiệu năng lên đến 15-20% trong một số trường hợp.

PGO là kỹ thuật tối ưu hóa biên dịch hai bước giúp tăng hiệu năng ứng dụng bằng cách phân tích luồng điều khiển được thực thi trong quá trình đào tạo.

PGO or not PGO this is the dilemma. Step 1

Profile-Guided Optimization (PGO) là kỹ thuật biên dịch hai giai đoạn, dùng để ghi lại các đường dẫn code hot và cold rồi tái biên dịch với dữ liệu đó. Trong thử nghiệm với Percona Server, PGO mặc định chỉ cải thiện hiệu năng dưới 5%, nhưng khi biên dịch MySQL với PGO được train trên sysbench-tpcc, kết quả lại chậm hơn bản không dùng PGO dù tăng thread từ 128 đến 1024. Kết quả trái ngược này cho thấy việc chọn workload huấn luyện ảnh hưởng lớn đến hiệu quả PGO. Nghiên cứu sẽ tiếp tục để làm rõ tại sao workload training lại quan trọng đến vậy.

Bài này giải thích tại sao kỹ thuật PGO không mang lại hiệu suất như mong đợi khi biên dịch MySQL với một số công cụ kiểm tra cụ thể.

Proposal: an opt-in emulator flag that makes map order independent of atom creation order

Map trong Elixir sắp xếp thứ tự dựa trên thời gian tạo atom, dẫn đến kết quả không ổn định do quá trình khởi động Elixir tải module song song và compiler biên dịch file đồng thời. Sự không đồng bộ này gây ra race condition khi lặp qua map, làm kết quả thay đổi giữa các lần chạy khác nhau. Đề xuất này đưa ra flag emulator để tách biệt thứ tự tạo atom và thứ tự lặp map, giải quyết vấn đề bằng cách cho phép lập trình viên chủ động lựa chọn hành vi mong muốn. Việc này quan trọng với các ứng dụng cần tính xác định như testing và deployment trong môi trường production.

Đề xuất này giúp hiểu cách xử lý thứ tự bản đồ độc lập với thứ tự tạo atom, tăng tính ổn định và dự đoán cho code của lập trình viên.

Zeroization, part 1: Wiping can make things worse

Bối cảnh: Việc xóa dữ liệu nhạy cảm sau khi sử dụng là thực bảo mật cơ bản. Nguyên nhân kỹ thuật: Nghiên cứu của Google trên Android 10 cho thấy phương thức secure deletion bằng truncate() và fsync() có thể làm lộ dữ liệu do cơ chế virtual memory của Linux. Hệ quả: Thay vì xóa an toàn, phương pháp này có thể để lại bản sao dữ liệu trong bộ nhớ swap hoặc RAM. Điều đáng học: Cần hiểu rõ cách hoạt động của hệ thống file và bộ nhớ ảo trước khi implement secure deletion, vì các API tưởng như an toàn như TRUNCATE có thể gây rò rỉ thông tin.

Bài này giúp lập trình viên hiểu tại việc xóa dữ liệu nhạy cảm bằng phương pháp thông thường có thể vô tình làm lộ thông tin quan trọng.

Hacking the Go compiler to efficiently map IPv4 to IPv6

Go maintainers declined netip.Addr.Map() saying the compiler should optimize netip.AddrFrom16(ip.As16()) instead. How difficult is it to implement?

Turbo Haskell

Tác giả bắt đầu viết THC, một dự án "Turbo Haskell compiler" như một trò đùa trong kỳ nghỉ thăm Bartosz Milewski. Mục tiêu chính là cải thiện tốc độ biên dịch cho Haskell bằng cách sử dụng các kỹ thuật tối ưu hóa tiên tiến. Dự án này hứa hẹn rút ngắn đáng kể thời gian biên dịch code Haskell từ vài phút xuống chỉ còn vài giây. Với Haskell vốn nổi tiếng với thời gian biên dịch dài, THC có thể mang lại bước đột phá cho nhà phát triển ngôn ngữ này.

Bài viết này giúp bạn khám phá cách xây dựng một trình biên dịch Haskell hiệu suất cao với cách tiếp cận sáng tạo và thú vị.

Lightning Talks (Python Language Summit 2026)

Lightning talks on a one-time ABI break, safer interruptions, EktuPy (Scratch but Python), an AGENTS.md file for CPython, and a call to read PEP 836.

What's New in Python 3.15 – Real Python

Explore the new features in Python 3.15, including lazy imports, frozendict, sentinel values, a sampling profiler, and a faster JIT.

AMD Upstreams AVX10_V2_AUX Support Into LLVM Clang 24

AMD has upstreamed initial support for AVX10_V2_AUX into LLVM/Clang, merged into LLVM 24 Git. The new instruction set extends AVX10 with data processing and format conversion instructions for AI workloads, including conversion to compressed formats like FP4 and FP6, OCP microscaling formats, and new rounding modes. It is exposed via a new -mavx10v2aux compiler flag and spans roughly 15,000 lines of code across 20 patches. This is part of the AI Compute Extensions (ACE) effort jointly developed by AMD and Intel under the x86 Ecosystem Advisory Group. AMD is also working on equivalent support for GCC. LLVM/Clang 24.1 stable is expected around next March.

Just-In-Time Compilation for Java Performance: Recent and Ongoing Improvements

A JavaOne 2026 talk overview covers recent and ongoing improvements to the JVM's just-in-time (JIT) compilers, which are central to Java's performance. It touches on how JIT compilation intersects with OpenJDK projects like Valhalla, Leyden, and Panama, and how it continues evolving alongside the Java language, application domains, deployment models, and hardware. The full talk is available in the JavaOne 2026 playlist.

JEP 544: Ahead-of-Time Code Compilation

JEP 544 đề xuất mở rộng AOT cache của HotSpot để lưu trữ code native đã được tối ưu hóa trong quá trình training, giúp quá trình production chạy ngay lập tức mà không cần phụ thuộc vào interpretation và JIT compilation. Giải pháp này kết hợp lợi ích khởi động của AOT với khả năng deoptimize và reoptimize của JIT khi workload thay đổi, dựa trên JEP 483 và JEP 515. Benchmark cho thấy cải thiện tốc độ khởi động khoảng 65-80% và giảm đáng kể thời gian warm-up. Đáng chú ý là tính năng này không yêu cầu thay đổi code ứng dụng, hỗ trợ các bộ thu gom Serial, Parallel, G1, và ZGC, nhưng sẽ fallback sang JIT khi CPU features, architecture hoặc GC choice giữa training và production khác nhau.

JEP 544 giúp tăng tốc khởi động và thời gian warm-up hiệu quả bằng cách kết hợp lợi ích của biên dịch Ahead-of-Time với khả năng tối ưu hóa linh hoạt của JIT.

Bjorn Gustavsson

The Erlang, Elixir and Gleam conference in Europe - 2 days of talks,discussions and networking for the BEAM community.

A custom virtual machine for the Stars! 4X game

Để chạy game Stars! năm 1995 trên hệ thống 64-bit hiện đại, nhà phát triển đã tạo Stars!VM - một VM tùy chỉnh kết hợp emulator 80286 và cầu nối Win16-to-Win32. Dự án sử dụng differential fuzzer để kiểm tra, MCP-based monitoring cho AI điều khiển UI, và tối ưu hóa I/O buffered giúp tăng tốc độ tạo lượt. Thông qua truy vết instruction với AI Fable 5.1, các đoạn code nóng được viết lại bằng C, làm tăng gấp đôi tốc độ tạo lượt. Project là một weekend hack với source code và bản release đã được ký sẵn trên GitHub, bao gồm cả việc reimplement WaveMix.dll và nén LZ để giảm kích thước game.

Một lập trình viên nên đọc bài này để học cách bảo tồn và tối ưu hóa phần mềm cũ bằng cách kết hợp máy ảo tùy chỉnh, công cụ AI và kỹ thuật tối ưu hóa mã nguồn.

C++26: Trivial infinite loops are no longer undefined behaviour

Let’s start with a question! Is this program well-defined? 1 2 3 4 int main() { while (true) ; } If you said yes, you’d be wrong — at least before C++26. A while (true); loop with no side effects used to be undefined behaviour. Compilers were free to assume it terminates, and some — Clang in particular — would optimize it away entirely, with spectacular consequences: 1 2 3 4 5 6 7 8 9 10 11 // https://godbolt.org/z/WYMxxeW1T #include <iostream> int main() { while (true) ; } void unreachable() { std::cout << "Hello world!" << std::endl; } In…

MSVC Build Tools Preview updates – September 2026

The MSVC Build Tools Preview is updated regularly with the latest features and fixes from the MSVC development team. This post covers updates from the

V8 Engine: The Journey of JavaScript from Code to Execution

V8 Engine: The Journey of JavaScript from Code to Execution When the JavaScript code is passed to v8 engine, it goes through different stages before execution those are NOTE: JavaScript is a JIT …

AMD Posts New GCC Compiler Patch For Extended Load Optimization

AMD đã đóng góp một bản vá mới cho GCC compiler nhằm tối ưu hóa load operations bằng cách thêm SLP-tree analysis. Công cụ này giúp nhận diện các mẫu load-plus-convert và thu hẹp kiểu vector load để sử dụng extended loads với ZMM registers thay vì vextract instructions. Tối ưu hóa này nhắm vào code generation x86_64 nói chung, không chỉ riêng cho kiến trúc Zen. Mặc dù chưa có benchmark hiệu năng được cung cấp, bản vá đang được xem xét để đưa vào GCC 17. Lập trình viên quan tâm đến optimization assembly code nên theo dõi sự phát triển của feature này.

Bài này giúp lập trình viên hiểu cách AMD tối ưu hóa trình biên dịch GCC để tăng hiệu suất tải dữ liệu trên nền tảng x86_64.

FEX 2609 Released With Speedier JIT Performance, JIT Disk Cache Option

FEX 2609, the monthly release of the open-source x86_64-on-AArch64 emulator, brings JIT performance improvements including an optimization for the PMULHRSW instruction family that can yield up to a 2x uplift in some game scenarios, faster self-modifying-code detection used by Unity games, and reduced lock contention when multiple threads JIT code simultaneously. The release also introduces an opt-in on-disk JIT cache via FEX_DISKCACHE=1 or a JSON config option, which persists compiled JIT code across runs to reduce stutter on later loads, though it currently lacks cache size limits or other safeguards. The project also debuted a revised logo.

Fedora 47 Considering Use Of Thin LTO Compiler Optimizations

Fedora 47 đang xem xét việc triển khai Thin LTO thay cho Fat LTO trong link-time optimizations thông qua RPM macro mới. Thin LTO hoạt động nhanh hơn và tiết kiệm bộ nhớ hơn so với LTO truyền thống nhưng vẫn giữ được hầu hết các lợi ích hiệu năng, được kích hoạt bằng flag -flto=thin. Đề xuất này không bắt buộc sử dụng LTO trên toàn bộ các package mà cho phép người bảo trì đánh giá riêng cải thiện thời gian biên dịch và hiệu năng. Vẫn cần bỏ phiếu từ Fedora Engineering and Steering Committee (FESCo) trước khi được áp dụng.

Lập trình viên nên đọc bài này để cập nhật về tối ưu hóa biên dịch Thin LTO tiềm năng trong Fedora 47 có thể cải thiện thời gian build và hiệu năng ứng dụng của họ.

Issue #815: ZJIT can now inline GC allocations — Ruby Weekly

Ruby Weekly Issue #815: ZJIT can now inline GC allocations

Move in C++ without a std::move

Bối cảnh lập trình viên thường được khuyên nên sử dụng std::move một cách hạn chế, nhưng thực tế có những tình huống cần di chuyển dữ liệu hiệu quả mà không cần đến std::move. Nguyên nhân kỹ thuật là do các trình biên dịch hiện đại đã tối ưu hóa giá trị trả về (RVO) và tối ưu hóa giá trị đặt tên (NRVO) để loại bỏ sao chép không cần thiết, thậm chí trong các phiên bản C++11 trở đi. Hệ quả là việc sử dụng thủ công std::move trong nhiều trường hợp không mang lại lợi ích về hiệu năng mà còn làm giảm độ rõ ràng của code. Điểm đáng học là lập trình viên nên hiểu khi nào trình biên dịch tự động tối ưu và khi nào cần can thiệp thủ công với std::move hoặc các kỹ thuật như perfect forwarding để đạt hiệu suất tối ưu.

Bài viết này giải thích cách sử dụng hiệu quả Move trong C++ mà không cần đến std::move.

adam bien's blog

Tại airhacks.fm có một tập podcast với Simon Ritter trình bày về các công nghệ hiệu suất Java của Azul bao gồm garbage collector C4 không dừng, JIT compiler Falcon dựa trên LLVM, ReadyNow loại bỏ warm-up và Cloud Native Compiler. Các giải pháp này đều hướng đến cải thiện hiệu suất Java mà không cần thay đổi code ứng dụng. Đặc biệt, Falcon JIT compiler sử dụng kiến trúc LLVM giúp tối ưu hóa mã bytecode thành mã gốc hiệu quả hơn. Podcast có thể tải xuống hoặc nghe qua Spotify và iTunes.

Bài podcast cung cấp kiến thức về công nghệ Java hiệu suất cao từ Azul mà không cần thay đổi mã nguồn ứng dụng.

Zero-Cost 'Tagless Final' in Rust with GADT-style Enums

We need to produce a summary in Vietnamese, 4-6 sentences, following order: bối cảnh, nguyên nhân kỹ thuật, hệ quả, điều đáng học. Must write like explaining to a programmer whether to read the original article. Must include concrete numbers and names of tech if present. Avoid generic statements. No markdown, no opening cliché, no "Tóm tắt". Must not use any Chinese/Japanese/Korean/Han characters. Use only Vietnamese and Latin characters. Keep technical terms in English unchanged. Must not use any non-Latin characters. So we must avoid diacritics? Actually Vietnamese uses diacritics, which are Latin characters with diacritics, allowed? The instruction says "Chỉ dùng chữ Việt và chữ Latin: tuyệt đối không có ký tự Hán/Trung/Nhật/Hàn trong câu trả lời". So Vietnamese uses Latin letters with diacritics, that's okay. Must not include any Chinese characters. So we can use Vietnamese diacritics. Must not use markdown formatting. Must not start with a generic opening phrase like "Tóm tắt". Must not use opening generic phrase. Must be 4-6 sentences. Must follow order: context, technical cause, consequence, lesson to learn. Must include concrete numbers and names of tech if present. In the article, there is "Zero-Cost 'Tagless Final' in Rust with GADT-style Enums". It mentions "never type" and "optimized assembly output". It may mention "zero-cost abstractions". It may mention "GADT-style Enums". It may mention "Rust". It may mention "tagless final". It may mention "never type". It may mention "assembly output". It may mention "optimized assembly". It may mention "deep dive". It may mention "implementing the 'tagless initial' pattern". It may mention "zero-cost abstractions". It may mention "Rust". It may mention "GADT". It may mention "enum". It may mention "never". It may mention "cost". It may mention "abstraction". It may mention "assembly". It may mention "optimized". It may mention "demonstrated". It may mention "deep dive". It may mention "zero-cost". It may mention "tagless final". It may mention "GADT-style Enums". It may mention "Rust". It may mention "never type". It may mention "assembly output". It may mention "optimized assembly output". It may mention "zero-cost abstractions". It may mention "deep dive". It may mention "implementing". It may mention "tagless initial". It may mention "pattern". It may mention "enums". It may mention "never type". It may mention "cost". It may mention "abstractions". It may mention "Rust". It may mention "GADT". It may mention "enum". It may mention "never". It may mention "assembly". It may mention "optimized". It may mention "output". It may mention "demonstrated". It may mention "deep dive". It may mention "zero-cost". It may mention "tagless final". It may mention "GADT-style Enums". It may mention "Rust". It may mention "never type". It may mention "assembly output". It may mention "optimized". It may mention "assembly". It may mention "output". It may mention "demonstrated". It may mention "deep dive". It may mention "implementing". It may mention "tagless initial". It may mention "pattern". It may mention "enums". It may mention "never type". It may mention "cost". It may mention "abstractions". It may mention "Rust". It may mention "GADT". It may mention "enum". It may mention "never". It may mention "assembly". It may mention "optimized". It may mention "output". It may mention "demonstrated". It may mention "deep dive". It may mention "zero-cost". It may mention "tagless final". It may mention "GADT-style Enums". It may mention "Rust". It may mention "never type". It may mention "assembly output". It may mention "optimized". It may mention "assembly". It may mention "output". It may mention "demonstrated". It may mention "deep dive". It may mention "implementing". It may mention "tagless initial". It may mention "pattern". It may mention "enums". It may mention "never type". It may mention "cost". It may mention "abstractions". It may mention "Rust". It may mention "GADT". It may mention "enum". It may mention "never". It may mention "assembly". It may mention "optimized". It may mention "output". It may mention "demonstrated". It may mention "deep dive". It may mention "zero-cost". It may mention "tagless final". It may mention "GADT-style Enums". It may mention "Rust". It may mention "never type". It may mention "assembly output". It may mention "optimized". It may mention "assembly". It may mention "output". It may mention "demonstrated". It may mention "deep dive". It may mention "implementing". It may mention "tagless initial". It may mention "pattern". It may mention "enums". It may mention "never type". It may mention "cost". It may mention "abstractions". It may mention "Rust". It may mention "GADT". It may mention "enum". It may mention "never". It may mention "assembly". It may mention "optimized". It may mention "output". It may mention "demonstrated". It may mention "deep dive". It may mention "zero-cost". It may mention "tagless final". It may mention "GADT-style Enums". It may mention "Rust". It may mention "never type". It may mention "assembly output".

Rust language adds algebraic floating-point methods

The new algebraic methods allow optimizations on floating-point addition, subtraction, multiplication, division, and remainder operations using the algebraic properties of real numbers.

Code BEAM Europe - Learning Resources / Talks - Erlang Forums

Adding JIT to AtomVM - Paul Guyot | Code BEAM Europe 2025 Comments welcome! View the code-sync tag for more Code Sync talks!

LLVM Improves Zen 1 / Zen 2 Support To Deal With "Notoriously Bad" PDEP/PEXT

LLVM đã cải thiện hỗ trợ cho AMD Zen 1 và Zen 2 để xử lý các instruction PDEP/PEXT vốn được biết đến là cực kỳ chậm trên các bộ xử lý này. Nguyên nhân kỹ thuật là do triển khai BMI2 bit-manipulation instructions trên Zen architecture có hiệu năng kém. Hệ quả là việc sử dụng các lệnh này trong các ứng dụng như database, cryptography và các trò chơi như chess, Sudoku sẽ được tối ưu hóa tốt hơn. Cải tiến này tập trung vào việc tinh chỉnh cost modeling cho znver1/znver2 scheduler và chuẩn bị cho việc tạo trực tiếp llvm.pdep/pext intrinsics, bao gồm cả các implementation dạng scalarized vector.

Cải tiến này giúp lập trình viên tối ưu hiệu năng ứng dụng sử dụng PDEP/PEXT trên AMD Zen 1/Zen 2.

AMD Proposes New LLVM iTHP Option For Squeezing More Performance

AMD's compiler technologies team has proposed a new opt-in Clang feature, -fenable-readonly-thp, that implements instruction Transparent Huge Pages (iTHP) at compile and link time. The compiler driver arranges 2 MiB segment alignment at link time, links a small startup object, and calls madvise(MADV_COLLAPSE) at process start so the kernel can promote 4 KiB text page mappings to huge pages, reducing iTLB pressure. Testing with SPEC CPU 2026, Geekbench, CPython, and database/server workloads showed workload-dependent gains, strongest on large .text binaries like interpreters and compilers, with no broad regressions observed but some cost in larger binaries and startup overhead. The feature requires Linux 7.2 or newer since older kernels only support iTHP from TMPFS-based storage. Unlike the BOLT binary layout optimizer, this approach requires no workload profiling. A Google engineer noted they built a similar library, and AMD hopes to upstream this into LLVM and potentially GNU toolchains instead.

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

Một kỹ sư AMD đã đề xuất patch cho GCC tăng chi phí branch misprediction lên 3 lần trong bảng chi phí của Zen 4 và Zen 5, mang lại 12% cải thiện trên benchmark SPEC CPU 544.nab_r cho Zen 5 và 9% cho Zen 4 khi biên dịch với -O3 -march=native -flto. Patch này đang được xem xét trên GCC mailing list và dự kiến sẽ được tích hợp vào GCC 17, với khả năng backport sang GCC 16.3. Việc AMD thường điều chỉnh bảng chi phí sau khi CPU ra mắt thay vì trước đó khác với việc họ cải thiện việc upstream các CPU target mới như Zen 6 vào GCC 16. Điều này cho thấy việc tối ưu hóa compiler có thể mang lại hiệu năng đáng kể ngay cả sau khi CPU đã được tung ra thị trường.

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ỏ.