AMD quyết định vô hiệu hóa loop buffer của Zen 4

 (chipsandcheese.com)
1 điểm bởi GN⁺ 2024-12-02 | 1 bình luận | Chia sẻ qua WhatsApp
  • Trong BIOS mới của ASRock B650 PG Lightning, loop buffer của Zen 4 không còn được quan sát thấy là nguồn cung cấp micro-op, còn khi quay về BIOS cũ thì nó được kích hoạt trở lại
  • Cấu trúc này có vẻ là tính năng nhằm giảm điện năng bằng cách lặp lại các vòng lặp nhỏ ngay ở frontend; ước tính có 144 entry ở đơn luồng, và 72 entry mỗi luồng khi SMT 2 luồng
  • Trong SPEC CPU2017, chênh lệch tổng điểm giữa khi bật/tắt loop buffer dưới 1%, nên tác động tới hiệu năng thông thường có vẻ rất nhỏ
  • Khi loop buffer bị tắt, Zen 4 cấp nhiều micro-op hơn từ op cache; băng thông op cache đủ cao so với thông lượng phía backend nên khó trở thành nút thắt frontend
  • Lý do vô hiệu hóa và tác động điện năng thực tế vẫn chưa rõ, nhưng đây là một tính năng giới hạn mà AMD hầu như không tài liệu hóa hay quảng bá, nên phần lớn người dùng và nhà phát triển khó cảm nhận được thay đổi

Vai trò và giới hạn của loop buffer trên Zen 4

  • Loop buffer là cấu trúc trong frontend CPU lưu giữ một số ít lệnh đã được nạp, cho phép tắt một phần các bước frontend khi thực thi lặp lại các vòng lặp nhỏ
    • Có thể giúp tiết kiệm điện
    • Cũng có khả năng cải thiện hiệu năng bằng cách né giới hạn ở frontend phía trước
    • Đây là kỹ thuật đã được dùng từ lâu trong các core Intel, Arm và AMD
  • Zen 4 được xem là trường hợp duy nhất trong các core AMD hiệu năng cao có loop buffer
  • Processor Programming Reference của Zen 4 đề cập loop buffer là một nguồn dispatch micro-op cùng với op cache và decoder
  • Theo các thử nghiệm performance counter, dung lượng được ước tính như sau
    • 144 entry khi chạy đơn luồng
    • Chia tĩnh thành 72 entry mỗi luồng khi bật SMT 2 luồng
  • Nếu trong vòng lặp có CALL/RET, loop buffer của Zen 4 không thể capture vòng lặp đó
  • Hướng dẫn tối ưu hóa Zen 4 của AMD không đề cập loop buffer, chỉ khuyên giữ hot code region trong dung lượng op cache

Loop buffer biến mất sau cập nhật BIOS

  • Sau khi cập nhật ASRock B650 PG Lightning lên BIOS 3.10, giám sát hiệu năng phần cứng cho thấy loop buffer không dispatch micro-op
  • Khi quay về BIOS 1.21, loop buffer được kích hoạt trở lại
  • Việc vô hiệu hóa dường như xảy ra giữa AGESA 1.0.0.6 của BIOS 1.21 và AGESA 1.2.0.2a của BIOS 3.10
  • AMD áp dụng thay đổi này mà không có thông báo hay quảng bá riêng
  • Theo các trao đổi bổ sung với nhân viên AMD tại Hot Chips 2024, loop buffer chủ yếu là tính năng nhằm tối ưu điện năng

