AMD ตัดสินใจปิดใช้งาน Loop Buffer ของ Zen 4

 (chipsandcheese.com)
1 คะแนน โดย GN⁺ 2024-12-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ใน BIOS ใหม่ของ ASRock B650 PG Lightning ไม่พบว่า loop buffer ของ Zen 4 เป็นแหล่งจ่าย micro-op อีกต่อไป และเมื่อย้อนกลับไปใช้ BIOS รุ่นเก่าก็กลับมาเปิดใช้งานอีกครั้ง
  • โครงสร้างนี้ดูเหมือนเป็นฟีเจอร์ที่ช่วยลดพลังงานด้วยการประมวลผลลูปขนาดเล็กซ้ำใน frontend โดยประเมินว่ามี 144 entries สำหรับเธรดเดียว และเมื่อใช้ SMT 2 เธรดจะแบ่งเป็น 72 entries ต่อเธรด
  • ใน SPEC CPU2017 คะแนนรวมระหว่างการเปิด/ปิด loop buffer ต่างกัน น้อยกว่า 1% จึงดูเหมือนส่งผลต่อประสิทธิภาพทั่วไปน้อยมาก
  • เมื่อปิด loop buffer, Zen 4 จะจ่าย micro-op จาก op cache มากขึ้น และ bandwidth ของ op cache ก็เพียงพอเหนือกว่า throughput ของส่วน backend ทำให้ยากที่จะกลายเป็นคอขวดที่ frontend
  • เหตุผลในการปิดใช้งานและผลต่อพลังงานจริงยังไม่แน่ชัด แต่เนื่องจากเป็นฟีเจอร์จำกัดที่ AMD แทบไม่ได้ทำเอกสารหรือโปรโมต ผู้ใช้และนักพัฒนาส่วนใหญ่จึงน่าจะไม่รู้สึกถึงความเปลี่ยนแปลง

บทบาทและข้อจำกัดของ Loop Buffer ใน Zen 4

  • Loop buffer คือโครงสร้างใน frontend ของ CPU ที่เก็บคำสั่งจำนวนเล็กน้อยซึ่งถูกดึงมาแล้ว เพื่อให้สามารถปิดบางขั้นตอนของ frontend ได้เมื่อรันลูปขนาดเล็กซ้ำ
    • อาจช่วยลดการใช้พลังงานได้
    • มีโอกาสช่วยเพิ่มประสิทธิภาพโดยเลี่ยงข้อจำกัดของ frontend ส่วนหน้า
    • เป็นเทคนิคที่ใช้กันมานานในคอร์ของ Intel, Arm และ AMD
  • เท่าที่ทราบ Zen 4 เป็นกรณีเดียวในบรรดาคอร์ AMD ประสิทธิภาพสูงที่มี loop buffer
  • Processor Programming Reference ของ Zen 4 ระบุว่า loop buffer เป็นแหล่ง dispatch micro-op ร่วมกับ op cache และ decoder
  • จากการทดลองด้วย performance counter ประเมินความจุได้ดังนี้
    • เมื่อรันเธรดเดียว 144 entries
    • เมื่อเปิดใช้ SMT 2 เธรด จะแบ่งแบบคงที่เป็น 72 entries ต่อเธรด
  • หากในลูปมี CALL/RET อยู่ loop buffer ของ Zen 4 จะไม่สามารถจับลูปนั้นได้
  • คู่มือ optimization ของ AMD สำหรับ Zen 4 ไม่ได้กล่าวถึง loop buffer และให้เพียงคำแนะนำให้รักษา hot code region ให้อยู่ภายในความจุของ op cache

Loop Buffer ที่หายไปหลังอัปเดต BIOS

  • หลังอัปเดต ASRock B650 PG Lightning เป็น BIOS 3.10 การ monitoring ประสิทธิภาพฮาร์ดแวร์แสดงว่า loop buffer ไม่ dispatch micro-op
  • เมื่อย้อนกลับเป็น BIOS 1.21 loop buffer ก็กลับมาเปิดใช้งานอีกครั้ง
  • การปิดใช้งานน่าจะเกิดขึ้นระหว่าง AGESA 1.0.0.6 ของ BIOS 1.21 และ AGESA 1.2.0.2a ของ BIOS 3.10
  • AMD นำการเปลี่ยนแปลงนี้มาใช้โดยไม่มีการประกาศหรือโปรโมตแยกต่างหาก
  • จากการพูดคุยเพิ่มเติมกับพนักงาน AMD ในงาน Hot Chips 2024 ระบุว่า loop buffer เป็นฟีเจอร์เพื่อ optimization ด้านพลังงาน เป็นหลัก

