Thách thức khi giả lập x86 trên kiến trúc ARM: Bài toán về mô hình bộ nhớ TSO

Chào mừng bạn đến với bài viết chuyên sâu đầu tiên trên trang web của chúng tôi. Chúng ta sẽ cùng tìm hiểu một vấn đề đang diễn ra với trình giả lập x86, ảnh hưởng đến mọi ứng dụng mà chúng ta giả lập. Vấn đề này gói gọn trong một thuật ngữ bao quát với những hệ lụy sâu rộng: Giả lập mô hình bộ nhớ x86 Total Store Ordering (x86-TSO).

Những khó khăn khi giả lập mô hình bộ nhớ này trên mô hình bộ nhớ thứ tự yếu (weak ordering) mà ARM định nghĩa là rất đa diện và bao gồm nhiều vấn đề. Trong bài viết này, chúng ta sẽ đi qua tất cả các vấn đề có thể gặp phải và cách chúng ta giải quyết (hoặc trong một số trường hợp là không thể giải quyết). Hãy chuẩn bị cho mình một món ăn nhẹ và một đồ uống ấm để thưởng thức, vì đây sẽ là một bài viết khá dài.

x86-TSO chính xác là gì?

Trước khi đi sâu vào cách chúng ta xử lý vấn đề mô hình bộ nhớ x86, trước tiên chúng ta cần thảo luận chính xác nó là gì. Mô hình bộ nhớ là một tập hợp các quy tắc về cách thức truy cập bộ nhớ trong một hệ thống hoạt động liên quan đến nhau. Các quy tắc này sẽ quyết định cách các lệnh tải (loads) và lưu (stores) tương tác trong môi trường đơn luồng hoặc đa luồng. Có một vài mô hình bộ nhớ phổ biến được triển khai trong các dạng phần cứng khác nhau, nhưng hai mô hình mà chúng ta quan tâm hôm nay là mô hình nhất quán lỏng (hoặc yếu) của ARM và biến thể mô hình nhất quán Total-Store-Ordering của x86. Hai mô hình này về cơ bản là hai thái cực của phổ; trong đó ARM là lỏng nhất, cho phép tối ưu hóa phần cứng đáng kể; còn x86 là nghiêm ngặt nhất, thực thi một mô hình nhất quán rất mạnh mẽ, không để lại nhiều không gian cho việc tối ưu hóa. Một điều cần lưu ý khi thảo luận về các mô hình bộ nhớ là sự khác biệt giữa tính nhất quán (consistency) và tính nguyên tử (atomicity). Mặc dù chúng có liên quan, nhưng chúng không giống nhau và không được đảm bảo trong mọi trường hợp.

Cách tốt nhất để giải thích sự khác biệt giữa các mô hình bộ nhớ là bắt đầu với cách x86 xử lý vấn đề này. Với việc TSO rất nghiêm ngặt trong cách vận hành, lập trình viên có thể giả định rằng khi một lệnh lưu bộ nhớ xảy ra, nó sẽ hiển thị một cách nhất quán với tất cả các bộ xử lý khác trong hệ thống. Điều này cũng có nghĩa là khi một lệnh tải bộ nhớ xảy ra, tất cả các lệnh lưu trước đó "về mặt logic" sẽ đã hoàn tất, hoặc ít nhất là đã hiển thị. Điều này phù hợp với kỳ vọng của lập trình viên: bạn ghi vào bộ nhớ, nó trở nên hiển thị ngay tại thời điểm ghi, vì đây là cách nghĩ trực quan khi lập trình. Các lệnh lưu thực sự đang sắp xếp thứ tự hiển thị của các lệnh tải, do đó mới có tên gọi của mô hình này. Có một chút sắc thái trong cách vận hành này nhưng không nhất thiết phải hiểu sâu.

