Windows Server 2025 ทำงานได้ดีกว่าบน ARM

 (jasoneckert.github.io)
1 คะแนน โดย GN⁺ 9 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • จากการเปรียบเทียบ Windows Server 2025 แบบเวอร์ชวลไลซ์ พบว่าการตั้งค่า guest แบบ ARM64 บน host แบบ ARM64 ทำงานได้เสถียร และยังตอบสนองได้ไวกว่าอย่างรู้สึกได้ทั้งในการเริ่มบริการ การเปิดคอนโซลจัดการ และการประมวลผลงานทดลอง
  • VM ทั้งสองเครื่องถูกตั้งค่าให้มี หน่วยความจำ·โปรเซสเซอร์เสมือน·บทบาทที่ติดตั้ง เหมือนกัน และในการวัดผลพบว่าระบบ Snapdragon มีความผันผวนของการใช้ CPU ต่ำกว่า รักษา Processor Queue Length ไว้ที่ 0 และบันทึกค่า CPU Wait Time Per Dispatch ได้อย่างสม่ำเสมอ
  • ในการวัดซ้ำกับ IIS, DNS, การค้นหา Active Directory, การยืนยันตัวตนโดเมน และการทำซ้ำไฟล์ I/O ก็พบว่า Snapdragon X Elite ให้ค่าระยะเวลาที่ทำซ้ำได้ใกล้เคียงเดิมแทบทุกครั้ง ขณะที่ Intel บางรอบเร็วกว่าแต่โดยรวมมีความแปรปรวนมากกว่า
  • ผู้เขียนไม่ได้สรุปว่าความต่างเกิดจากสถาปัตยกรรม CPU เพียงอย่างเดียว แต่ชี้ว่าพร้อมกับสตอเรจ หน่วยความจำ การจัดการพลังงาน และคุณลักษณะด้านความร้อนแล้ว ความสม่ำเสมอของ latency และการจัดตารางที่คาดเดาได้มีผลสำคัญกว่าในโหลดเซิร์ฟเวอร์แบบเวอร์ชวลไลซ์
  • แม้ x64 จะยังได้เปรียบในเวิร์กโหลดที่เน้นปริมาณงานสูงสุด แต่ในการใช้งาน Windows Server ทั่วไปที่มี งานขนาดเล็กจำนวนมากและไวต่อความหน่วง ความน่าสนใจของ ARM64 เพิ่มขึ้น อย่างไรก็ตามแพลตฟอร์มมาตรฐานสำหรับการสอนยังคงใช้ x64 เนื่องจาก ARM64 ยังไม่รองรับ nested virtualization

สภาพแวดล้อมการทดสอบและเกณฑ์การเปรียบเทียบ

  • มีการสร้างสภาพแวดล้อมเสมือนของ Windows Server 2025 บนสองระบบเพื่อเปรียบเทียบ
    • ระบบ Intel Core i9 รุ่นที่ 14 บน Windows 11 ที่รันเครื่องเสมือน Hyper-V หลายเครื่อง
    • ระบบ Snapdragon X Elite บน Windows 11 on ARM ที่ตั้งค่า Windows Server 2025 แบบเดียวกัน
  • เนื่องจาก Microsoft ยังไม่มี ISO ติดตั้งอย่างเป็นทางการของ Windows Server 2025 ARM บนเว็บไซต์ จึงใช้ UUP dump เพื่อสร้างอิมเมจจากเซิร์ฟเวอร์อัปเดตของ Microsoft แล้วติดตั้ง
  • Hyper-V VM ทั้งสองเครื่องถูกตั้งค่าให้มี หน่วยความจำ, โปรเซสเซอร์เสมือน, บทบาทที่ติดตั้ง เหมือนกัน
    • Snapdragon X Elite คือ ARM64 guest on ARM64 host
    • Intel Core i9 คือ x64 guest on x64 host