Chênh lệch hiệu năng nhỏ trong SPEC CPU2017

  • Tổng điểm của các suite số nguyên và dấu phẩy động trong SPEC CPU2017 chỉ chênh dưới 1% giữa khi bật và tắt loop buffer
  • Mức tăng hiệu năng SMT cũng không bị ảnh hưởng bởi việc vô hiệu hóa loop buffer
  • Lý do tác động hiệu năng nhỏ là op cache của Zen 4 vốn đã cung cấp băng thông cao hơn mức mà các giai đoạn rename/allocate ở backend có thể tiêu thụ
  • Ngay cả khi loop buffer được bật, performance counter cho thấy chỉ một phần nhỏ micro-op được cấp từ loop buffer
  • Ở từng benchmark riêng lẻ cũng không thấy tổn thất lớn
    • 523.xalanbmk có một phần nhỏ nhưng đáng kể của instruction stream do loop buffer đảm nhiệm, nhưng điểm số là 9.48 với BIOS mới và 9.44 với BIOS cũ, nằm trong biên độ sai số
    • 544.nab nhận gần một phần tư micro-op từ loop buffer, nhưng điểm trên BIOS mới khi loop buffer tắt lại tăng 1,7%, đạt 11.7 so với 11.5 trước đó
    • Mức tăng này có thể là biến thiên giữa các lần chạy
  • Trong performance counter của BIOS mới, op cache đảm nhiệm phần của loop buffer và xử lý tỷ lệ lớn hơn trong instruction stream
  • Ở 507.cactuBSSN, op cache coverage giảm phần nào và decoder cung cấp khoảng một phần tư tổng số micro-op
    • Performance counter là công cụ cho thấy xu hướng tổng thể hơn là phép đo chính xác 100%
    • Frontend dispatch là speculative event, nên có thể bị ảnh hưởng bởi các lệnh được nạp sai sau một nhánh dự đoán sai

Khả năng tiết kiệm điện và hoạt động của frontend

  • Mục đích chính của loop buffer không phải tăng hiệu năng, mà là tắt theo cơ hội một phần đáng kể frontend, bao gồm cả op cache
  • Chức năng giám sát hiệu năng của Zen 4 có count mask, cho phép đếm các chu kỳ mà số event vượt ngưỡng
    • Nếu đặt ngưỡng là 1, có thể ước tính số chu kỳ mà từng nguồn micro-op thực sự cấp micro-op
    • Qua đó ước lượng khi bật loop buffer thì frontend có thể được tắt thường xuyên đến mức nào
  • Trong SPEC CPU2017, tần suất hoạt động của từng nguồn nhìn chung khớp tốt với tỷ lệ micro-op mà nguồn đó truyền đi
  • Ở một số workload, cũng có khá nhiều chu kỳ frontend không cung cấp gì
    • 502.gcc, 520.omnetpp bị ràng buộc mạnh bởi độ trễ bộ nhớ ở backend
    • Nếu out-of-order execution engine không thể giữ đủ lệnh ở trạng thái in-flight để che giấu độ trễ, frontend không thể gửi thêm xuống backend và sẽ ở trạng thái idle
  • Trong suite dấu phẩy động, 544.nab và 508.namd dùng loop buffer trong khá nhiều core cycle
    • 508.namd là workload IPC cao với trung bình 3.64 IPC, nên yêu cầu lớn về thông lượng frontend
    • Nó thân thiện với loop buffer, tạo cơ hội tắt op cache để tiết kiệm điện
  • Khi loop buffer bị tắt, op cache cấp dữ liệu cho core trong nhiều cycle hơn
    • Ở 523.xalanbmk, nếu không có loop buffer, op cache phải hoạt động thêm trong 12% core cycle
    • 548.exchange2 là workload IPC cao với trung bình 4.31 IPC, nhưng gần như không dùng loop buffer ngay cả khi được bật, còn op cache hoạt động hơn 85% core cycle
    • Ở 508.namd, tỷ lệ hoạt động của op cache tăng từ 56,67% khi bật loop buffer lên 75,1% khi tắt
  • Loop buffer 144 entry quá nhỏ để chứa phần lớn instruction stream
    • Nó có khả năng chỉ tạo hiệu ứng rõ rệt khi chương trình dành phần đáng kể thời gian trong các vòng lặp nhỏ và không bị ràng buộc bởi throughput hay latency ở backend

