Gánh nặng của việc giả lập x86 trên ARM: Khi bộ nhớ trở thành rào cản lớn nhất

Trong nhiều năm qua, việc chạy các ứng dụng x86 trên kiến trúc ARM đã trở thành một chủ đề nóng, đặc biệt khi Apple Silicon chứng minh rằng ARM hoàn toàn có thể cạnh tranh về hiệu năng. Tuy nhiên, đằng sau vẻ ngoài hào nhoáng đó là một loạt vấn đề kỹ thuật phức tạp liên quan đến mô hình bộ nhớ. Bài viết mới đây từ dự án FEX-Emu đã đi sâu phân tích những "nỗi đau" mà các nhà phát triển phải đối mặt.

x86-TSO là gì và tại sao nó quan trọng?

Mô hình bộ nhớ (memory model) là tập hợp các quy tắc chi phối cách các truy cập bộ nhớ tương tác với nhau trong hệ thống. Có hai mô hình đối lập nhau:

• ARM: mô hình nhất quán lỏng lẻo (relaxed/weak consistency), cho phép tối ưu hóa phần cứng tối đa
• x86: mô hình Total Store Ordering (TSO), rất nghiêm ngặt, đảm bảo tính nhất quán cao

Trên x86, khi một lệnh store được thực thi, giá trị đó ngay lập tức hiển thị với mọi bộ xử lý khác trong hệ thống. Điều này phù hợp với trực giác lập trình viên. Ngược lại, ARM theo mặc định không đảm bảo điều này, giúp tiết kiệm năng lượng nhưng gây khó khăn khi giả lập.

Để bù đắp, ARM đã giới thiệu các lệnh load-acquire và store-release (tương ứng với memory_order_acquire và memory_order_release trong C++). Khi giả lập x86 trên ARMv8.0-a, FEX buộc phải chuyển mọi lệnh load thành load-acquire và mọi lệnh store thành store-release — một giải pháp cực kỳ tốn kém.

Vấn đề với căn chỉnh bộ nhớ

Các ứng dụng x86 không quan tâm đến căn chỉnh bộ nhớ. Chúng truy cập bộ nhớ tùy ý, thậm chí vượt qua ranh giới cacheline. Trong khi đó, ARMv8.0 yêu cầu căn chỉnh tự nhiên (natural alignment): một truy cập 8 byte phải nằm ở offset 0, 8, 16, 24... Nếu không, CPU sẽ phát sinh lỗi căn chỉnh.

FEX xử lý vấn đề này thông qua cơ chế patchpoint: khi xảy ra lỗi căn chỉnh, nó bắt lấy lỗi, vá mã từ load-acquire/store-release sang lệnh load/store cơ bản và bọc trong data memory barrier (DMB). Tuy nhiên, biện pháp này gây suy giảm hiệu năng nghiêm trọng.

Kết quả đo đạc trên các nền tảng khác nhau cho thấy:

• AmpereOne: hiệu năng store cực kém, chỉ đạt ~8.5% khi gặp truy cập không căn chỉnh
• Cortex-X4 (Snapdragon 8 Gen 3): mất khoảng 50% hiệu năng cho cả load và store
• Oryon-3 (Qualcomm mới nhất): lệnh LRCPC-load đạt hiệu năng tương đương load thường khi căn chỉnh tốt, nhưng store không căn chỉnh chỉ đạt ~43%
• Apple M1: nhờ hỗ trợ TSO trực tiếp trong phần cứng, chênh lệch chỉ khoảng 5% — gần như không đáng kể

Đây chính là điều mà Apple đã làm để thực sự nghiêm túc với việc giả lập x86 trên ARM. Họ nhìn thấy vấn đề và giải quyết nó trực tiếp trong silicon.

Những lệnh atomic đáng sợ

x86 hỗ trợ 18 lệnh atomic read-modify-write (RMW), và hầu hết ánh xạ trực tiếp sang các lệnh ARMv8.1-a như ldaddal, ldclral, ldsetal, casal... Nghe có vẻ đơn giản, nhưng vấn đề căn chỉnh lại nổi lên.