ข้อสังเกตเบื้องต้นและขอบเขตการตีความ

  • สภาพแวดล้อม Windows Server 2025 บนระบบ ARM มีความ เสถียร และ ทำงานได้ปกติ โดยให้ความรู้สึกว่าเร็วกว่าโดยรวมจนอยู่ในระดับ ใช้งานจริงได้
    • เริ่มบริการได้เร็วขึ้น
    • เปิดคอนโซลจัดการได้เร็วขึ้น
    • ใช้เวลาทำงานทดลองสำหรับการเขียนตำราลดลง
  • อย่างไรก็ตาม ผู้เขียนไม่ได้สรุปว่าความต่างด้านประสิทธิภาพเกิดจาก สถาปัตยกรรม CPU เพียงอย่างเดียว
    • สตอเรจ หน่วยความจำ การจัดการพลังงาน และลักษณะด้านความร้อนก็อาจมีผลต่อผลลัพธ์
    • แทนที่จะสรุปว่า “ARM เร็วกว่า” จึงควรตีความบนพื้นฐานของ คุณลักษณะของระบบโดยรวม
  • โหลดบริการทั่วไปของ Windows Server มีลักษณะเป็น เธรดจำนวนมาก และเน้น งาน CPU และ I/O ขนาดเล็กแต่เกิดบ่อย
    • รวมถึง Active Directory, DNS, DHCP, IIS, บริการไฟล์ SMB/NFS/DFS, Print Services, Certificate Services, Remote Desktop Services, Routing and Remote Access, NPS เป็นต้น
    • งานประเภทนี้ไวต่อ latency และ การสลับบริบท และได้ประโยชน์จากประสิทธิภาพที่สม่ำเสมออย่างต่อเนื่อง

ข้อสังเกตเกี่ยวกับความแตกต่างด้านประสิทธิภาพ

  • ระบบ ARM ตระกูล Snapdragon มีแนวโน้มให้ ประสิทธิภาพที่ต่อเนื่องและเสถียร มากกว่าการไล่ตามบูสต์คล็อกสูง
  • CPU Intel รุ่นใหม่สามารถให้ประสิทธิภาพสูงสุดได้มากกว่าด้วยคุณลักษณะ การเร่งความถี่และการ throttle แบบไดนามิก
    • แต่ในโหลดต่อเนื่องหรือโหลดผสม ก็อาจทำให้ความแปรปรวนของการจัดตารางและ latency เพิ่มขึ้น
  • ในสภาพแวดล้อมเวอร์ชวลไลซ์ ความแปรปรวนนี้ยิ่งสำคัญมากขึ้น
    • ไฮเปอร์ไวเซอร์อย่าง Hyper-V ทำหน้าที่เสมือนตัวจัดตารางฮาร์ดแวร์
    • ยิ่งช่วงเวลาการทำงานของฮาร์ดแวร์คาดเดาได้มากเท่าไร การจัดตารางของไฮเปอร์ไวเซอร์ก็ยิ่งให้ผลลัพธ์ที่สม่ำเสมอมากขึ้นเท่านั้น
    • ผลดังกล่าวสะท้อนออกมาใน VM และการตอบสนองของบริการภายใน VM
  • ยังมีการกล่าวถึงความเป็นไปได้ของความต่างที่ตัว Windows Server ARM64 build เอง
    • จาก release note หลายฉบับที่ตรวจสอบทางออนไลน์ เวอร์ชัน ARM64 อาจหลีกเลี่ยง legacy compatibility layer บางส่วน และใช้ไบนารีที่ทันสมัยและปรับแต่งมาแล้วมากกว่า
    • จึงอาจเป็น build ที่สะอาดกว่า เวอร์ชัน x64
    • อย่างไรก็ตามไม่ได้มีการนำเสนอหลักฐานเชิงลึกของการติดตั้งภายในเพิ่มเติม