ความต่างด้านประสิทธิภาพเล็กน้อยที่เห็นใน SPEC CPU2017

  • คะแนนรวมของ suite จำนวนเต็มและ floating-point ใน SPEC CPU2017 ต่างกันระหว่างเปิด/ปิด loop buffer เพียง น้อยกว่า 1%
  • การเพิ่มประสิทธิภาพจาก SMT ก็ไม่ได้รับผลกระทบจากการปิด loop buffer
  • เหตุผลที่ผลกระทบด้านประสิทธิภาพน้อย คือ op cache ของ Zen 4 ให้ bandwidth ได้มากกว่าที่ขั้นตอน rename/allocate ใน backend จะบริโภคได้อยู่แล้ว
  • แม้เปิด loop buffer อยู่ จาก performance counter ก็พบว่ามี micro-op เพียงส่วนน้อยที่ถูกจ่ายจาก loop buffer
  • ใน benchmark รายตัวก็ไม่พบการสูญเสียครั้งใหญ่
    • 523.xalanbmk มี loop buffer รับผิดชอบสัดส่วนเล็กแต่มีนัยสำคัญของ instruction stream แต่คะแนนคือ BIOS ใหม่ 9.48 และ BIOS เก่า 9.44 ซึ่งอยู่ในช่วงความคลาดเคลื่อน
    • 544.nab ได้รับ micro-op เกือบหนึ่งในสี่จาก loop buffer แต่ใน BIOS ใหม่ที่ปิด loop buffer คะแนนกลับเพิ่มเป็น 11.7 จากเดิม 11.5 หรือเพิ่มขึ้น 1.7%
    • การเพิ่มขึ้นนี้อาจเป็น run-to-run variance
  • ใน performance counter ของ BIOS ใหม่ op cache เข้ามารับส่วนของ loop buffer และประมวลผลสัดส่วนที่มากขึ้นของ instruction stream
  • ใน 507.cactuBSSN พบรูปแบบที่ op cache coverage ลดลงบางส่วน และ decoder จ่าย micro-op ประมาณหนึ่งในสี่ของทั้งหมด
    • performance counter เป็นเครื่องมือที่แสดงแนวโน้มโดยรวม มากกว่าจะเป็นการวัดที่แม่นยำ 100%
    • frontend dispatch เป็น speculative event จึงอาจได้รับผลจากคำสั่งที่ถูกดึงมาผิดหลัง branch ที่ทำนายผิด

ความเป็นไปได้ในการประหยัดพลังงานและกิจกรรมของ Frontend

  • เป้าหมายหลักของ loop buffer ไม่ใช่การเพิ่มประสิทธิภาพ แต่เป็นการปิด frontend ส่วนใหญ่ รวมถึง op cache เมื่อมีโอกาส
  • ฟีเจอร์ performance monitoring ของ Zen 4 มี count mask ที่สามารถนับ cycle ที่จำนวน event เกิน threshold ได้
    • หากตั้ง threshold เป็น 1 จะสามารถประเมินจำนวน cycle ที่แต่ละแหล่งจ่าย micro-op ได้จ่าย micro-op จริง
    • วิธีนี้ช่วยประเมินได้ว่าเมื่อเปิด loop buffer จะสามารถปิด frontend ได้บ่อยเพียงใด
  • ใน SPEC CPU2017 ความถี่ที่แต่ละแหล่งจ่ายทำงานโดยรวมสอดคล้องกับสัดส่วน micro-op ที่แหล่งนั้นส่งมอบ
  • ใน workload บางส่วน มี cycle จำนวนมากที่ frontend ไม่ได้จ่ายอะไรเลย
    • 502.gcc, 520.omnetpp ถูกจำกัดอย่างมากด้วย backend memory latency
    • หาก out-of-order execution engine ไม่สามารถคงคำสั่งไว้ในสถานะ flight ได้มากพอที่จะซ่อน latency ได้ frontend ก็จะส่งต่อไปยัง backend ไม่ได้และเข้าสู่สถานะ idle
  • ใน suite floating-point, 544.nab และ 508.namd ใช้ loop buffer เป็นเวลาค่อนข้างมากในหน่วย core cycle
    • 508.namd เป็น workload แบบ high IPC โดยมีค่าเฉลี่ย 3.64 IPC จึงต้องการ frontend throughput สูง
    • เป็น workload ที่เป็นมิตรกับ loop buffer ทำให้มีโอกาสปิด op cache และประหยัดพลังงาน
  • เมื่อปิด loop buffer, op cache จะจ่ายงานให้คอร์เป็นจำนวน cycle ที่มากขึ้น
    • ใน 523.xalanbmk หากไม่มี loop buffer, op cache ต้องทำงานเพิ่มอีก 12% ของ core cycle
    • 548.exchange2 เป็น workload แบบ high IPC ที่มีค่าเฉลี่ย 4.31 IPC แต่แม้เปิด loop buffer ก็แทบไม่ได้ใช้ และ op cache ทำงานมากกว่า 85% ของ core cycle
    • ใน 508.namd สัดส่วนการทำงานของ op cache เพิ่มจาก 56.67% เมื่อเปิด loop buffer เป็น 75.1% เมื่อปิด
  • loop buffer ขนาด 144 entries เล็กเกินกว่าจะเก็บ instruction stream ได้เป็นส่วนใหญ่
    • น่าจะให้ผลชัดเจนเฉพาะเมื่อโปรแกรมใช้เวลารันส่วนใหญ่ในลูปขนาดเล็ก และไม่ถูกจำกัดด้วย backend throughput หรือ latency