Mô hình bộ nhớ yếu mà ARM sở hữu có cách vận hành ít trực quan hơn một chút. Theo mặc định, các lệnh tải và lưu bộ nhớ thông thường mà ARM sử dụng không nhất quán một cách nghiêm ngặt giữa các bộ xử lý trong hệ thống của bạn, cho phép CPU hoạt động hiệu quả hơn trong hầu hết thời gian. Khi một lệnh lưu được thực thi, phần bộ nhớ đó (cacheline) không hiển thị ngay lập tức với các bộ xử lý khác trong hệ thống. Điều này giúp tiết kiệm năng lượng và hiệu suất quý giá vì việc vô hiệu hóa cacheline của các nhân khác hoặc cho phép chúng "snoop" (dò tìm) bộ nhớ đệm của bộ xử lý khác là rất tốn kém về mặt phần cứng. Liên quan đến điều này, nếu một bộ xử lý đang tải dữ liệu từ bộ nhớ mà bộ xử lý khác đã ghi vào, không có gì đảm bảo rằng lệnh tải này sẽ thấy được bộ nhớ đã cập nhật đó. Nghe có vẻ như điều này sẽ gây ra một số vấn đề đáng kể trong ứng dụng đa luồng, phải không? Các phiên bản ARM cũ hơn (ARMv7 trở về trước) đã sử dụng lệnh rào cản bộ nhớ (memory barrier) để đảm bảo thứ tự, điều này gây ra những ảnh hưởng đáng kể đến hiệu suất.

Để vượt qua hạn chế về tính nhất quán này, ARM cũng đã giới thiệu các lệnh bộ nhớ load-acquire và store-release. Trong ngôn ngữ C++, điều này tương ứng với các định nghĩa memory_order_acquire và memory_order_release của std::atomic. Theo thuật ngữ của ARM, các lệnh này về mặt kỹ thuật cũng không được coi là các thao tác nguyên tử, nhưng các lập trình viên thường đánh đồng hai khái niệm này. FEX đã sử dụng các thuật ngữ atomic-load và atomic-store để chỉ cùng một thứ! Sự khác biệt thường không quan trọng, nhưng khi thảo luận về các chủ đề này, có lẽ nên khắt khe hơn một chút.

Trường hợp sử dụng chính cho các lệnh này là để ép buộc thứ tự bộ nhớ giữa các lớp lệnh này. ARM gọi đây là mô hình "Release Consistency sequentially consistent (RCsc)". Không đi quá sâu vào cách mô hình này vận hành, ý chính là các lệnh load-acquire phải được quan sát theo trình tự mà không được sắp xếp lại, và các lệnh store-release cũng vậy trong khi phải thỏa mãn ngữ nghĩa "barrier-ordered-before". Điều này giúp loại bỏ lệnh rào cản bộ nhớ tốn kém vốn bắt buộc phải có trong các phiên bản kiến trúc ARM cũ hơn.

Những khởi đầu khiêm tốn của ARMv8.0-a

Đây là tiền đề nơi chúng ta bắt đầu với ARMv8.0-a khi giả lập mô hình bộ nhớ x86-TSO. Chúng ta biến tất cả các lệnh tải bộ nhớ x86 thành các lệnh load-acquire của ARM, và các lệnh lưu bộ nhớ x86 thành các lệnh store-release. Điều này mang lại cho FEX ngữ nghĩa bộ nhớ giống hệt như x86, mặc dù thực tế chúng ta đang nghiêm ngặt hơn mức cần thiết. Điều này là do chúng ta không có điểm trung gian nào khớp chính xác với hành vi đó. Như người ta có thể nghĩ, việc giả lập TSO với các lệnh này cực kỳ tốn kém và chúng ta có các microbenchmark có thể chứng minh điều này. Bởi vì các CPU ARM không được thiết kế để các lệnh acquire/release tương đối hiếm gặp này đột nhiên trở thành đại đa số các lệnh được thực thi.

Trước tiên, hãy bắt đầu với một thứ gì đó dễ dàng và sử dụng một microbenchmark khá "thân thiện" với phần cứng. Không có các trường hợp biên phức tạp, chỉ truy cập bộ nhớ trong trường hợp thông thường. Điều này cung cấp cho chúng ta một số con số cơ sở về tình huống tốt nhất nên là gì.