Quan sát trong Cyberpunk 2077

  • Tác động của việc vô hiệu hóa loop buffer tới hiệu năng game được kiểm tra bằng benchmark tích hợp của Cyberpunk 2077
  • Để tăng tính nhất quán, Core Performance Boost được vô hiệu hóa trên Ryzen 9 7950X3D và toàn bộ core bị giới hạn ở 4.2GHz
    • Đặt bit 25 của thanh ghi Hardware Configuration MSR 0xC0010015
    • RX 6900 XT bị giới hạn ở 2GHz
    • Thiết lập benchmark là 1080p, preset medium, không upscaling
  • Khi ghim game vào VCache die, việc vô hiệu hóa loop buffer gần như không ảnh hưởng tới hiệu năng
  • Khi ghim vào non-VCache die, quan sát thấy mất 5% hiệu năng khi vô hiệu hóa loop buffer, nhưng nguyên nhân chưa được xác định
    • Benchmark được chạy lại khoảng sáu lần
  • Trung bình, loop buffer đảm nhiệm khoảng 22% instruction stream của Cyberpunk 2077, cho thấy game này thân thiện với loop buffer hơn dự kiến
    • Sau khi vô hiệu hóa loop buffer, tỷ lệ cung cấp micro-op của op cache tăng từ 62% lên 82%
  • Game này không phải workload IPC cao: trung bình 0.89 IPC khi tắt loop buffer và 1.02 IPC khi bật
    • Băng thông frontend không phải yếu tố đáng cân nhắc lớn
    • Có khả năng bị backend bound hoặc bị ràng buộc bởi độ trễ branch predictor
  • Khi chạy trên VCache die, performance counter cho thấy trung bình 1.25 IPC khi bật loop buffer và 1.07 IPC khi tắt
    • Cũng quan sát thấy mức giảm hiệu năng nhỏ trên BIOS mới
    • Ở mức khoảng 155 FPS, có thể đã tiến gần hơn tới nút thắt phía GPU

Bất định trong kết quả core power counter

  • Để xác nhận liệu thực thi qua loop buffer có cải thiện hiệu quả điện năng hay không, core power counter của Zen 4 cũng được xem xét
  • Benchmark instruction bandwidth được sửa để không dùng CALL/RET trong đoạn kiểm thử
    • Vì nếu có CALL/RET thì Zen 4 không dùng loop buffer
  • Thử nghiệm được ghim vào một core; đọc Core Energy Status MSR trước và sau khi nhảy tới mảng kiểm thử để tính công suất trung bình
  • Core Performance Boost bị vô hiệu hóa vì kết quả đọc điện năng dao động lớn
  • Trên BIOS cũ, Core Energy Status MSR báo trung bình 6W khi lấy NOP từ op cache, và mức điện năng thấp hơn nhiều khi lấy từ loop buffer
  • Ngay cả khi tăng kích thước mảng kiểm thử lên 128KB, vừa trong dung lượng L2, để hạ op cache coverage xuống dưới 1%, công suất core trung bình vẫn được báo là 1.5W
    • Đây là kết quả không khớp với tình huống lẽ ra mức dùng decoder và L2 fetch path phải tăng
  • Trên BIOS mới, bài test op cache báo trung bình 1.68W, và bài test chủ yếu cấp qua decoder từ L2 cũng báo mức điện năng gần như tương tự
  • Chức năng giám sát điện năng của AMD có thể là mô hình hóa điện năng chứ không phải đo thực tế
    • Có thể phương pháp mô hình hóa đã thay đổi giữa các phiên bản BIOS, hoặc mô hình điện năng không chính xác
    • Không có phần cứng để đo trực tiếp tại đầu nối 12V EPS hay tương tự, nên chưa thực hiện xác minh thêm