สิ่งที่สังเกตได้ใน Cyberpunk 2077

  • ตรวจสอบผลของการปิด loop buffer ต่อประสิทธิภาพเกมด้วย benchmark ในตัวของ Cyberpunk 2077
  • เพื่อเพิ่มความสม่ำเสมอ ได้ปิด Core Performance Boost บน Ryzen 9 7950X3D และจำกัดทุกคอร์ไว้ที่ 4.2GHz
    • ตั้งค่า bit 25 ของ Hardware Configuration register MSR 0xC0010015
    • จำกัด RX 6900 XT ไว้ที่ 2GHz
    • ตั้งค่า benchmark เป็น 1080p, medium preset, ไม่ใช้ upscaling
  • เมื่อตรึงเกมไว้บน VCache die การปิด loop buffer แทบไม่ส่งผลต่อประสิทธิภาพ
  • เมื่อตรึงไว้บน non-VCache die พบว่าเมื่อปิด loop buffer มี ประสิทธิภาพลดลง 5% แต่ยังยืนยันสาเหตุไม่ได้
    • benchmark ถูกรันซ้ำประมาณหกครั้ง
  • โดยเฉลี่ย Cyberpunk 2077 มี loop buffer รับผิดชอบ instruction stream ราว 22% ซึ่งเป็นมิตรกับ loop buffer มากกว่าที่คาด
    • หลังปิด loop buffer สัดส่วนการจ่าย micro-op ของ op cache เพิ่มจาก 62% เป็น 82%
  • เกมนี้ไม่ใช่ workload แบบ high IPC โดยมีค่าเฉลี่ย 0.89 IPC เมื่อปิด loop buffer และ 1.02 IPC เมื่อเปิด
    • frontend bandwidth ไม่ใช่ประเด็นสำคัญ
    • อาจเป็น backend bound หรือถูกจำกัดด้วย branch predictor delay
  • เมื่อรันบน VCache die, performance counter แสดงค่าเฉลี่ย 1.25 IPC เมื่อเปิด loop buffer และ 1.07 IPC เมื่อปิด
    • พบประสิทธิภาพลดลงเล็กน้อยบน BIOS ใหม่ด้วย
    • ที่ระดับประมาณ 155 FPS อาจเข้าใกล้คอขวดฝั่ง GPU มากขึ้น

ความไม่แน่นอนของผลลัพธ์จาก Core Power Counter

  • เพื่อตรวจสอบว่าการรันผ่าน loop buffer ช่วยเพิ่มประสิทธิภาพด้านพลังงานหรือไม่ จึงดู core power counter ของ Zen 4 ด้วย
  • instruction bandwidth benchmark ถูกปรับไม่ให้ใช้ CALL/RET ในช่วงทดสอบ
    • เพราะหากมี CALL/RET, Zen 4 จะไม่ใช้ loop buffer
  • การทดสอบถูกตรึงไว้บนหนึ่งคอร์ และอ่าน Core Energy Status MSR ก่อนและหลังการกระโดดไปยัง test array เพื่อคำนวณพลังงานเฉลี่ย
  • ปิด Core Performance Boost เพราะค่าพลังงานที่อ่านได้แกว่งมาก
  • ใน BIOS เก่า Core Energy Status MSR แสดงค่าเฉลี่ย 6W เมื่อนำ NOP จาก op cache และแสดงพลังงานต่ำกว่ามากเมื่อนำจาก loop buffer
  • แม้เพิ่มขนาด test array ถึง 128KB ซึ่งพอดีกับความจุ L2 เพื่อลด op cache coverage ให้ต่ำกว่า 1% ก็ยังแสดงค่า core power เฉลี่ย 1.5W
    • เป็นผลที่ไม่สอดคล้องกับสถานการณ์ที่ควรมีการใช้ decoder และ L2 fetch path เพิ่มขึ้น
  • ใน BIOS ใหม่ การทดสอบ op cache แสดงค่าเฉลี่ย 1.68W และการทดสอบที่ให้ decoder จ่ายงานหลักจาก L2 ก็แสดงพลังงานแทบเท่ากัน
  • ฟีเจอร์ power monitoring ของ AMD อาจเป็นการสร้างแบบจำลองพลังงาน ไม่ใช่การวัดจริง
    • อาจมีการเปลี่ยนวิธี modeling ระหว่าง BIOS แต่ละเวอร์ชัน หรือ power model อาจไม่ตรง
    • ไม่มีฮาร์ดแวร์สำหรับวัดโดยตรงที่ตัวเชื่อมต่อ 12V EPS เป็นต้น จึงไม่ได้ตรวจสอบเพิ่มเติม

