Windows Server 2025, ARM üzerinde daha iyi çalışıyor

 (jasoneckert.github.io)
1 puan yazan GN⁺ 8 일 전 | 1 yorum | WhatsApp'ta paylaş
  • Sanallaştırılmış Windows Server 2025 karşılaştırmasında, ARM64 host üzerinde ARM64 guest yapılandırması kararlı çalıştı; servis başlatma, yönetim konsolu çalıştırma ve uygulamalı görevleri işleme sırasında hissedilen tepki de daha hızlıydı
  • İki VM’de bellek, sanal işlemci ve rol yapılandırması aynı tutuldu; ölçümlerde Snapdragon sisteminin CPU kullanım dalgalanmasının daha düşük olduğu, Processor Queue Length değerinin 0’da kaldığı ve CPU Wait Time Per Dispatch metriğinde tutarlı değerler verdiği görüldü
  • IIS, DNS, Active Directory sorguları, etki alanı kimlik doğrulaması ve dosya I/O tekrar ölçümlerinde de Snapdragon X Elite neredeyse her seferinde yeniden üretilebilir süre değerleri gösterdi; Intel bazı çalıştırmalarda daha hızlı olsa da genel olarak sapma daha büyüktü
  • Fark yalnızca CPU mimarisine bağlanmadı; depolama, bellek, güç yönetimi ve termal özelliklerle birlikte gecikme tutarlılığı ve öngörülebilir zamanlamanın sanallaştırılmış sunucu yüklerinde daha önemli rol oynadığı belirtildi
  • Azami throughput odaklı iş yüklerinde x64 avantajını korusa da, küçük ve gecikmeye duyarlı işlerin çok olduğu tipik Windows Server dağıtımlarında ARM64’ün çekiciliği artıyor; ancak eğitim amaçlı standart platform, ARM64’te iç içe sanallaştırma desteği olmadığı için x64 olarak kalıyor

Test ortamı ve karşılaştırma ölçütü

  • Windows Server 2025 sanal ortamı iki sistemde ayrı ayrı kurularak karşılaştırma yapıldı
    • Windows 11 tabanlı 14. nesil Intel Core i9 sistemde birden fazla Hyper-V sanal makinesi çalıştırıldı
    • Windows 11 on ARM tabanlı Snapdragon X Elite sistemde de aynı Windows Server 2025 ortamı kuruldu
  • Microsoft web sitesinde resmi Windows Server 2025 ARM kurulum ISO’su sunulmadığı için, Microsoft güncelleme sunucularını temel alan imaj UUP dump ile oluşturulup kuruldu
  • İki Hyper-V VM, bellek, sanal işlemci ve kurulu roller açısından aynı şekilde yapılandırıldı
    • Snapdragon X Elite: ARM64 guest on ARM64 host
    • Intel Core i9: x64 guest on x64 host

İlk gözlemler ve yorum kapsamı

  • ARM sistemindeki Windows Server 2025 ortamı kararlıydı, normal çalıştı ve gerçek kullanım için uygun düzeyde hissedilen genel hız da daha iyiydi
    • Servis başlatma hızı arttı
    • Yönetim konsolu çalıştırma hızı arttı
    • Ders kitabı yazımı için uygulamalı görevleri tamamlama süresi kısaldı
  • Ancak performans farkının yalnızca CPU mimarisinin sonucu olduğu kesin biçimde söylenmedi
    • Depolama, bellek, güç yönetimi ve termal özellikler de sonucu etkileyebilir
    • “ARM daha hızlıdır” gibi kesin bir yargı yerine tüm sistem özellikleri temelinde yorum yapılması gerektiği vurgulandı
  • Windows Server’ın tipik servis yükü thread ağırlıklıdır ve küçük ama sık CPU ve I/O işleri merkezlidir
    • Buna Active Directory, DNS, DHCP, IIS, SMB/NFS/DFS dosya servisleri, Print Services, Certificate Services, Remote Desktop Services, Routing and Remote Access ve NPS dahildir
    • Bu tür yükler gecikme süresine ve bağlam değişimine duyarlıdır; sürekli tutarlı performans burada avantaj sağlar