Trên x86, nếu một lệnh atomic không căn chỉnh vẫn nằm trong một cacheline, hiệu năng gần như không đổi nhờ tính năng coherent cachelines đã có hàng thập kỷ. Chỉ khi vượt qua ranh giới cacheline (split-lock), hiệu năng mới sụp đổ — chậm hơn khoảng 458 lần.

Trên ARM, tình hình phức tạp hơn:

• Hầu hết các nền tảng ARM có độ trễ chậm hơn x86 ít nhất 3 lần ngay cả khi căn chỉnh tự nhiên
• Oryon-3 là CPU ARM đầu tiên hỗ trợ "coherent cachelines", đạt hiệu năng ngang x86 cho đến khi vượt cacheline
• Steam Frame (Valve) sử dụng bản vá kernel giúp xử lý atomic không căn chỉnh nhanh hơn đáng kể — từ 1060ns xuống còn 209ns

Tuy nhiên, split-lock là tính năng bắt buộc của x86 và hiện tại FEX chỉ có thể giả lập ở mức "best-effort", đôi khi gây hỏng dữ liệu (tear). Giải pháp lý tưởng là Transactional Memory Extension của ARM, nhưng tiếc thay, ARM đã chính thức khai tử extension này và chưa ai từng triển khai nó trong sản phẩm thực tế.

Bộ nhớ uncached — vấn đề ít được nhắc đến

Trong thuật ngữ Vulkan, uncached memory (thiếu bit VK_MEMORY_HOST_CACHED_BIT) thường đi kèm với VK_MEMORY_HOST_COHERENT. Các game engine dựa vào loại bộ nhớ này để truyền dữ liệu trực tiếp lên GPU qua PCIe, đặc biệt khi không có kiến trúc UMA.

Vấn đề là bộ nhớ write-combine (uncached) có hành vi rất khác biệt:

• Store thường vẫn đạt tốc độ tương đương cached nhờ write combine buffers (WCB)
• Load từ bộ nhớ write-combine lại cực kỳ chậm trên mọi nền tảng — đây là điểm yếu chí mạng khi giả lập

Đối với các tựa game chỉ hỗ trợ đường dẫn PCIe (không có UMA), việc giả lập bộ nhớ uncached đúng cách là điều kiện sống còn để chúng hoạt động.

Tương lai nào cho giả lập x86 trên ARM?

Dự án FEX đang kỳ vọng vào một số hướng đi:

• FEAT_LRCPC với ba phiên bản (LRCPC, LRCPC2, LRCPC3) bổ sung dần các lệnh TSO cho GPR, offset tức thời và vector
• Chế độ TSO cấp phần cứng như Apple đã làm — được đánh giá là giải pháp tốt nhất
• CASP 128-bit với khả năng chia đôi qua ranh giới atomic granule, cho phép split-lock thất bại an toàn và thử lại

Tuy nhiên, ngay cả những extension này vẫn chưa xử lý hoàn hảo mọi trường hợp biên. Các nhà phát triển FEX thừa nhận họ không phải kiến trúc sư phần cứng, nên chỉ có thể "phàn nàn và hy vọng ai đó giải quyết giúp".

Kết luận

Việc giả lập x86 trên ARM không chỉ là vấn đề dịch mã lệnh. Đằng sau nó là một loạt thách thức về mô hình bộ nhớ, căn chỉnh, atomic và tính nhất quán cache — những thứ mà phần cứng ARM truyền thống không được thiết kế để xử lý hiệu quả. Apple đã chứng minh giải pháp khả thi là tích hợp TSO trực tiếp vào chip, và Qualcomm với Oryon-3 cũng đang tiến gần đến điều đó.

Đối với người dùng Việt Nam đang quan tâm đến các thiết bị ARM như Snapdragon X Elite, Steam Frame hay các laptop ARM mới, đây là lý do tại sao trải nghiệm chạy phần mềm x86 vẫn chưa thể hoàn hảo. Tuy nhiên, với đà phát triển hiện tại, tương lai của giả lập x86 trên ARM đang trở nên sáng sủa hơn bao giờ hết.