การวัดด้วย Performance Monitor

  • มีการเพิ่มตัวนับของ Performance Monitor บนโฮสต์ Windows 11 ทั้งสองเครื่องเพื่อวัดผล
    • \\Processor(_Total)\\% Processor Time
      • อัตราการใช้ CPU ของทุกคอร์รวมกัน
    • \\System\\Processor Queue Length
      • จำนวนเธรดที่กำลังรอเวลา CPU
      • หากเหมาะสมที่สุดควร คงไว้ที่ 0
    • \\Hyper-V Hypervisor Virtual Processor(*)\\CPU Wait Time Per Dispatch
      • เวลารอเฉลี่ยก่อนที่โปรเซสเซอร์เสมือนจะถูกจัดตารางลง CPU
  • หลังจากสร้างโหลดจาก PowerShell ภายในแต่ละ VM แล้วจึงสังเกตผลลัพธ์
    • รันลูปไม่สิ้นสุด 8 ชุด ที่เรียก Get-Process ซ้ำ ๆ โดยจัดเรียงผลตามการใช้ CPU และดึง 5 อันดับแรก
  • จากผลการวัด Snapdragon แสดงรูปแบบประสิทธิภาพที่ ต่อเนื่องและเสถียร
    • ความผันผวนของ % Processor Time ต่ำกว่ามาก
    • Processor Queue Length คงอยู่ที่ 0
    • CPU Wait Time Per Dispatch ก็เรียบและคงที่เช่นกัน
  • ระบบ Intel แสดงให้เห็นผลของความแปรปรวนจาก การบูสต์/การ throttle ในตัวชี้วัด
    • ความผันผวนของ % Processor Time มากกว่า
    • Processor Queue Length พุ่งสูงเป็นช่วง ๆ
    • CPU Wait Time Per Dispatch ก็มีความผันผวนอย่างมีนัยสำคัญ

การวัดการตอบสนองของบริการ

  • ใช้ Measure-Command ใน PowerShell ของแต่ละ VM เพื่อวัดเวลาของงานบริการทั่วไป
  • มีการทดสอบกับเว็บเซิร์ฟเวอร์ IIS
    • ทำซ้ำ Invoke-WebRequest http://localhost -UseBasicParsing | Out-Null จำนวน 1000 ครั้ง
  • วัดซ้ำบริการอื่นด้วยวิธีเดียวกัน
    • DNS
      • Resolve-DnsName "domainX.com" -Server 127.0.0.1 | Out-Null
    • การค้นหา Active Directory
      • Get-ADUser -Filter * -ResultSetSize 1 | Out-Null
    • latency ของการยืนยันตัวตนโดเมน
      • Test-ComputerSecureChannel -Verbose:$false
    • ไฟล์ I/O
      • สร้างไดเรกทอรี C:\TestFiles
      • ทำซ้ำ 2000 รอบ โดยสร้างไฟล์ เขียนข้อมูล อ่าน และลบไฟล์
  • จากการรันซ้ำหลายครั้ง ระบบ Snapdragon ให้ ค่าระยะเวลาที่สม่ำเสมอและทำซ้ำได้ แทบทุกครั้ง
  • ระบบ Intel มีความแปรปรวนของผลลัพธ์มากกว่า
    • บางรอบก็เร็วกว่าระบบ Snapdragon
    • แต่ในกรณีส่วนใหญ่ตามหลัง
  • โดยรวมจึงสรุปว่า Snapdragon เหนือกว่าในทุกการทดสอบ