Performans farkına ilişkin gözlemler

  • Snapdragon tabanlı ARM sistemleri, yüksek boost clock peşinde koşmaktan ziyade sürekli ve kararlı performans sunma eğiliminde
  • Modern Intel CPU’lar frekans hızlandırma ve dinamik throttling sayesinde yüksek azami performans sunabiliyor
    • Ancak sürekli yükte veya karma yükte zamanlama ve gecikme dalgalanması artabiliyor
  • Sanallaştırma ortamında bu tür dalgalanma daha önemli hale geliyor
    • Hyper-V gibi hypervisor’lar fiilen bir donanım zamanlayıcısı gibi çalışıyor
    • Donanım yürütme zamanlaması ne kadar öngörülebilir olursa, hypervisor zamanlaması da o kadar tutarlı sonuç veriyor
    • Bunun etkisi VM’lere ve VM içindeki servislerin yanıt verebilirliğine yansıyor
  • Windows Server ARM64 build farkı olasılığı da anıldı
    • Çevrim içi incelenen çeşitli sürüm notlarına göre, ARM64 sürümü bazı legacy uyumluluk katmanlarından kaçınıp daha modern ve optimize ikili dosyalar kullanıyor olabilir
    • x64 sürümüne göre daha sadeleştirilmiş bir build olabileceği gözlemi paylaşıldı
    • Ancak buna dair ek somut iç uygulama kanıtı sunulmadı

Performance Monitor ölçümleri

  • İki Windows 11 host üzerinde Performance Monitor sayaçları eklenerek ölçüm yapıldı
    • \\Processor(_Total)\\% Processor Time
      • Tüm çekirdekler için CPU kullanım oranı
    • \\System\\Processor Queue Length
      • CPU süresi bekleyen thread sayısı
      • İdeal durumda 0’da kalması tercih edilir
    • \\Hyper-V Hypervisor Virtual Processor(*)\\CPU Wait Time Per Dispatch
      • Sanal işlemcinin CPU’da zamanlanana kadar beklediği ortalama süre
  • Her VM içinde PowerShell ile yük oluşturulduktan sonra sonuçlar gözlemlendi
    • Get-Process çıktısını CPU kullanımına göre sıralayıp ilk 5 süreci tekrar tekrar sorgulayan sonsuz döngü 8 kez çalıştırıldı
  • Ölçüm sonuçlarında Snapdragon sisteminde sürekli ve kararlı performans deseni görüldü
    • % Processor Time dalgalanması çok daha düşüktü
    • Processor Queue Length 0’da kaldı
    • CPU Wait Time Per Dispatch de düz ve tutarlı değerler verdi
  • Intel sisteminde boost/throttle değişkenliği metriklere yansıdı
    • % Processor Time dalgalanma aralığı daha büyüktü
    • Processor Queue Length periyodik olarak sert yükseldi
    • CPU Wait Time Per Dispatch metriğinde de anlamlı dalgalanma görüldü

Servis yanıt verebilirliği ölçümü

  • Her VM’in PowerShell ortamında Measure-Command kullanılarak tipik servis işlemlerinin süreleri ölçüldü
  • IIS web sunucusu için test yapıldı
    • Invoke-WebRequest http://localhost -UseBasicParsing | Out-Null 1000 kez tekrarlandı
  • Aynı yöntemle diğer servisler de tekrar tekrar ölçüldü
    • DNS
      • Resolve-DnsName "domainX.com" -Server 127.0.0.1 | Out-Null
    • Active Directory sorgusu
      • Get-ADUser -Filter * -ResultSetSize 1 | Out-Null
    • Etki alanı kimlik doğrulama gecikmesi
      • Test-ComputerSecureChannel -Verbose:$false
    • Dosya I/O
      • C:\TestFiles dizini oluşturuldu
      • 2000 tekrar boyunca dosya oluşturma, içerik yazma, okuma ve silme işlemleri yapıldı
  • Birden çok tekrarın ardından Snapdragon sistemi tutarlı ve yeniden üretilebilir süreler neredeyse her seferinde verdi
  • Intel sisteminde sonuç sapması daha büyüktü
    • Bazı çalıştırmalarda Snapdragon’dan daha hızlı olduğu da oldu
    • Ancak çoğu durumda geride kaldı
  • Genel sonuç olarak tüm testlerde Snapdragon üstün bulundu