เหตุผลในการปิดใช้งานและมุมมองของนักพัฒนา

  • ยังไม่ทราบเหตุผลที่ AMD ปิดใช้งาน loop buffer ของ Zen 4
  • ฟีเจอร์ของ CPU บางครั้งถูกปิดใช้งานเพราะบั๊กฮาร์ดแวร์
    • มีกรณีที่ LSD ซึ่งเป็น loop buffer ของ Intel Skylake ถูกปิดใช้งานเพราะบั๊กเกี่ยวกับ partial register access ในลูปสั้นเมื่อเปิดใช้งาน SMT ทั้งสองเธรด
  • Zen 4 เป็นความพยายามครั้งแรกของ AMD ในการใส่ loop buffer ลงใน CPU ประสิทธิภาพสูง และการตรวจสอบฟีเจอร์ที่เป็น implementation แรกนั้นทำได้ยาก
  • AMD อาจพบบั๊กภายในที่ไม่เปิดเผยต่อภายนอก และปิด loop buffer เป็นมาตรการป้องกัน
  • ผลต่อประสิทธิภาพดูเหมือนแทบไม่มีหรือมีน้อยมาก เพราะ bandwidth ของ op cache เพียงพอ
  • ผลต่อพลังงานยังไม่ทราบ แต่อาจเล็กและวัดได้ยาก
  • AMD แทบไม่ได้ทำเอกสารหรือโฆษณา loop buffer เลย นอกเหนือจากหนึ่งบรรทัดใน Processor Programming Reference
    • ตรงข้ามกับ Intel ที่มักทำเอกสารเกี่ยวกับ loop buffer ของตน และแนะนำในคู่มือ optimization ให้นักพัฒนาใช้ประโยชน์
  • loop buffer ของ Zen 4 เป็นฟีเจอร์จำกัดที่มีประโยชน์ไม่เท่า op cache เพราะความจุต่ำและข้อจำกัดเรื่อง CALL/RET
  • หากจะ optimize โดยคำนึงถึง loop buffer ของ Zen 4 บน BIOS เก่า อาจพิจารณาเงื่อนไขต่อไปนี้
    • รักษาลูปให้มีขนาดต่ำกว่า 144 micro-ops
    • หากมีสองเธรดแชร์ physical core ให้พิจารณาความจุประมาณครึ่งหนึ่ง
    • พิจารณา inline ฟังก์ชันที่ถูกเรียกในลูปขนาดเล็ก เพื่อหลีกเลี่ยง CALL/RET
  • แม้ทำ optimization แบบนี้ ผลตอบแทนก็น่าจะไม่มีในกรณีส่วนใหญ่

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-12-02
ความคิดเห็นจาก Hacker News

  • มีการคาดเดาว่าฟีเจอร์นี้อาจถูกปิดใช้งานเพื่อพยายามป้องกัน ช่องโหว่ฮาร์ดแวร์ ที่ยังไม่ถูกเปิดเผย

    • ในบทความก็เดาไปในทำนองเดียวกันโดยรวม: Zen 4 เป็นความพยายามครั้งแรกของ AMD ในการใส่ลูปบัฟเฟอร์ลงใน CPU ประสิทธิภาพสูง และการตรวจสอบความถูกต้องของการใช้งานครั้งแรกนั้นยากเสมอ
      ก็ไม่ใช่เรื่องเกินจริงที่จะจินตนาการว่า AMD พบข้อบกพร่องที่ไม่มีใครภายในเคยเจอ และปิดลูปบัฟเฟอร์ด้วยความระมัดระวังเกินเหตุ ในช่วงวงจรชีวิตของคอร์ ณ จุดนี้ นึกไม่ค่อยออกว่า AMD จะมีเหตุผลอื่นใดในการไปแตะฟรอนต์เอนด์ของ Zen 4
    • ในความเป็นจริง อาจมีหลายอย่างกว่านี้ที่ถูกปิดใช้งาน ตัวเลขค่อนข้างน่าประหลาดใจ: เมื่อรัน Cyberpunk 2077 บนได VCache การเปิดลูปบัฟเฟอร์ทำให้ตัวนับประสิทธิภาพแสดงค่า IPC เฉลี่ย 1.25 ส่วนการปิดอยู่ที่ 1.07 แต่ BIOS ใหม่กลับมีประสิทธิภาพลดลงเล็กน้อย
      ส่วนตัวแล้วรู้สึกเหมือนเป็น มาตรการบรรเทาระดับไมโครโค้ด แต่แน่นอนว่าต้องรอดู CVE ก่อน
    • การปิดใช้งานอย่างเงียบ ๆ ก็เสี่ยงมากเช่นกัน เพราะมันเป็นสัญญาณว่าพวกเขารู้ถึงความร้ายแรงของปัญหา และตัดสินว่าร้ายแรงพอที่จะต้องแพตช์
      หากไม่เปิดเผยช่องโหว่ ฝ่ายที่ได้รับผลกระทบก็ไม่มีทางเริ่มรับมือได้ นอกจากความหวาดระแวงล้วน ๆ การเปิดเผยช่องโหว่ยังเป็นวิธีผลักความรับผิดชอบไปยังผู้ใช้ปลายทางด้วย ทำนองว่า ถ้าไม่อัปเดตก็อย่าบ่น การเปิดเผยมักไม่ค่อยนำไปสู่ความรับผิดชอบต่อผลิตภัณฑ์ และจำไม่ได้ว่ามีประเด็นความรับผิดแบบนั้นในกรณี Meltdown หรือ Spectre ด้วย ดังนั้นจึงไม่ขอฟันธงว่า AMD จงใจปกปิด
    • ดูเหมือนจะเป็นคำตอบที่ถูกต้อง แต่พูดมากกว่านี้ไม่ได้ :(

  • บทความดูเหมือนจะบอกเป็นนัยว่า ลูปบัฟเฟอร์ ไม่ได้ให้ประโยชน์ทั้งด้านประสิทธิภาพหรือพลังงาน
    ถ้าเป็นเช่นนั้น ก็อาจเป็นกรณีคลาสสิกแบบ “ทีมวิศวกรใช้เวลาหลายเดือนสร้างฟีเจอร์ใหม่แวววาว แต่ไม่มีประโยชน์จริง ถึงอย่างนั้นก็ยังปล่อยออกมาเพราะมีใครบางคนอยากรักษาหน้า” ในทีมซอฟต์แวร์ก็เคยเห็นการเสนอให้เขียนโค้ดเบสใหม่เพื่อกำจัดความอุ้ยอ้ายแบบ legacy และเพิ่มประสิทธิภาพ แต่พอเสร็จแล้วจำนวนบรรทัดโค้ดกลับเพิ่มขึ้นและประสิทธิภาพแย่ลง ทั้งสองกรณีไม่ควรถูกปล่อยออกมาเลย

    • แต่เหตุผลที่ยังปล่อยออกมาก็คือสามารถปิดได้ด้วย อัปเดตเฟิร์มแวร์ และการเปลี่ยนเลย์เอาต์ฮาร์ดแวร์ทางกายภาพครั้งใหญ่ระหว่างการออกแบบมีโอกาสส่งผลแย่ยิ่งกว่า
    • หากเพิ่งตระหนักหลังจากมันเข้าไปอยู่ในคอร์แล้วว่าไม่ได้ช่วยอะไรมาก การถอดมันออกเองก็เป็นความเสี่ยงชัดเจน
    • ในบทความก็บอกว่าการวัดการใช้พลังงานโดยรวมทำได้ยาก ดังนั้นจึงไม่สามารถสรุปได้ว่าฟีเจอร์นี้ไม่มีผลใด ๆ และจริง ๆ แล้วก็ไม่ควรสรุปแบบนั้น
      ยากที่จะมองว่าทีมวิศวกรรมของ AMD จะไร้หลักการถึงขั้นปล่อยให้ฟีเจอร์ฮาร์ดแวร์ที่ไร้ค่าใช้พื้นที่และพลังงานไปเปล่า ๆ และในกรณีนี้อยากให้น้ำหนักกับความเป็นไปได้ที่ Chips 'n Cheese วัดผลกระทบไม่พบมากกว่า
    • ทำงานอยู่ในบริษัทฮาร์ดแวร์ที่ค่อนข้างมีชื่อเสียงแห่งหนึ่ง ฝั่งซอฟต์แวร์กำลังหมกมุ่นกับการ ทำอะไรสักอย่าง แม้จะยังพิสูจน์ประโยชน์ได้ไม่เพียงพอ นอกจากบาง use case แคบ ๆ หรือ benchmark ที่ตั้งเป้าไว้
      น่าหงุดหงิดมาก แต่ไม่มีใครอยากใช้เวลาทำการตรวจสอบล่วงหน้า การดันโปรเจกต์ใหม่มักทำให้ผู้บริหารระดับบนพอใจและถูกตั้งคำถามน้อยกว่า
    • อีกความเป็นไปได้คือ benchmark ด้านพลังงานนั้นแม่นยำแล้ว บัฟเฟอร์เคยช่วยประหยัดพลังงาน แต่ภายหลังพบการปรับแต่งที่ดีกว่าใน ระดับไมโครโค้ด ซึ่งทำให้เส้นทางปกติประหยัดพลังงานกว่าเดิม จนบัฟเฟอร์กลับกลายเป็นอุปกรณ์ที่กินพลังงานแทน

  • ย่อหน้าที่น่าสนใจที่สุดในบทความคือส่วนนี้: มุมมองที่ดีที่สุดต่อการมีลูปบัฟเฟอร์ใน Zen 4 คือมันเป็นสัญญาณว่า AMD มี กำลังสำรอง ให้เหล่าวิศวกรได้ลองทำอะไรบางอย่าง
    ครั้งนี้อาจไม่ประสบผลสำเร็จ แต่การให้วิศวกรได้ทดลองกับฟีเจอร์ที่มีความเสี่ยงต่ำและผลกระทบต่ำ เป็นวิธีที่ดีในการสร้างความมั่นใจ หวังว่าจะได้เห็นความมั่นใจแบบนั้นมากขึ้นในอนาคต

  • ส่วนที่ว่า “แปลกตรงที่ถ้าตรึงไว้กับได non-VCache การปิดลูปบัฟเฟอร์ทำให้ประสิทธิภาพเกมลดลง 5% ไม่รู้ว่าทำไม” นั้น ถ้ามีการวัดพลังงานที่ละเอียดกว่านี้ ก็น่าจะช่วยตัดสินได้ว่าเกี่ยวกับ งบประมาณด้านความร้อน/พลังงาน หรือไม่
    ฟีเจอร์นี้ก็ดูเหมือนมีเจตนาเพื่อประหยัดพลังงานด้วย

    • ตรงนี้มีรายละเอียดไม่พอ CCD ตัวที่สองของชิป Ryzen แม้ในชิป non-X3D ก็มีคุณภาพการคัดเกรดต่ำกว่าตัวแรก และแตกต่างกันไปในแต่ละชิป
      ในชิป non-X3D ของผม คอร์ส่วนใหญ่ใน CCD0 ไปได้ถึง 5.6~5.75GHz แต่คอร์ใน CCD1 จบที่ 5.4~5.5GHz ชิป V-Cache ของ Zen 4 มีโทษด้านคล็อกมาก แต่แคชชดเชยได้เกินกว่านั้น ต้องดูว่าทดสอบทั้งสถานะเปิดและปิดฟีเจอร์บน CCD1 ของชิปเดียวกันหรือไม่ และพยายามแยกการเปลี่ยนแปลงอื่น เช่น การแก้ไขด้านความปลอดภัย ออกหรือไม่ ซึ่งบทความเองก็ยอมรับว่า “ไม่” หากจะทำให้ถูกต้อง ต้องหาวิธีปิดเฉพาะฟีเจอร์นี้ใน BIOS ที่ยังเปิดอยู่ แล้วทดสอบทั้งสองฝั่งบนชิปตัวเดียวกัน และถึงอย่างนั้นผลลัพธ์ก็อาจไม่แม่นยำเพราะเงื่อนไขการแตกแขนงอื่น ๆ ถ้ามีโปรไฟล์ประสิทธิภาพทั้งหมด ความแม่นยำจะสูงขึ้น แต่คงมีแค่วิศวกรของ AMD ที่ทำได้
    • บอกว่ามันถูกปิดใช้งาน ณ จุดใดจุดหนึ่งระหว่าง UEFI สองเวอร์ชัน ที่ทดสอบ คงมีการเปลี่ยนแปลงอื่นรวมอยู่ด้วย ดังนั้นการวัดจึงไม่ใช่การทดสอบ A/B ที่เข้มงวด

  • ดูเหมือนมันเล็กเกินไปที่จะสร้างความแตกต่างจริง และมีความหมายเฉพาะในสถานการณ์ที่เจาะจงมาก ๆ เท่านั้น ถ้าทำให้ใหญ่กว่านี้ ต้นทุนการใช้งานน่าจะสูงเกินประโยชน์
    ถึงอย่างนั้นก็คงมี regression เล็กน้อยในบาง workload แต่ AMD ก็เคยทำการปรับปรุงประสิทธิภาพเล็ก ๆ หลังวางจำหน่ายมาแล้ว ใน Zen 4 น่าจะทำให้เป็นตัวเลือกใน BIOS ไปเลย การที่ดูเหมือนไม่ได้ทำเช่นนั้นบ่งชี้ถึงความเป็นไปได้ของบั๊กหรือปัญหาด้านความปลอดภัย

    • การที่ฟีเจอร์ซึ่งผู้ใช้ส่วนใหญ่ไม่สังเกตเห็น แต่ทำให้ฟรอนต์เอนด์ซับซ้อนขึ้น ถูก ปิดใช้งานอย่างเงียบ ๆ นั้น ให้ความรู้สึกเหมือนพวกเขาดึง chicken bit นี้เพื่อหลีกเลี่ยงหรือชะลอการเปิดเผยบั๊กฮาร์ดแวร์ ขณะเดียวกันก็ปล่อยมาตรการบรรเทาออกไปแล้ว ผู้ผลิตบ้าเอ๊ย เมื่อไหร่จะเรียนรู้สักที

  • เกร็ดหนึ่งคือ ความแตกต่างไม่กี่อย่างระหว่าง 68000 ปี 1979 กับ 68010 ปี 1982 มี “loop mode” หรือการเพิ่มบัฟเฟอร์ลูปขนาด 6 ไบต์อยู่ด้วย

    • สิ่งที่สำคัญกว่ามากคือการแก้ การรองรับ MMU เดิมที 68000 สูญเสียสถานะบางส่วนที่จำเป็นต่อการกู้คืนจาก page fault และวิธีแก้เลี่ยงก็น่าเกลียดและแพง
      คือให้ CPU สองตัวทำงานเหลื่อมกันหนึ่งไซเคิล แล้วฉีดอินเทอร์รัปต์ที่กู้คืนได้เข้าไปใน CPU ตัวที่สอง ถึงอย่างนั้น ถ้าต้องการ CPU ที่มี MMU, ชุดคำสั่ง 32 บิต และบัสแอดเดรส 24 บิต ตอนนั้นก็ดูเหมือนจะถูกกว่าทางเลือกอื่น ๆ คงเป็นยุคที่โหดจริง ๆ
    • น่าสนใจดี สำหรับบัฟเฟอร์ลูปขนาดเล็ก ผมค่อนข้างชอบ คอร์ Forth ของ GreenArrays
      คำสั่ง 4 คำสั่งอยู่ในเวิร์ด 18 บิตหนึ่งคำ และมี opcode หนึ่งตัวที่ลด loop counter แล้วกลับไปยังจุดเริ่มต้นของเวิร์ด แบบนั้นมันจึงทำงานได้เร็วขึ้นพอสมควร
    • บัฟเฟอร์ลูปของ 68010 แทบไม่มีประโยชน์เลย เพราะไม่ใช่แค่มี 6 ไบต์ แต่ยังเก็บคำสั่งได้แค่สองคำสั่งด้วย
      หนึ่งในนั้นต้องเป็นคำสั่งลูป (DBcc) ดังนั้นตัวลูปจึงต้องเป็นคำสั่งเดียว สิ่งที่เร็วขึ้นได้จริง ๆ แทบจะมีแค่ memcpy ที่ไม่ได้ optimize เท่านั้น

  • น่าสนใจที่ใน Cortex-A15 สิ่งนี้เป็น ฟีเจอร์หลักของการออกแบบ อยากรู้ว่ามีตัวเลขผลลัพธ์ในชิปอื่น ๆ ไหม
    ในอุปกรณ์อย่างคอนโซลที่มีอายุการออกแบบยาวกว่า อย่างน้อยก็น่าจะใช้เป็นเป้าหมายในการ optimize ได้

    • ผมก็สงสัยเหมือนกัน คาดว่าประโยชน์ที่ได้จากบัฟเฟอร์ลูปใน สถาปัตยกรรม RISC ใด ๆ น่าจะค่อนข้างน้อย
      เพราะหัวใจของ RISC คือการ fetch และ decode คำสั่งนั้นง่ายกว่ามาก หรือแทบจะเป็นเรื่องเล็กน้อย

  • ผมมี 7950X3D ซึ่งอัปเกรดมาจาก Skylake 6700K ดูเหมือนโดยไม่รู้ตัวแล้วผมจะถูกดึงดูดเข้าหา ชิปที่บัฟเฟอร์ลูปฮาร์ดแวร์ถูกปิดใช้งานด้วยซอฟต์แวร์

    • ถ้าสักวันจะซื้อเครื่องใหม่ รบกวนบอกล่วงหน้าด้วยนะ พวกเราจะได้เลี่ยง!

  • เป็นบทความที่น่าสนใจ แต่ไม่รู้ว่าบัฟเฟอร์ลูปกิน พื้นที่บนได มากแค่ไหน
    ถ้าตัดออกในชิปรุ่นถัดไป ก็สงสัยว่าจะเอาพื้นที่นั้นไปใช้กับสิ่งที่มีประโยชน์กว่าอย่าง L2 cache ที่ใหญ่ขึ้นได้หรือไม่

    • ผมมองว่าชิปสมัยใหม่ส่วนใหญ่ถูกจำกัดด้วย การเดินสาย มากกว่าพื้นที่บนได คุณสร้างฟีเจอร์ได้มหาศาล แต่การจ่ายทั้งพลังงานและสัญญาณที่ปรับรูปแล้วให้ถึงตรงนั้นต่างหากที่ลำบากจริง ๆ
    • ตามความเข้าใจของผม มันเป็นการ optimize ขนาดค่อนข้างเล็กใน front-end เดิมทีก็มีรายการไม่มาก แค่ 144 รายการ ดังนั้นพื้นที่ที่ประหยัดได้คงน้อยมาก
      ในทางทฤษฎี บัฟเฟอร์ลูปช่วยประหยัดพลังงานหรือเพิ่มประสิทธิภาพในลูปที่แน่นมากได้ ในทางปฏิบัติดูเหมือนจะทำไม่ได้ทั้งสองอย่าง และ AMD ก็ถอดมันออกทั้งหมดใน Zen 5
    • ดูจากแผนภาพแล้ว บัฟเฟอร์ลูปดูเหมือนจะใช้พื้นที่จัดเก็บเดียวกับ คิว micro-op ที่มีอยู่แล้ว
      ถ้าเป็นอย่างนั้นจริงก็สมเหตุสมผล และต้นทุนด้านพื้นที่ก็น่าจะเป็นเพียงลอจิกควบคุมเพิ่มเติม ส่วนที่แพงที่สุดน่าจะเป็นการตรวจจับลูปตั้งแต่แรก แต่ก็น่าจะค่อนข้างเล็กเมื่อเทียบกับขนาดคิว
    • ระบุว่าเป็น รายการ micro-op 144 รายการ ต่อคอร์ ไม่รู้ว่ากี่ไบต์ แต่ L2 cache สมัยนี้อยู่ราว 1MB ต่อคอร์ ดังนั้นแม้จะสมมติว่าพื้นที่ไดของบัฟเฟอร์ลูปส่วนใหญ่เป็นที่เก็บข้อมูล ก็คงไม่ทำให้เห็นความต่างชัดเจน

  • การวิเคราะห์ในส่วน “พลังงาน” ดูเหมือนจะไม่ได้หารด้วยจำนวนคำสั่งที่รันต่อวินาที
    ถ้าจะดูประโยชน์ของบัฟเฟอร์ลูปนี้ แทบจะแน่นอนว่าควรดู พลังงานต่อคำสั่ง ไม่ใช่พลังงานต่อวินาที หรือกำลังไฟ (วัตต์)

    • แต่ละคำสั่งใช้จำนวน clock cycle ต่างกัน และระหว่างเจเนอเรชันสถาปัตยกรรมอย่าง Zen 4 กับ Zen 5 ก็ยังต่างกันด้วย ดังนั้นจึงทำได้จริงยาก เว้นแต่ว่า workload จะสร้าง จำนวนคำสั่งต่อไซเคิล ที่เหมือนกันเป๊ะ ซึ่งเป็นไปไม่ได้เพราะมี multithreading และการประมวลผลงาน
      แม้แต่ลำดับและเนื้อหาใน RAM ก็เปลี่ยนทุกอย่างได้ การรันแบบเปิดและปิดหลายร้อยครั้งอาจช่วยแยกแยะได้บ้าง แต่จะใช้เวลามหาศาลและก็ยังไม่แม่น 100% อยู่ดี แค่การปิดฟีเจอร์ก็อาจทำให้โค้ดไปคนละ branch และทำให้การจัดวางทั้งหมดเปลี่ยนไป ผมไม่ได้รู้ปัญหานี้แบบเฉพาะเจาะจง แต่เคยเห็นกรณีที่พอปิดฟีเจอร์แล้วโหลดถูกย้ายจาก integer unit ไปยัง FPU หรือ GPU หรือมีคำสั่งหายไป 5 คำสั่งแต่เพิ่มเข้ามา 2 คำสั่งแทน