ข้อสรุปสำคัญ

  • องค์ประกอบร่วมที่เห็นได้จากทุกผลลัพธ์คือ ความสม่ำเสมอของ latency
  • โหลด Windows Server แบบเวอร์ชวลไลซ์ให้ความสำคัญมากกับ การตอบสนองที่รวดเร็วต่อคำสั่งขนาดเล็กที่เกิดบ่อย และ การจัดตารางที่คาดเดาได้
  • ในเวิร์กโหลดที่ ปริมาณงานสูงสุด สำคัญ ระบบ x64 ยังมีข้อได้เปรียบที่ชัดเจน
  • ในทางกลับกัน หากเป็นสภาพแวดล้อมแบบ Windows Server ทั่วไปที่มี งานขนาดเล็กจำนวนมากและไวต่อความหน่วง ทำงานร่วมกันภายใต้การเวอร์ชวลไลซ์ ความสม่ำเสมอ จะสำคัญกว่าความเร็วสูงสุดล้วน ๆ
  • ในบริบทนี้ ARM64 จึงน่าสนใจมากขึ้น
  • ARM64 ถูกใช้อย่างแพร่หลายในคลาวด์อยู่แล้ว และยังมีการกล่าวว่ามี อัตราส่วนประสิทธิภาพต่อราคาที่ดีกว่า x64
  • ผู้เขียนตั้งคำถามว่า Microsoft ควรพิจารณาเพิ่มสัดส่วนของ ARM64 ในอนาคตของ Windows Server
    • ปัจจุบัน Microsoft ยังไม่รองรับ Windows Server on ARM64 อย่างสมบูรณ์
    • อย่างไรก็ตามมีการยกตัวเลขว่าในปีที่ผ่านมา 33% ของ Microsoft Azure VM อินสแตนซ์ใหม่ เป็น ARM64 และ Amazon AWS มี 50% เป็น ARM64