Temel sonuç

  • Çeşitli sonuçların ortak noktası gecikme tutarlılığı oldu
  • Sanallaştırılmış Windows Server yüklerinde küçük ve sık işlere hızlı yanıt ile öngörülebilir zamanlama büyük önem taşıyor
  • Azami throughput odaklı iş yüklerinde x64 sistemler hâlâ belirgin avantaj taşıyor
  • Buna karşılık, tipik Windows Server dağıtımlarında olduğu gibi çok sayıda küçük ve gecikmeye duyarlı işin sanallaştırma altında birlikte çalıştığı ortamlarda ham tepe hızdan çok tutarlılık daha önemli
  • Bu bağlamda ARM64’ün cazibesi artıyor
  • ARM64 zaten bulut ortamlarında yaygın biçimde kullanılıyor ve maliyet başına performans oranının x64’ten daha iyi olduğuna da değiniliyor
  • Microsoft’un Windows Server’ın geleceğinde ARM64’ün payını artırmayı değerlendirmesi gerektiği öne sürülüyor
    • Microsoft şu anda Windows Server on ARM64 platformunu tam olarak desteklemiyor
    • Ancak geçen yıl yeni Microsoft Azure VM instance’larının %33’ünün, Amazon AWS tarafında ise %50’sinin ARM64 olduğu sayıları paylaşıldı

Eğitim amaçlı standart platform seçimi

  • Ders kitabı için uygulama ortamında hâlâ x64 standardizasyonu korunuyor
  • Bunun nedeni uygulama düzeninde iç içe sanallaştırma bulunması
  • Hyper-V’nin ARM64 üzerinde iç içe sanallaştırmayı desteklememesi nedeniyle ARM64 şu anda eğitim için varsayılan ortam olarak seçilmiyor
  • Öğrencilerin uygulamayı dolaylı yollarla kurması mümkün olsa da, ders kitabının hedeflerinden biri yeniden üretilebilirlik olduğu için adım adım aynı şekilde çalışan ortam öncelikli tutuluyor
  • Şu an için eğitim amacıyla x64 pratik seçenek olmaya devam ediyor

İlgili okumalar