Hãy phân tích biểu đồ này vì nó kể cho chúng ta nghe một vài câu chuyện thú vị. Các cột Load và Store của mỗi máy đại diện cho con số hiệu suất cơ sở mà phần cứng của chúng ta nên cố gắng đạt được. Chúng không cố gắng tối đa hóa băng thông bộ nhớ của mỗi hệ thống, mà thực hiện cùng một lượng công việc cho mỗi loại thao tác. Nếu chúng ta chú ý đến kết quả acquire-load, chúng ta có thể thấy rằng trong số năm CPU được kiểm tra, ba trong số đó có hiệu suất bị cản trở khá nhiều do sử dụng acquire-load! Ngoài ra, chúng ta có thể thấy rằng CPU AmpereOne có các lệnh release-store thấp một cách đáng kinh ngạc so với các kết quả khác, và các lệnh tải M1 Acquire/LRCPC cũng thấp hơn đáng kể so với mức cơ sở.

Kết quả của AmpereOne đặc biệt cho thấy con đường kế thừa này có thể tệ đến mức nào. Những lệnh này chưa bao giờ được thiết kế để sử dụng theo cách này. Việc sử dụng ngữ nghĩa acquire-release cho mọi lệnh tải để giả lập x86 thực sự áp đặt một số hạn chế rất nghiêm ngặt lên các CPU ARM, khiến các lệnh tải không còn có thể được sắp xếp thứ tự xung quanh nhau chút nào. Vì vậy, khi bạn có hàng triệu lệnh trong số đó đang chạy mỗi giây, hiệu suất thực sự không được mong đợi là tốt. Nhưng vì đây là những lệnh duy nhất chúng ta có với ARMv8.0-a, nên đó là những gì chúng ta phải sử dụng. Trong khi Cortex-X4 và Cortex-X925 có hiệu suất tuyệt vời cho các lệnh này, bạn có thể thấy Oryon-3 đã hạ thấp tầm quan trọng của chúng như thế nào.

Chúng ta sẽ đi đâu từ đây?

Hãy xem xét kỹ hơn các lệnh LRCPC-load, vốn là bắt buộc kể từ ARMv8.3. Phần mở rộng này thêm một loạt các lệnh tải mới vào ARM ISA và thêm một mô hình bộ nhớ mới trên nền tảng mô hình RCsc của ARM trước đó. Mô hình bộ nhớ "Release Consistency processor consistent (RCpc)" mới này chính là thứ chúng ta hằng mong đợi! Phần mở rộng này được thiết kế dựa trên các yêu cầu mà việc giả lập x86 đòi hỏi, và dự kiến sẽ được sử dụng nhiều trên phần cứng triển khai nó. Như bạn có thể thấy từ biểu đồ, hầu hết các nền tảng đều có hiệu suất LRCPC-load tương đương với các lệnh tải thông thường của chúng.

Với phần mở rộng mới này được bắt buộc bởi các phiên bản ARM mới hơn, chúng ta về cơ bản đã giải quyết được vấn đề hiệu suất bộ nhớ. Ít nhất theo microbenchmark này thì có vẻ là như vậy. Khi FEX phát hiện ra phần mở rộng này, chúng ta ngừng sử dụng hoàn toàn các lệnh Acquire-Load và chuyển sang LRCPC-Load thay thế. Nhưng chuyện gì đang xảy ra với kết quả của Apple M1 vậy..?

Đây là nơi chúng ta cần khen ngợi con đường của Apple trong việc giải quyết vấn đề này. Với các bộ xử lý Apple Silicon, họ đã trực tiếp thêm hỗ trợ cho mô hình bộ nhớ x86-TSO. Khi tính năng CPU này được bật, các lệnh tải/lưu ARM thông thường của họ sẽ thay đổi hành vi để khớp với những gì x86 yêu cầu. Họ đã đi theo con đường này khi biết rằng họ sẽ cần một giải pháp hiệu suất cao cho phần cứng của mình khi chuyển sang hệ sinh thái ARM độc quyền. Đây là lý do tại sao trên phần cứng của họ, các lệnh LRCPC-load thực chất là các bí danh (aliases) của các lệnh acquire-load, vì trình giả lập x86 của họ thậm chí không sử dụng các lệnh này! Vì họ triển khai mô hình bộ nhớ x86, họ chỉ sử dụng các lệnh tải/lưu thông thường, điều này có thể thấy trong kết quả microbench của chúng tôi là mức hao hụt hiệu suất không thể phân biệt được. Công bằng mà nói với các nền tảng khác, việc bật chế độ TSO trên toàn luồng này có ảnh hưởng đến hiệu suất, chúng ta chỉ là không thấy nó ở đây. Khi FEX phát hiện tính năng CPU này từ Asahi Linux, chúng ta cũng sẽ kích hoạt nó và nhận được sự cải thiện hiệu suất "miễn phí". Một mối lo ngại tiềm ẩn là khi chuyển đổi giữa giả lập x86 và mã ARM, mã ARM sẽ phải chịu chi phí hao hụt không cần thiết do tất cả các truy cập của nó giờ đây đều là TSO. Mặc dù đây là một mối lo ngại hợp lý, nhưng lượng mã ARM gốc thực thi dưới dạng giả lập tiến gần đến 0%. Là một nhà phát triển, bạn không quan tâm đến việc 1% các truy cập bộ nhớ trở nên chậm hơn 10%, bạn quan tâm đến việc 99% các truy cập trở nên nhanh hơn 15% so với mức "lý tưởng" (như đã thấy trong kết quả của AmpereOne).