การเลือกแพลตฟอร์มมาตรฐานสำหรับการสอน

  • สภาพแวดล้อมทดลองสำหรับตำรายังคงใช้มาตรฐาน x64 ต่อไป
  • เหตุผลคือการตั้งค่าการทดลองมี nested virtualization อยู่ด้วย
  • เนื่องจาก Hyper-V บน ARM64 ยังไม่รองรับ nested virtualization จึงยังไม่สามารถนำ ARM64 มาใช้เป็นสภาพแวดล้อมหลักสำหรับการสอนได้ในตอนนี้
  • แม้นักศึกษาจะสามารถปรับวิธีทำการทดลองเพื่อหลีกเลี่ยงข้อจำกัดได้ แต่หนึ่งในเป้าหมายของตำราคือ ความสามารถในการทำซ้ำได้ จึงให้ความสำคัญกับสภาพแวดล้อมที่ทำงานเหมือนกันได้ทุกขั้นตอน
  • ณ เวลานี้ สำหรับวัตถุประสงค์ทางการศึกษา x64 ยังเป็นตัวเลือกที่ใช้งานได้จริง

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

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

 
GN⁺ 9 일 전
ความคิดเห็นจาก Hacker News
  • แม้จะเปิดเผยทั้งการตั้งค่า สมมติฐาน และโค้ดที่จำเป็นสำหรับการทดสอบซ้ำแล้ว แต่กลับไม่มี ค่าผลลัพธ์ที่สัมผัสได้จริง อยู่ด้วย เลยรู้สึกแอบสงสัยนิดหน่อย อยากรู้ว่าจริง ๆ แล้ว ARM เร็วแค่ไหนในเชิงตัวเลข
    • มีเหตุผลที่ตั้งใจไม่ใส่ภาพหน้าจอผลลัพธ์ไว้ เพราะไม่อยากให้ประเด็นกลายเป็น โพสต์แนวเบนช์มาร์ก และผลก็อาจทำให้เข้าใจผิดได้เนื่องจากขึ้นอยู่กับฮาร์ดแวร์ ARM หรือรุ่นย่อยของ Snapdragon X Elite ด้วย เลยใส่ PowerShell snippet ไว้แทนเพื่อให้ใครก็ทดสอบซ้ำได้ ผลคร่าว ๆ คือ Snapdragon VM เร็วกว่า Intel VM ราว 20~80% แล้วแต่การทดสอบ โดย DNS ประมาณ 20%, IIS ประมาณ 50% และที่เหลือส่วนใหญ่ใกล้ 80%
  • ถ้ามองจากมุมของนักพัฒนา Windows เรื่องนี้ดูมีโอกาสสูงว่าจะเป็นผลจาก segment heap การทำงานของ heap ใน Windows มีอยู่สองสายที่แยกจากกันคือ NT heap แบบเก่า และ segment heap ที่มาจากยุค 2010s ซึ่ง segment heap มีประสิทธิภาพดีกว่าในแง่การแตกกระจายของหน่วยความจำและการนำ allocation ขนาดเล็กกลับมาใช้ซ้ำ แต่ Windows ให้ความสำคัญกับความเข้ากันได้ย้อนหลังอย่างมาก จึงไม่ได้สลับค่าเริ่มต้นทั้งหมด เพราะแอปเก่าอาจพึ่งพาพฤติกรรมเสี่ยงอย่าง use-after-free หรือแม้แต่โครงสร้างภายในของ NT heap เอง สุดท้ายจึงเลือกแนวทางประนีประนอมคือเปิดใช้ segment heap เป็นค่าเริ่มต้นกับ executable แบบ packaged ส่วนแบบ unpackaged ก็ปล่อยไว้เหมือนเดิม แต่เมื่อการเปลี่ยนผ่านไป UWP ล้มเหลว ระบบนิเวศ Windows ก็ยิ่งแตกเป็นส่วน ๆ และซอฟต์แวร์สำคัญส่วนใหญ่ก็ยังคงเป็น unpackaged x64 อยู่ ขณะที่ไบนารี arm64 มีโอกาสน้อยกว่าจะเป็นโค้ด legacy เก่า ๆ ดังนั้นบน arm จึงเปิด segment heap เป็นค่าเริ่มต้นอยู่แล้ว คิดว่าส่วนหนึ่งไม่น้อยที่ผู้ใช้รู้สึกว่า arm Windows ตอบสนองดีกว่าก็มาจากตรงนี้ ถ้าลองบังคับเปิด segment heap บน x64 แล้วรันทดสอบนี้ใหม่ก็น่าจะน่าสนใจ สำหรับการตั้งค่าราย executable สามารถกำหนด FrontEndHeapDebugOptions แบบ DWORD เป็น 8 ใต้ HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\.exe ได้ และถ้าจะตั้งค่าแบบทั้งระบบ ให้กำหนด Enabled แบบ DWORD เป็น 3 ใต้ HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Segment Heap บนเครื่องพัฒนาของฉันเอง หลังเปิดใช้ทั้งระบบก็ยังไม่เจอปัญหา และการใช้หน่วยความจำลดลงประมาณ 15% ตามการทดสอบ
    • ใน workload ที่กิน RAM/CPU มาก ของฉันเอง เมื่อเทียบกับ NT Heap แล้ว Segment Heap ทำให้ประสิทธิภาพโดยรวมดีขึ้นอย่างสม่ำเสมอราว 7% งานชุดเดียวกันเสร็จเร็วขึ้น 7% ถ้ายังมีการรับรองแบบ "Compatible with Windows XXX" อยู่ในยุค Windows 10/11 ก็น่าจะใส่การตรวจ segment heap เข้าไปได้ เพื่อให้แอปและผู้ใช้จำนวนมากขึ้นได้ประโยชน์ด้านประสิทธิภาพ การใช้พลังงาน และความเป็นมิตรต่อสิ่งแวดล้อม อีกอย่าง ปัญหาของ UWP ไม่ได้อยู่ที่ตัวเทคโนโลยีเท่าไร แต่อยู่ที่การยึดติดกับการแพ็กเกจและการผูกกับ Store มากเกินไป ซึ่งขัดกับวิธีที่ Windows ในฐานะ OS ดำรงอยู่
    • ถ้าใครสนใจ สามารถ opt-in พฤติกรรมนี้ได้โดยตั้งค่า heapType เป็น SegmentHeap ใน application manifest ของ executable ตัวเอง มีคำอธิบายในเอกสาร
    • ทิปใช้งานจริง แบบนี้แหละที่ทำให้ HN มีคุณค่า เลยสงสัยว่าคีย์รีจิสทรีแบบทั้งระบบต้องรีบูตก่อนไหม หรือมีผลทันทีตั้งแต่ตอนเริ่มรัน executable
    • เนื้อหานี้น่าสนใจระดับที่ควรเก็บเป็น บล็อกโพสต์ มากกว่าจะเป็นแค่คอมเมนต์ในฟอรัม
    • เคยเห็นการอธิบายการตั้งค่า global นี้แบบ 0 เทียบกับ non-zero มาก่อน เลยสงสัยว่าทำไมค่าถึงเป็น 3 โดยเฉพาะ แล้ว 2 หมายถึงอะไร และถ้าอยากเช็กความหมายของค่าพวกนี้เองควรไปดูจากที่ไหน
  • ประโยคในบทความที่ว่า "ARM ไม่ไล่ตาม boost clock สูง ๆ แต่ให้ประสิทธิภาพคงที่" ฟังดูเกินจริงไปหน่อย ระบบ ARM ที่ฉันเคยใช้ก็ล้วนมี การปรับสเกลความถี่ และในแง่นั้นก็ทำงานคล้าย x86 สุดท้ายความต่างน่าจะอยู่แค่ว่าขึ้นไปได้สูงแค่ไหน
    • แม้จะขึ้นกับ workload แต่ในสภาพแวดล้อมคลาวด์ของหลายองค์กรที่ฉันเคยทำงานด้วย แค่ ย้ายจาก x86 ไป ARM ก็ช่วยลดต้นทุนได้มากพอสมควรแล้ว เพราะทั้งราคาของ instance ต่ำกว่าและประสิทธิภาพต่อพลังงานก็ดีกว่า โดยเฉพาะที่หนึ่งซึ่งมีการ autoscaling แบบไดนามิกของ Kubernetes node หลายร้อยตัว โดยแทบไม่ต้องเปลี่ยนอย่างอื่นเลย แค่เปลี่ยน x86 -> ARM ก็ประเมินแบบอนุรักษ์นิยมได้ว่าประหยัดราว 15% และก็ทำได้จริง ถ้าเป็น workload ที่ติด CPU และไม่ได้ผูกกับฟีเจอร์เฉพาะของ x86 มากนัก ก็อาจได้มากกว่า 15% ด้วยซ้ำ
  • ถ้าหัวใจจริง ๆ คือประสิทธิภาพของ ARM ที่แกว่งน้อยและคาดเดาได้มากกว่า ก็คงมองได้ว่าการใช้ CPU เซิร์ฟเวอร์อย่าง Epyc แทน CPU เดสก์ท็อปก็น่าจะให้ข้อดีคล้ายกัน เพราะ CPU เซิร์ฟเวอร์มีการแกว่งของสัญญาณนาฬิกาน้อยกว่าและนโยบาย boost ก็ไม่ดุดันเท่า แม้แต่บนฮาร์ดแวร์เดสก์ท็อปที่มีอยู่ตอนนี้เอง ก็อาจลองปิด Turbo ใน BIOS เพื่อบังคับให้ Intel CPU วิ่งที่ base clock แล้วเทียบดูได้ ซึ่งแม้จะช้ากว่า แต่ก็น่าจะให้ประสิทธิภาพที่คงที่และคาดเดาได้
    • ใน power plan ก็ปิด พฤติกรรม turbo ได้เหมือนกัน เพียงแต่ตัวเลือกนั้นอาจไม่ได้แสดงใน GUI ตามค่าเริ่มต้น
  • อยากรู้ว่า Windows on ARM ใช้ VBS หรือ Virtualization Based Security หรือไม่ และใน VM เองรองรับสิ่งนั้นผ่าน nested virtualization ด้วยหรือเปล่า อีกทั้งการบรรเทาช่องโหว่ของ CPU ถูกซ้อนสองชั้นใน VM หรือไม่ ซึ่งอาจมีผลต่อประสิทธิภาพ นี่เป็นสาเหตุของปัญหาด้านประสิทธิภาพที่มักเจอเมื่อรัน Windows ใน VM ทุกวันนี้พอสมควร แต่บทความไม่ได้พูดถึงส่วนนี้เลย จึงน่าเสียดาย
  • สงสัยเรื่องการตั้งค่า RAM และสตอเรจของทั้งสองระบบ ฝั่ง Snapdragon อาจเป็น RAM แบบแพ็กเกจรวม จึงมี interconnect ที่เร็วกว่า ส่วนฝั่ง x86 อาจใช้ DIMM ทำให้เส้นทางสัญญาณยาวกว่า สตอเรจหรือรุ่น CPU เองก็มีผลต่อประสิทธิภาพอย่างมาก เบนช์มาร์กมักกระตุ้นแค่บางส่วนของระบบมากเกินไป เลยคิดว่าความต่างจริงอาจไม่ได้มาจากสถาปัตยกรรม ARM เอง แต่อาจมาจากปัจจัยอื่นอย่าง RAM, syscall หรือ SSD ก็ได้
    • ทั้งสองระบบใช้ DDR5 แบบบัดกรีติดเมนบอร์ดและใช้ NVMe SSD เหมือนกัน เสียอีกที่ SSD ฝั่ง Intel เป็น Samsung ซึ่งเร็วกว่า Foresee ทางฝั่ง Snapdragon
  • บน Linux ทุกอย่างทำงานได้ดีกว่าอยู่แล้ว และไม่เสียรอบประมวลผลไปกับ โอเวอร์เฮดจากการสอดส่อง
  • บทความดูเหมือนจงใจหลีกเลี่ยงที่จะบอกว่าใช้ Intel รุ่นอะไร เลยสงสัยว่าฉันพลาดอะไรไปหรือเปล่า
    • CPU ที่ใช้คือ 14th Gen Intel Core i9
  • บนเซิร์ฟเวอร์ HV ปกติมักปิด C States และตั้ง power management เป็น high เพื่อไม่ให้ x86 ลดความถี่ลง ถ้าป้องกันไม่ให้ CPU แกว่งขึ้นลงได้ ประสิทธิภาพก็อาจดีขึ้นมาก เพียงแต่วิธีแบบนี้มักไม่ค่อยทำกันบนเครื่องส่วนตัวหรือเครื่องแล็บ
    • หรือจะปิดแค่ turbo boost ไปเลยก็ได้
  • อ่านบทความแล้วรู้สึกว่าประเด็นหลักมีสองอย่าง หนึ่งคือ ARM64 อาจ "ฉลาด" น้อยกว่า x64 จึงให้ ประสิทธิภาพที่สม่ำเสมอ มากกว่า แทนที่จะ boost และ throttle อย่างดุดันเหมือน Core i9 ซึ่งทำให้ OS จัดตารางงานได้ง่ายกว่า สองคือ Windows บน ARM อาจมีภาระทางประวัติศาสตร์น้อยกว่า x64 ทำให้ตัว build บน ARM เองมีประสิทธิภาพกว่า สุดท้ายเลยชวนสงสัยว่า CPU throttling ทุกวันนี้ฉลาดเกินไปจนเริ่มให้ผลเสียแล้วหรือยัง
    • แต่ก็ต้องดูควบคู่กันไปด้วยว่านี่เป็นกรณีทดสอบ Server OS บน CPU x86 แบบเดสก์ท็อป CPU เซิร์ฟเวอร์ x86 อย่าง AMD Epyc หรือ Intel Xeon มีช่วงการแกว่งของสัญญาณนาฬิกาน้อยกว่าและนโยบายก็ไม่ดุดันเท่า จึงให้ประสิทธิภาพที่คงที่และคาดเดาได้มากกว่า CPU เดสก์ท็อป คุณลักษณะนี้เหมาะกับ workload แบบมัลติเธรด ส่วน CPU เดสก์ท็อปถูกจูนมาเพื่อประสิทธิภาพ single-thread สูงสุด จึงอาจกลับกลายเป็นเสียเปรียบในงานมัลติเธรดก็ได้