1 yorum

 
GN⁺ 8 일 전
Hacker News görüşleri
  • Testi yeniden üretmek için gereken ayarlar, varsayımlar ve hatta kodun tamamı paylaşılmıştı ama hissedilen sonuç kısmı eksikti; bu yüzden biraz şüpheli gelmişti. ARM'in pratikte ne kadar hızlı olduğunu sayısal olarak merak etmiştim
    • Çıktı ekran görüntülerini bilerek eklememişti. Bunun bir benchmark yazısına dönüşmesini istememişti ve sonuçların ARM donanımına ya da Snapdragon X Elite'in alt modeline göre değişip yanlış anlamalara yol açabileceğini düşünmüştü. Bunun yerine herkes yeniden üretebilsin diye PowerShell snippet'i eklemişti. Kabaca sonuçlar, Snapdragon VM'in Intel VM'den teste göre yaklaşık %20 ila %80 daha hızlı olduğunu gösteriyordu; DNS yaklaşık %20, IIS yaklaşık %50, geri kalanlar ise çoğunlukla %80'e yakındı
  • Windows geliştiricisi açısından bakınca bunun büyük olasılıkla segment heap etkisi olduğu düşünülüyordu. Windows heap uygulamasında, eski NT heap ile 2010'larda gelen segment heap olmak üzere birbirinden bağımsız iki ayrı soy vardı ve segment heap, bellek parçalanması ile küçük ayırmaların yeniden kullanımı açısından daha verimliydi. Ancak Windows, geriye dönük uyumluluğa aşırı önem verdiği için, eski uygulamalar use-after-free gibi tehlikeli davranışlara ya da dahili NT heap yapılarına bağımlı olabileceğinden varsayılanı topluca değiştirmedi. Bu yüzden packaged çalıştırılabilir dosyalarda segment heap'i varsayılan yaptı, unpackaged tarafta ise eskisini koruyan bir orta yol seçti. Fakat UWP geçişi başarısız olunca Windows ekosistemi daha da parçalandı ve önemli yazılımların çoğu hâlâ unpackaged x64 olarak kaldı. Buna karşılık arm64 ikililerinin eski legacy kod olma ihtimali daha düşük olduğu için arm üzerinde segment heap varsayılan olarak etkinleştirildi. Kullanıcıların arm Windows'u daha tepkisel hissetmesinin azımsanmayacak bir kısmının bundan kaynaklandığı düşünülüyordu. x64 üzerinde segment heap'i zorla açıp bu testi yeniden yapmak ilginç olabilirdi. Çalıştırılabilir dosya bazında HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\.exe altında FrontEndHeapDebugOptions DWORD değerini 8 yapmak yeterliydi; sistem genelinde ise HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Segment Heap altında Enabled DWORD değerini 3 yapmak gerekiyordu. Kendi geliştirme makinesinde bunu sistem genelinde etkinleştirdikten sonra bir sorun görmemişti ve bellek kullanımı da testlerine göre yaklaşık %15 azalmıştı
    • Benim RAM/CPU yoğun iş yükümde, NT Heap'e kıyasla Segment Heap ile toplam performans tutarlı biçimde yaklaşık %7 arttı. Birleştirilmiş iş yükü %7 daha hızlı tamamlandı. Eskiden olduğu gibi Windows 10/11 için de bir "Compatible with Windows XXX" sertifikasyonu olsaydı, buna bir segment heap kontrol maddesi eklenip daha fazla uygulama ve kullanıcıya performans, enerji verimliliği ve çevresel fayda sağlanabilirdi diye düşünüyorum. Ayrıca UWP'nin sorunu teknolojinin kendisinden çok paketleme ve Store bağlantısında ısrar edilmesiydi; bu da Windows adlı işletim sisteminin varoluş biçimiyle çelişiyordu
    • İlgilenenler, kendi çalıştırılabilir dosyalarının application manifest içinde heapType değerini SegmentHeap yaparak bu davranışı opt-in edebilir. Belgelerde açıklanıyor
    • İşte HN'nin asıl değeri böyle pratik ipuçları. Sistem genelindeki registry anahtarının yeniden başlatma gerektirip gerektirmediğini, yoksa çalıştırılabilir dosya başlatıldığı andan itibaren mi uygulandığını merak ettim
    • Bu konu, forum yorumundan çok bir blog yazısı olarak kalmayı hak edecek kadar ilgi çekiciydi
    • Eskiden bu sistem genelindeki ayarın 0'a karşı non-zero şeklinde açıklandığını görmüştüm; değerin neden özellikle 3 olduğunu merak ediyorum. 2 ne anlama geliyor, bu tür değerlerin anlamını kendi başıma nereden doğrulayabilirim, onu da bilmek isterim
  • Yazıdaki "ARM yüksek boost clock peşinde koşmak yerine istikrarlı performans veriyor" ifadesi biraz abartılı geldi. Kullandığım ARM sistemlerin hepsi frekans ölçekleme yapıyordu ve bu açıdan x86'ya benzer davranıyordu. Sonuçta farkın, ne kadar yükseğe çıkabildiği meselesi olduğu düşünülüyordu
    • İş yüküne bağlıdır ama çalıştığım çeşitli kurumların bulut ortamlarında, x86'dan ARM'e geçiş tek başına bile ciddi maliyet düşüşü sağlamıştı. Bunun nedeni hem instance fiyatlarının daha düşük olması hem de verimliliğin daha iyi olmasıydı. Özellikle bir kurumda yüzlerce Kubernetes düğümünün dinamik otomatik ölçeklendiği bir ortamda, ek bir değişiklik yapmadan yalnızca x86 -> ARM geçişiyle temkinli tahminle bile yaklaşık %15 tasarruf öngörülmüş ve bu gerçekten elde edilmişti. CPU'ya yüklenen ve x86'ya özgü özelliklere daha az bağımlı iş yüklerinde bunun %15'ten çok daha fazla olabileceği düşünülüyordu
  • Eğer asıl mesele ARM CPU'ların daha az dalgalanan, daha öngörülebilir performansıysa, masaüstü CPU yerine Epyc gibi sunucu CPU'ları kullanıldığında da benzer faydalar görülebilir diye düşünülüyordu. Çünkü sunucu CPU'larında saat hızı dalgalanması daha düşüktür ve boost politikaları daha az agresiftir. Hatta mevcut masaüstü donanımında bile BIOS'tan Turbo kapatılarak Intel CPU temel saat hızına sabitlenebilir; böylece daha düşük olsa da kararlı ve öngörülebilir bir performans elde edilip karşılaştırma yapılabilir
    • Turbo davranışı, güç planı ayarlarından da kapatılabiliyordu. Yalnız bu seçenek GUI'de varsayılan olarak görünmeyebilir
  • Windows on ARM'ın VBS ya da Virtualization Based Security kullanıp kullanmadığı, ayrıca bunu VM içinde nested virtualization ile destekleyip desteklemediği merak ediliyordu. CPU güvenlik açığı azaltımlarının VM içinde iki kez uygulanıp performansı etkileyip etkilemediği de önemli görünüyordu. Çünkü bugünlerde Windows'u VM içinde çalıştırırken görülen performans sorunlarının önemli bir kısmı buradan kaynaklanıyor. Yazının buna değinmemesi eksiklik gibi geldi
  • İki sistemin RAM ve depolama yapılandırması merak ediliyordu. Snapdragon tarafında paketlenmiş RAM bulunduğundan interconnect daha hızlı olabilir, x86 tarafında ise DIMM kullanıldığı için izler daha uzun olabilir diye düşünülüyordu. Depolama ya da CPU modeli de performans farkını ciddi biçimde etkileyebilir. Benchmark'lar çoğu zaman sistemin bir bölümünü aşırı zorlar; dolayısıyla gerçek farkın ARM mimarisinin kendisinden değil RAM, syscall, SSD gibi başka unsurlardan geliyor olması da mümkündü
    • Her iki sistem de anakarta lehimli DDR5 ve NVMe SSD kullanıyordu. Hatta Intel tarafındaki SSD, Snapdragon tarafındaki Foresee'den daha hızlı olan bir Samsung modeliydi
  • Linux'ta her şey daha iyi çalışıyor ve döngüler gözetim overhead'i ile boşa harcanmıyor gibi geliyordu
  • Yazı, Intel işlemcinin ne olduğunu özellikle söylemekten kaçınıyormuş gibi görünüyordu; benim bir şeyi kaçırıp kaçırmadığımı merak ettim
    • Kullanılan CPU 14th Gen Intel Core i9 idi
  • HV sunucularında genelde C States'i devre dışı bırakma, güç yönetimini high yapma gibi yöntemlerle x86'nın saat hızını düşürmesi engellenir. CPU'nun sürekli aşağı-yukarı oynamasını durdurmak performansı ciddi biçimde artırabilir. Ancak bu tür ayarlar genelde kişisel ya da laboratuvar sistemlerinde pek yapılmaz
    • Ya da sadece turbo boost'u devre dışı bırakmak da yeterlidir
  • Yazıyı okuyunca bana göre esas nokta iki parçadan oluşuyordu. Birincisi, ARM64'ün x64 kadar "akıllı" olmaması; Core i9 gibi agresif biçimde boost ve throttle arasında gidip gelmek yerine istikrarlı performans vermesi ve bunun da işletim sistemi zamanlayıcısının işini kolaylaştırmasıydı. İkincisi, Windows'un ARM tarafında x64'e kıyasla daha az tarihsel yük taşıması nedeniyle ARM derlemesinin kendisinin daha verimli olma ihtimaliydi. Sonuçta CPU throttle mekanizmaları fazla akıllanıp ters etki yaratacak noktaya mı geldi diye düşündürüyor
    • Ancak bunun, sunucu işletim sisteminin masaüstü sınıfı bir x86 CPU üzerinde test edilmesiyle birlikte değerlendirilmesi gerekiyor. AMD Epyc ya da Intel Xeon gibi x86 sunucu CPU'larında saat hızı değişim aralığı daha küçüktür ve politikalar daha az agresiftir; bu yüzden masaüstü CPU'lara göre daha kararlı ve öngörülebilir performans verirler. Bu özellik çok iş parçacıklı iş yüklerinde avantaj sağlar; masaüstü CPU'lar ise tek iş parçacığında en yüksek performans için ayarlandığından çok iş parçacıklı senaryolarda tersine dezavantaj yaratabilir