Cần lưu ý rằng, chúng tôi nghĩ chế độ TSO là con đường tốt nhất để đảm bảo giả lập x86 hiệu suất cao trên nền tảng này. Bởi vì điều này đảm bảo rằng mọi lệnh truy cập bộ nhớ đều hoạt động theo cách chúng ta muốn hoặc mong đợi. Điều này được thể hiện qua việc phần mở rộng FEAT_LRCPC chính thức thực sự có ba phiên bản, mỗi phiên bản đều áp dụng các "băng dán" (bản vá) cho việc triển khai.

Ngay cả với ba phần mở rộng này, vẫn có những hành vi trường hợp biên không thể được giả lập tốt như khi chúng ta có một nút chuyển đổi phần cứng TSO. Chúng tôi dự đoán sẽ có thêm các phiên bản mở rộng theo thời gian, cố gắng khắc phục một số vấn đề bổ sung mà chúng ta sẽ thảo luận sau trong bài viết.

Tôi cứ tưởng truy cập bộ nhớ là phần dễ dàng?

Trong phần trước, chúng ta đã "tử tế" với phần cứng ARM và tuân theo các yêu cầu căn chỉnh (alignment) của phần cứng cơ bản để có được mức cơ sở cho hiệu suất. Tuy nhiên, khi giả lập x86, chúng ta đâm sầm vào một vấn đề nhức nhối ngay từ đầu. Các ứng dụng x86 yêu thích của bạn không quan tâm đến căn chỉnh! Chúng sẽ truy cập bộ nhớ theo bất kỳ cách nào chúng muốn, vượt qua các ranh giới cacheline, thực hiện các thao tác nguyên tử không được căn chỉnh. Bạn nghĩ đến các vấn đề căn chỉnh nào, thì các trò chơi này đều đang làm như vậy. Vấn đề này tồi tệ đến mức chúng ta có một thuật ngữ liên quan đến nó, gọi là split-locks. Đây là một vấn đề lớn đến mức ngay cả nhân Linux cũng sẽ ghi lại khi chúng xảy ra và làm chậm các trò chơi khi chúng thực hiện điều đó! Khiến nhiều game thủ phải mày mò với các tùy chọn nhân để tránh sự chậm trễ này!

Nhưng chúng ta sẽ chưa nói về split-locks toàn diện, hãy bắt đầu với các lệnh tải-lưu trong một môi trường không quan tâm đến căn chỉnh. x86 đưa ra một số đảm bảo nhất định cho lập trình viên; nếu bạn thực hiện một lệnh tải-lưu và nó nằm bên trong một cacheline thì lệnh tải-lưu đó sẽ vừa là nguyên tử vừa vẫn khớp với mô hình nhất quán như đã mô tả trước đó. Tuy nhiên, để "tử tế" một chút với các nhà phát triển phần cứng, nếu lệnh tải-lưu vượt qua một cacheline, dữ liệu sẽ không còn là nguyên tử và các luồng khác có thể và sẽ thấy nó bị xé lẻ (tear). Vì vậy, lập trình viên cần phải cẩn thận vì một lệnh tải-lưu cơ bản không phải là một split-lock.