Lý do vô hiệu hóa và góc nhìn của nhà phát triển

  • Chưa rõ vì sao AMD vô hiệu hóa loop buffer của Zen 4
  • Các tính năng CPU đôi khi bị vô hiệu hóa vì lỗi phần cứng
    • LSD, loop buffer của Intel Skylake, từng bị vô hiệu hóa do lỗi liên quan đến partial register access trong các vòng lặp ngắn khi cả hai luồng SMT đều hoạt động
  • Zen 4 là nỗ lực đầu tiên của AMD đưa loop buffer vào CPU hiệu năng cao, và việc xác minh một tính năng triển khai lần đầu là khó
  • Có khả năng AMD đã phát hiện nội bộ một lỗi chưa lộ ra ngoài và tắt loop buffer như biện pháp phòng ngừa
  • Tác động hiệu năng có vẻ gần như không có hoặc rất nhỏ, vì băng thông op cache là đủ
  • Tác động điện năng chưa rõ, nhưng có thể nhỏ và cũng khó đo
  • AMD hầu như không tài liệu hóa hay quảng cáo loop buffer ngoài một dòng trong Processor Programming Reference
    • Điều này trái ngược với cách Intel thường tài liệu hóa loop buffer của mình và khuyến nghị nhà phát triển tận dụng nó trong hướng dẫn tối ưu hóa
  • Loop buffer của Zen 4 là tính năng giới hạn, không hữu dụng bằng op cache do dung lượng thấp và hạn chế CALL/RET
  • Nếu tối ưu hóa có chủ ý cho loop buffer của Zen 4 trên BIOS cũ, có thể cân nhắc các điều kiện sau
    • Giữ vòng lặp dưới 144 micro-op
    • Nếu hai luồng dùng chung một core vật lý, hãy tính tới mức khoảng một nửa con số đó
    • Với các hàm được gọi bên trong vòng lặp nhỏ, cân nhắc inline để tránh CALL/RET
  • Ngay cả khi thực hiện các tối ưu hóa này, khả năng cao là gần như không có phần thưởng

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-12-02
Các ý kiến trên Hacker News

  • Có suy đoán rằng tính năng này bị vô hiệu hóa để cố ngăn một lỗ hổng phần cứng chưa được công bố

    • Bài viết nhìn chung cũng suy đoán tương tự: Zen 4 là lần đầu AMD thử đưa bộ đệm vòng lặp vào CPU hiệu năng cao, và việc xác minh một triển khai đầu tiên luôn khó
      Cũng không quá khi tưởng tượng rằng nội bộ AMD đã phát hiện một lỗi mà chưa ai gặp phải, rồi tắt bộ đệm vòng lặp vì quá thận trọng. Ở giai đoạn này trong vòng đời của nhân, khó nghĩ ra lý do nào khác để AMD động vào frontend của Zen 4
    • Trên thực tế có thể còn nhiều thứ khác đã bị vô hiệu hóa hơn. Các con số khá bất ngờ: trong Cyberpunk 2077, khi chạy trên die VCache, bộ đếm hiệu năng cho thấy IPC trung bình là 1,25 khi bật bộ đệm vòng lặp và 1,07 khi tắt, vậy mà BIOS mới vẫn có sụt giảm hiệu năng nhẹ
      Cá nhân tôi thấy có mùi biện pháp giảm thiểu bằng microcode, nhưng dĩ nhiên phải chờ CVE
    • Việc âm thầm vô hiệu hóa cũng là rủi ro lớn. Vì nó phát tín hiệu rằng họ đã biết mức độ nghiêm trọng của vấn đề và đánh giá nó đủ nghiêm trọng để vá
      Nếu không công bố lỗ hổng, phía bị ảnh hưởng không có cách nào bắt đầu ứng phó ngoài sự hoang tưởng thuần túy. Công bố lỗ hổng cũng là một cách chuyển trách nhiệm cuối cùng sang người dùng cuối: kiểu như nếu không cập nhật thì đừng phàn nàn. Việc công bố hiếm khi dẫn tới trách nhiệm sản phẩm, và tôi cũng không nhớ Meltdown hay Spectre có vấn đề trách nhiệm như vậy. Vì thế tôi sẽ không khẳng định AMD cố tình che giấu
    • Có vẻ là đáp án đúng, nhưng không thể nói thêm :(

  • Bài viết dường như gợi ý rằng bộ đệm vòng lặp không đem lại lợi ích hiệu năng hay điện năng
    Nếu vậy thì đây có thể là trường hợp kinh điển: “một nhóm kỹ sư mất vài tháng làm một tính năng mới hào nhoáng nhưng thực tế không có lợi ích, rồi vẫn có người tung ra để giữ thể diện”. Trong các đội phần mềm, tôi cũng từng thấy chuyện đề xuất viết lại codebase để loại bỏ sự phình to legacy và tăng hiệu năng, cuối cùng số dòng code lại tăng còn hiệu năng thì tệ hơn. Trong cả hai trường hợp lẽ ra đều không nên phát hành

    • Dù vậy, lý do họ vẫn phát hành là vì có thể tắt bằng cập nhật firmware, và việc thay đổi lớn bố trí phần cứng vật lý giữa chừng trong thiết kế có khả năng gây tác động còn tệ hơn
    • Nếu sau khi đã đưa vào nhân họ mới nhận ra nó chẳng giúp ích mấy, thì bản thân việc loại bỏ nó rõ ràng là một rủi ro
    • Bài viết cũng nói rằng nhìn chung khó đo mức tiêu thụ điện, nên không thể kết luận tính năng này hoàn toàn không có tác động, và thật ra không nên kết luận như vậy
      Khó tin rằng đội kỹ thuật AMD lại thiếu nguyên tắc đến mức để một tính năng phần cứng vô giá trị tiêu tốn diện tích và điện năng; ở đây tôi nghiêng về khả năng Chips 'n Cheese không đo được tác động
    • Tôi làm ở một công ty phần cứng khá nổi tiếng, và phía phần mềm hiện đang ám ảnh với việc làm một cái gì đó, dù lợi ích chưa được chứng minh đầy đủ ngoài một số trường hợp sử dụng hẹp hoặc benchmark mục tiêu
      Rất bực bội, nhưng không ai muốn dành thời gian nghiên cứu trước. Thúc đẩy một dự án mới thường dễ làm cấp trên hài lòng và ít bị hỏi hơn
    • Cũng có khả năng khác là benchmark điện năng chính xác. Bộ đệm từng tiết kiệm điện, nhưng sau đó ở cấp microcode họ tìm được tối ưu tốt hơn giúp đường đi thông thường tiết kiệm điện hơn, khiến bộ đệm lại trở thành thứ tiêu thụ điện

  • Đoạn thú vị nhất trong bài là phần này: cách nhìn tốt nhất về bộ đệm vòng lặp của Zen 4 là coi nó như tín hiệu rằng AMD có năng lực dư để các kỹ sư thử nghiệm điều gì đó
    Lần này có thể không có kết quả, nhưng để kỹ sư thử nghiệm với các tính năng rủi ro thấp và tác động thấp là một cách tốt để xây dựng sự tự tin. Hy vọng trong tương lai sẽ thấy nhiều sự tự tin như vậy hơn

  • Phần “kỳ lạ là nếu cố định vào die non-VCache, hiệu năng game giảm 5% khi vô hiệu hóa bộ đệm vòng lặp. Không rõ lý do” khiến tôi nghĩ rằng nếu có đo điện năng chi tiết hơn thì có thể xác định liệu có liên quan đến ngân sách nhiệt/điện hay không
    Tính năng này cũng có vẻ được thiết kế nhằm tiết kiệm điện

    • Ở đây không có đủ chi tiết. CCD thứ hai trên chip Ryzen có chất lượng binning thấp hơn CCD đầu tiên ngay cả trên chip non-X3D, và mỗi chip đều khác nhau
      Trên chip non-X3D của tôi, hầu hết nhân CCD0 lên được 5,6~5,75GHz, nhưng nhân CCD1 dừng ở 5,4~5,5GHz. Chip V-Cache của Zen 4 chịu phạt xung nhịp lớn, nhưng bộ nhớ đệm bù lại nhiều hơn thế. Cần xem liệu họ có thử cả trạng thái bật và tắt tính năng trên CCD1 của cùng một chip hay không, và có cố tách các thay đổi khác như bản sửa bảo mật hay không; trong bài, chính họ thừa nhận là “không”. Muốn làm đúng thì phải tìm cách chỉ tắt riêng tính năng này trên BIOS đang bật tính năng, rồi thử cả hai bên trên cùng một chip; dù vậy kết quả vẫn có thể không chính xác vì các điều kiện rẽ nhánh khác. Nếu có toàn bộ hồ sơ hiệu năng thì độ chính xác sẽ tăng, nhưng có lẽ chỉ kỹ sư AMD mới làm được
    • Họ nói nó đã bị vô hiệu hóa ở đâu đó giữa hai phiên bản UEFI được thử nghiệm. Hẳn cũng có các thay đổi khác đi kèm, nên phép đo không phải là A/B test nghiêm ngặt

  • Có vẻ nó quá nhỏ để tạo khác biệt thực sự và chỉ có ý nghĩa trong những tình huống rất cụ thể. Nếu làm lớn hơn, chi phí triển khai có lẽ quá cao so với lợi ích
    Dù vậy, một số workload vẫn sẽ có hồi quy nhẹ, nhưng AMD cũng đã có các cải thiện hiệu năng nhỏ sau khi phát hành. Trên Zen 4, lẽ ra họ nên biến nó thành một tùy chọn BIOS. Việc có vẻ họ không làm vậy gợi ý khả năng có lỗi hoặc vấn đề bảo mật

    • Việc âm thầm vô hiệu hóa một tính năng mà đa số người dùng không nhận ra nhưng làm frontend phức tạp hơn, đem lại cảm giác họ đã bật bit “chicken” này để tránh hoặc trì hoãn công bố lỗi phần cứng, trong khi biện pháp giảm thiểu đã được triển khai. Mấy nhà cung cấp chết tiệt, bao giờ mới chịu học đây

  • Theo giai thoại, một trong số ít khác biệt giữa 68000 năm 1979 và 68010 năm 1982 là “loop mode”, tức việc thêm bộ đệm vòng lặp 6 byte

    • Điều quan trọng hơn nhiều là đã sửa hỗ trợ MMU. Ban đầu 68000 làm mất một phần trạng thái cần thiết để khôi phục sau lỗi trang, và cách né thì xấu xí lẫn tốn kém
      Đó là chạy hai CPU lệch nhau một chu kỳ và tiêm một ngắt có thể khôi phục vào CPU thứ hai. Dù vậy, nếu muốn một CPU có MMU, tập lệnh 32-bit và bus địa chỉ 24-bit thì có vẻ nó vẫn rẻ hơn các lựa chọn khác thời đó. Hẳn là một thời kỳ thật dữ dội
    • Thú vị. Với bộ đệm vòng lặp nhỏ, tôi khá thích các lõi Forth của GreenArrays
      Một word 18-bit chứa 4 lệnh, và một opcode sẽ giảm bộ đếm vòng lặp rồi quay lại đầu word. Khi đó nó có thể chạy nhanh hơn đáng kể
    • Bộ đệm vòng lặp của 68010 gần như vô dụng. Không chỉ vì nó chỉ có 6 byte, mà còn vì chỉ chứa được hai lệnh
      Một trong số đó phải là lệnh vòng lặp (DBcc), nên thân vòng lặp phải là một lệnh duy nhất. Thứ gần như duy nhất thực sự có thể nhanh hơn là kiểu memcpy chưa được tối ưu

  • Thú vị là trên Cortex-A15, đây lại là tính năng thiết kế cốt lõi. Tôi tò mò liệu có số liệu hiệu quả trên các chip khác không
    Với những thiết bị có vòng đời thiết kế dài hơn như console, ít nhất có lẽ cũng có thể dùng nó làm mục tiêu tối ưu hóa

    • Tôi cũng tò mò. Tôi đoán lợi ích từ bộ đệm vòng lặp trên bất kỳ kiến trúc RISC nào cũng sẽ tương đối nhỏ
      Vì điểm chính của RISC là việc nạp và giải mã lệnh dễ hơn nhiều, hoặc gần như không đáng kể

  • Tôi có một 7950X3D, nâng cấp từ Skylake 6700K. Có vẻ trong vô thức tôi bị hấp dẫn bởi những con chip có bộ đệm vòng lặp phần cứng bị vô hiệu hóa bằng phần mềm

    • Nếu sau này bạn định mua máy mới thì báo trước nhé. Để chúng tôi còn tránh!

  • Bài viết thú vị, nhưng tôi không biết bộ đệm vòng lặp chiếm bao nhiêu diện tích trên die
    Nếu loại bỏ nó khỏi các chip tương lai, tôi tò mò liệu phần diện tích đó có thể dùng cho thứ hữu ích hơn như cache L2 lớn hơn không

    • Tôi nghĩ ở hầu hết chip hiện đại, ràng buộc dây dẫn lớn hơn diện tích bề mặt. Có thể tạo ra rất nhiều tính năng, nhưng cấp cả nguồn điện lẫn tín hiệu đã chuẩn hóa cho chúng mới thật sự là cực hình
    • Theo tôi hiểu thì đây là một tối ưu hóa khá nhỏ ở front-end. Ngay từ đầu số entry đã không nhiều, chỉ 144, nên diện tích tiết kiệm được có lẽ không đáng kể
      Về lý thuyết, bộ đệm vòng lặp có thể tiết kiệm điện hoặc tăng hiệu năng trong các vòng lặp chặt. Trên thực tế có vẻ nó không làm được cả hai, và AMD đã loại bỏ hoàn toàn trong Zen 5
    • Nhìn vào sơ đồ, có vẻ bộ đệm vòng lặp dùng cùng vùng lưu trữ với hàng đợi vi tác vụ vốn đã tồn tại
      Nếu đúng vậy thì nghe hợp lý, và chi phí diện tích chỉ là phần logic điều khiển bổ sung. Phần đắt nhất có lẽ là phát hiện vòng lặp ngay từ đầu, nhưng so với kích thước hàng đợi thì có vẻ khá nhỏ
    • Bài viết nói là 144 entry vi tác vụ cho mỗi lõi. Tôi không biết mỗi entry bao nhiêu byte, nhưng cache L2 ngày nay khoảng 1MB mỗi lõi, nên ngay cả giả sử phần lớn diện tích die của bộ đệm vòng lặp là lưu trữ thì cũng sẽ không tạo ra khác biệt đáng chú ý

  • Phân tích trong mục “điện năng” có vẻ chưa chia cho số lệnh thực thi mỗi giây
    Để thấy lợi ích của bộ đệm vòng lặp này, gần như chắc chắn phải xem năng lượng trên mỗi lệnh, chứ không phải năng lượng mỗi giây, tức công suất (watt)

    • Số chu kỳ clock cần cho mỗi lệnh khác nhau, và cũng khác giữa các thế hệ kiến trúc như từ Zen 4 sang Zen 5. Vì vậy trừ khi workload tạo ra chính xác cùng số lệnh trên mỗi chu kỳ, việc này không khả thi, mà điều đó là bất khả thi vì multithreading và cách xử lý công việc
      Ngay cả thứ tự và nội dung RAM cũng có thể thay đổi mọi thứ. Có thể chạy hàng trăm lần khi bật và tắt để tách bạch ở một mức nào đó, nhưng sẽ tốn rất nhiều thời gian và vẫn không chính xác 100%. Chỉ riêng việc tắt tính năng cũng có thể khiến code đi nhánh khác và làm mọi bố trí thay đổi. Tôi không biết cụ thể vấn đề này, nhưng từng thấy trường hợp tắt một tính năng khiến tải chuyển từ đơn vị số nguyên sang FPU hoặc GPU, hoặc thay vì loại bỏ 5 lệnh thì lại thêm 2 lệnh