Vấn đề khi giả lập các truy cập cơ bản này bằng load-acquire/store-release là ARMv8.0 yêu cầu cái được gọi là căn chỉnh tự nhiên (natural alignment). Điều này có nghĩa là đối với bất kỳ kích thước dữ liệu nào được truy cập, phần bù (offset) trong bộ nhớ phải khớp với kích thước đó. Vì vậy, đối với một truy cập 8 byte, nó phải nằm ở các phần bù: 0, 8, 16, 24, v.v. Điều này hoạt động tốt cho các ứng dụng ARM gốc, nhưng điều gì sẽ xảy ra khi chúng ta không tuân thủ các yêu cầu căn chỉnh tự nhiên? Đối với ARM, điều này có nghĩa là lệnh sẽ gây ra lỗi căn chỉnh (alignment fault). Phần cứng xác thực rằng các yêu cầu căn chỉnh đã được đáp ứng và nếu không, CPU sẽ báo lỗi. Điều này thường dẫn đến treo ứng dụng nhưng FEX có cách xử lý đặc biệt.

Bên trong cơ chế JIT của FEX, chúng ta theo dõi các lệnh tải-lưu bộ nhớ đang giả lập các lệnh tải-lưu x86. Khi chúng ta biết rằng một lệnh tải-lưu có thể gây ra lỗi căn chỉnh, chúng ta có cái gọi là patchpoint (điểm vá) trong mã. Đối với các lệnh tải-lưu, điều này xuất hiện dưới dạng một lệnh NOP trước hoặc sau lệnh tải-lưu. Khi lỗi căn chỉnh xảy ra tại một trong những patchpoint này, FEX sẽ bắt lỗi, vá mã từ lệnh load-acquire/store-release thành một lệnh tải-lưu cơ bản tương đương, và bao bọc lệnh đó trong một rào cản bộ nhớ dữ liệu (data memory barrier). Sau đó, nó tiếp tục thực thi!

Trước rồi sau khi vá

Toàn bộ cuộc thảo luận từ trước về việc ARMv8.0-a đã thêm các lệnh load-acquire, store-release mới lạ mắt đó? Chúng ta ngay lập tức quay lại lệnh rào cản bộ nhớ cổ điển khi hành vi căn chỉnh không khớp. Biểu đồ trước đó của chúng ta không hiển thị trường hợp xấu này, vì vậy hãy đưa vào một số dữ liệu mới.

Ồ, đó là rất nhiều dữ liệu để sàng lọc. Mặc dù một lần nữa thật tốt khi thấy phần cứng cách xa con đường "tối ưu" như thế nào khi giả lập TSO, nhưng đó không phải là điều chúng ta quan tâm ở đây. Thật thú vị khi lưu ý rằng microbench này không cho thấy nhiều sự khác biệt giữa căn chỉnh và không căn chỉnh đối với các lệnh tải/lưu thông thường, vì vậy chúng tôi chỉ tính trung bình giữa hai loại. Chúng ta sẽ loại bỏ CPU x86 và dữ liệu tải-lưu thông thường khỏi các cột ARM, vì đây không phải là các đường dẫn FEX phổ biến. Bằng cách này, chúng ta sẽ có cái nhìn tập trung hơn về việc các truy cập bộ nhớ không căn chỉnh gây hại như thế nào dưới dạng giả lập.

Bây giờ chúng ta đã có một biểu đồ dữ liệu hợp lý hơn nhiều, hãy đi từ trái sang phải và thảo luận về những gì đang diễn ra.

AmpereOne

Cái này khá thú vị, cả lệnh tải căn chỉnh và không căn chỉnh đều gần như tương đương và nằm trong phạm vi nhiễu. Điều này có nghĩa là mặc dù các lệnh tải không căn chỉnh đang bị ảnh hưởng bởi hình phạt rào cản bộ nhớ dữ liệu, CPU vẫn xử lý được. Đây có thể là trường hợp mà benchmark bị nghẽn bởi các yếu tố khác, xét đến hiệu suất thấp hơn nhiều so với các nền tảng khác.

Trong khi đó, phía lưu trữ (store) có vẻ không ở trạng thái tốt ngay cả khi không có lỗi không căn chỉnh. Nó gần như không hiển thị trên biểu đồ! Khi gặp các lệnh lưu không căn chỉnh, chúng ta đang thấy mức giảm hiệu suất khoảng ~8.5%, nhưng vì chúng ta đã bắt đầu ở mức quá thấp nên rất khó để nhận thấy. Điều này cũng trái ngược hoàn toàn với các lệnh lưu thông thường đạt ~28GB/s trong bài kiểm tra này.

Kết luận duy nhất chúng ta có thể đưa ra ở đây là Ampere đang tối ưu hóa cho một số khối lượng công việc cấp máy chủ và không thực sự khớp với hành vi phần cứng tiêu dùng. Đó là một điểm dữ liệu thú vị, nhưng người dùng của chúng tôi thường không chạy trò chơi trên loại phần cứng này.

Cortex-X4

Đây là một nhân CPU rất phổ biến đang nằm bên trong Qualcomm Snapdragon 8 Gen 3. Chúng tôi chỉ kiểm tra nhân này từ SoC để không làm biểu đồ bị quá tải dữ liệu. Khá nhiều thiết bị cầm tay được xuất xưởng với nhân này nên đây là một mục tiêu thú vị. CPU này thực sự hoạt động tốt một cách đáng ngạc nhiên khi xét đến việc nó là SoC điện thoại di động duy nhất trong danh sách này. Nhìn chung, nhân này khá phù hợp với những gì chúng ta mong đợi từ nó và các xu hướng biểu đồ đi theo Cortex thế hệ tiếp theo trong biểu đồ đó.

Các chủ đề chính cho CPU này là các lệnh tải và lưu căn chỉnh của nó khá mạnh mẽ, đạt khoảng 11.5GB/s và 6.7GB/s tương ứng. Điều thú vị là sự sụt giảm hiệu suất khi nó cần xử lý các lệnh tải-lưu không căn chỉnh, việc gặp các lệnh DMB gây phạt nhân này khoảng 50% đều đặn giữa tải và lưu trong benchmark này.

Điều này dường như ngụ ý rằng CPU có thể giữ một số lượng kha khá các lệnh LRCPC-release loadstores đang thực thi, vì vậy các lệnh DMB gây hại nhiều hơn khi chúng xuất hiện, nhưng nó không gây ra hiệu suất tồi tệ đến mức tận thế. Chỉ là mức giảm hiệu suất 50% do căn chỉnh không phải là một kết quả tuyệt vời.

Cortex-X925

Tiếp nối X4, hãy dừng chân tại DGX Spark và các nhân X925 của nó. Đây không chỉ là một nhân CPU mới hơn từ ARM, nó còn chạy trên một hệ thống có băng thông bộ nhớ lớn hơn đáng kể. 273GB/s trên nền tảng so với 76.8GB/s trước đó. Điều này có nghĩa là chúng ta thậm chí nhận được kết quả khá giống với X4, chỉ là biểu đồ mở rộng cao hơn một chút. Thú vị thay, hình phạt hiệu suất cho các truy cập không căn chỉnh gần như khớp với X4. Mặc dù có vẻ như các lệnh lưu có thể phục hồi nhanh hơn một chút, có khả năng là do bộ nhớ nhanh hơn giúp ích. Không có gì ngạc nhiên ở đây, chỉ là hiệu suất khớp nhất quán qua các thế hệ.

Oryon-3

Thiết kế nhân CPU này vừa mới ra lò từ Qualcomm. Hỗ trợ Linux vẫn đang trong quá trình hoàn thiện nhưng nó đã có một màn thể hiện mạnh mẽ. Kết quả thú vị nhất từ điều này thực sự đến từ thực tế là các lệnh LRCPC-load căn chỉnh đang khớp với hiệu suất của các lệnh tải thông thường! Điều đó có nghĩa là trong trường hợp một ứng dụng hoạt động tốt, chúng ta thường có thể mong đợi hiệu suất đầy đủ. Điều này tiếp tục với các lệnh release-store khá mạnh mẽ, mặc dù nó không hoàn toàn khớp với các lệnh lưu thông thường với chỉ 68% băng thông. Không phải là một màn thể hiện tồi chút nào.