Windows Server 2025 ARM पर बेहतर चलता है

 (jasoneckert.github.io)
1 पॉइंट द्वारा GN⁺ 2026-04-22 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • वर्चुअलाइज़्ड Windows Server 2025 की तुलना में ARM64 host पर ARM64 guest कॉन्फ़िगरेशन स्थिर रूप से चला, और service startup, management console launch तथा hands-on tasks में भी अधिक तेज़ महसूस होने वाली responsiveness देखी गई
  • दोनों VM में memory, virtual processor, और role configuration समान रखे गए, और measurement में Snapdragon system में CPU utilization का उतार-चढ़ाव कम था, Processor Queue Length लगातार 0 रहा, और CPU Wait Time Per Dispatch के मान भी स्थिर रहे
  • IIS, DNS, Active Directory query, domain authentication, और file I/O के repeated measurement में भी Snapdragon X Elite ने लगभग हर बार reproducible timing दिखाई, जबकि Intel कुछ runs में तेज़ था लेकिन कुल मिलाकर variation अधिक था
  • अंतर को केवल CPU architecture से नहीं जोड़ा गया; storage, memory, power management, और thermal characteristics के साथ latency consistency और predictable scheduling वर्चुअलाइज़्ड server workloads में अधिक महत्वपूर्ण लगे
  • maximum throughput-केंद्रित workloads में x64 की बढ़त बनी हुई है, लेकिन छोटे latency-sensitive tasks वाले सामान्य Windows Server deployments में ARM64 अधिक आकर्षक दिखता है; हालांकि training के standard platform के लिए ARM64 में nested virtualization सपोर्ट न होने से x64 ही रखा गया है

टेस्ट वातावरण और तुलना के मानदंड

  • Windows Server 2025 का virtual environment दो systems पर अलग-अलग बनाकर तुलना की गई
    • Windows 11 आधारित 14th Gen Intel Core i9 system पर कई Hyper-V virtual machines चलाई गईं
    • Windows 11 on ARM आधारित Snapdragon X Elite system पर भी वही Windows Server 2025 environment बनाया गया
  • Microsoft website पर Windows Server 2025 ARM का official install ISO उपलब्ध न होने के कारण, UUP dump से Microsoft update servers पर आधारित image बनाकर install किया गया
  • दोनों Hyper-V VM में memory, virtual processor, और installed roles समान रखे गए
    • Snapdragon X Elite: ARM64 guest on ARM64 host
    • Intel Core i9: x64 guest on x64 host

शुरुआती अवलोकन और व्याख्या की सीमा

  • ARM system पर Windows Server 2025 environment stable और सही ढंग से काम करने वाला था, और real-world use के स्तर पर कुल मिलाकर अधिक तेज़ महसूस हुआ
    • services जल्दी शुरू हुईं
    • management consoles तेज़ खुलीं
    • textbook writing के लिए practice tasks कम समय में पूरे हुए
  • हालांकि performance difference को केवल CPU architecture का परिणाम नहीं माना गया
    • storage, memory, power management, और thermal characteristics भी परिणामों को प्रभावित कर सकते हैं
    • “ARM तेज़ है” जैसी सीधी बात कहने के बजाय पूरे system की विशेषताओं के आधार पर व्याख्या ज़रूरी है
  • Windows Server के सामान्य service workloads में thread-heavy और छोटे लेकिन बार-बार होने वाले CPU और I/O tasks की प्रवृत्ति होती है
    • इसमें Active Directory, DNS, DHCP, IIS, SMB/NFS/DFS file services, Print Services, Certificate Services, Remote Desktop Services, Routing and Remote Access, NPS आदि शामिल हैं
    • ऐसे workloads latency और context switching के प्रति संवेदनशील होते हैं, इसलिए लगातार स्थिर performance का लाभ मिलता है

प्रदर्शन अंतर पर अवलोकन

  • Snapdragon परिवार के ARM systems में उच्च boost clock के पीछे भागने के बजाय लगातार और स्थिर performance देने की प्रवृत्ति देखी गई
  • आधुनिक Intel CPU में frequency boost और dynamic throttling के कारण उच्च peak performance मिल सकती है
    • लेकिन sustained load या mixed load में scheduling और latency variation बढ़ सकती है
  • virtualization environment में यह variation और महत्वपूर्ण हो जाती है
    • Hyper-V जैसा hypervisor व्यवहार में hardware scheduler की तरह काम करता है
    • hardware execution timing जितनी predictable होगी, hypervisor scheduling उतनी ही consistent होगी
    • इसका असर VM और उसके अंदर चल रही services की responsiveness पर पड़ता है
  • Windows Server ARM64 build में स्वयं कुछ अंतर होने की संभावना भी बताई गई
    • online उपलब्ध कई release notes के आधार पर, ARM64 version कुछ legacy compatibility layers से बचता है और संभवतः अधिक modern और optimized binaries का उपयोग करता है
    • यह x64 version की तुलना में अधिक cleaned-up build हो सकता है
    • हालांकि इसके लिए कोई ठोस internal implementation evidence नहीं दिया गया

Performance Monitor से मापन

  • दोनों Windows 11 hosts पर Performance Monitor counters जोड़कर measurement किया गया
    • \\Processor(_Total)\\% Processor Time
      • सभी cores के आधार पर CPU usage
    • \\System\\Processor Queue Length
      • CPU time की प्रतीक्षा कर रहे threads की संख्या
      • आदर्श रूप से 0 रहना बेहतर है
    • \\Hyper-V Hypervisor Virtual Processor(*)\\CPU Wait Time Per Dispatch
      • virtual processor को CPU पर schedule होने से पहले प्रतीक्षा का औसत समय
  • प्रत्येक VM के अंदर PowerShell से load generate करके परिणाम देखे गए
    • Get-Process के परिणामों को CPU usage के आधार पर sort करके top 5 को बार-बार query करने वाला infinite loop 8 बार चलाया गया
  • measurement results में Snapdragon ने लगातार और स्थिर performance pattern दिखाया
    • % Processor Time में उतार-चढ़ाव बहुत कम था
    • Processor Queue Length लगातार 0 रहा
    • CPU Wait Time Per Dispatch भी समतल और स्थिर रहा
  • Intel system में boost/throttle variability metrics में साफ़ दिखी
    • % Processor Time का उतार-चढ़ाव अधिक था
    • Processor Queue Length समय-समय पर तेज़ी से बढ़ा
    • CPU Wait Time Per Dispatch में भी उल्लेखनीय variation दिखा

service responsiveness का मापन

  • हर VM की PowerShell में Measure-Command का उपयोग करके सामान्य service tasks का समय मापा गया
  • IIS web server पर टेस्ट किया गया
    • Invoke-WebRequest http://localhost -UseBasicParsing | Out-Null को 1000 बार दोहराया गया
  • इसी तरह अन्य services का भी repeated measurement किया गया
    • DNS
      • Resolve-DnsName "domainX.com" -Server 127.0.0.1 | Out-Null
    • Active Directory query
      • Get-ADUser -Filter * -ResultSetSize 1 | Out-Null
    • domain authentication latency
      • Test-ComputerSecureChannel -Verbose:$false
    • file I/O
      • C:\TestFiles directory बनाई गई
      • 2000 repetitions में file create, write, read, और delete किया गया
  • कई बार दोहराने पर Snapdragon system ने लगभग हर बार consistent और reproducible timings दर्ज कीं
  • Intel system में परिणामों में variation अधिक था
    • कुछ runs में वह Snapdragon से तेज़ भी था
    • लेकिन अधिकांश मामलों में पीछे रहा
  • कुल मिलाकर निष्कर्ष यह रहा कि लगभग सभी tests में Snapdragon आगे रहा

मुख्य निष्कर्ष

  • सभी परिणामों में जो साझा तत्व उभरकर आया, वह था latency consistency
  • वर्चुअलाइज़्ड Windows Server workloads में छोटे लेकिन बार-बार होने वाले tasks पर तेज़ response और predictable scheduling बहुत महत्वपूर्ण हैं
  • maximum throughput महत्वपूर्ण होने वाले workloads में x64 systems की स्पष्ट बढ़त अभी भी बनी हुई है
  • इसके विपरीत, सामान्य Windows Server deployment की तरह ऐसे environments में जहाँ कई छोटे latency-sensitive tasks virtualization के तहत साथ चल रहे हों, वहाँ सिर्फ़ peak speed से अधिक consistency अहम होती है
  • इसी संदर्भ में ARM64 का आकर्षण बढ़ता है
  • ARM64 पहले से ही cloud environments में व्यापक रूप से उपयोग हो रहा है, और यह भी कहा गया कि performance-per-cost ratio x64 से बेहतर हो सकता है
  • यह सवाल उठाया गया कि Microsoft को Windows Server के भविष्य में ARM64 की बड़ी भूमिका पर विचार करना चाहिए
    • फिलहाल Microsoft Windows Server on ARM64 को fully support नहीं करता
    • लेकिन पिछले वर्ष नए Microsoft Azure VM instances में 33% और Amazon AWS में 50% ARM64 थे, ऐसा आँकड़ा दिया गया

शिक्षा के लिए standard platform का चयन

  • textbook lab environment के लिए अभी भी x64 standardization बनाए रखी गई है
  • कारण यह है कि lab setup में nested virtualization शामिल है
  • Hyper-V में ARM64 पर nested virtualization support न होने के कारण ARM64 को फिलहाल training के default environment के रूप में नहीं चुना गया
  • छात्र चाहें तो labs को workaround के साथ चला सकते हैं, लेकिन textbook का एक लक्ष्य reproducibility भी है, इसलिए step-by-step समान रूप से काम करने वाले environment को प्राथमिकता दी गई
  • इस समय education use case के लिए x64 ही व्यावहारिक विकल्प बना हुआ है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-04-22
Hacker News टिप्पणियाँ
  • टेस्ट को दोहराने के लिए ज़रूरी सेटिंग्स, अनुमान और कोड सब साझा किए गए थे, लेकिन अनुभूत परिणाम खुद गायब थे, इसलिए थोड़ा संदेह हुआ। ARM वास्तव में कितना तेज़ था, इसके आँकड़े जानने की उत्सुकता थी
    • आउटपुट स्क्रीनशॉट जानबूझकर छोड़े गए थे। मकसद इसे benchmark पोस्ट की तरह धुंधला करना नहीं था, और ARM हार्डवेयर या Snapdragon X Elite के किस सटीक मॉडल पर चल रहा है उसके हिसाब से नतीजे बदल सकते थे, जिससे गलतफहमी हो सकती थी। इसलिए उसकी जगह ऐसा PowerShell snippet दिया गया था जिसे कोई भी दोहरा सके। मोटे तौर पर, Snapdragon VM, Intel VM से टेस्ट के हिसाब से लगभग 20~80% तेज़ था; DNS में लगभग 20%, IIS में लगभग 50%, और बाकी ज़्यादातर मामलों में 80% के करीब
  • Windows डेवलपर के नज़रिए से देखें तो इसकी वजह segment heap होने की संभावना काफ़ी बड़ी लगती है। Windows heap implementation में दो अलग-अलग वंश हैं: पुराना NT heap और 2010 के दशक का segment heap, और segment heap memory fragmentation तथा छोटे allocations के reuse के मामले में ज़्यादा efficient था। लेकिन Windows legacy compatibility को बहुत गंभीरता से लेता है, इसलिए पुराने apps use-after-free जैसे जोखिमभरे behavior या अंदरूनी NT heap structures पर निर्भर हो सकते थे, इस वजह से default को एक साथ नहीं बदला गया। इसलिए packaged executables पर segment heap को default बनाया गया और unpackaged वाले वैसे ही छोड़ दिए गए। लेकिन UWP migration असफल रहने से Windows ecosystem और बिखर गया, और ज़्यादातर महत्वपूर्ण software अब भी unpackaged x64 ही रहा। दूसरी ओर, arm64 binaries के पुराने legacy code होने की संभावना कम थी, इसलिए arm पर segment heap default रूप से enabled है। उपयोगकर्ताओं को arm Windows ज़्यादा responsive लगने की एक बड़ी वजह शायद यही है। x64 पर segment heap को ज़बरदस्ती enable करके यह टेस्ट फिर से चलाया जाए तो दिलचस्प होगा। प्रति executable, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\.exe के नीचे FrontEndHeapDebugOptions DWORD को 8 पर सेट किया जा सकता है, और global रूप से HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Segment Heap के नीचे Enabled DWORD को 3 पर। मेरी development machine पर global enable करने के बाद कोई समस्या नहीं दिखी, और memory usage टेस्ट के आधार पर लगभग 15% कम हुआ
    • मेरे RAM/CPU intensive workload में NT Heap की तुलना में Segment Heap से कुल performance लगातार लगभग 7% बेहतर हुई। संयुक्त काम लगभग 7% जल्दी खत्म हुआ। अगर पुराने ज़माने की "Compatible with Windows XXX" जैसी certification Windows 10/11 में भी होती, तो उसमें segment heap का check जोड़कर ज़्यादा apps और users को performance, power efficiency और पर्यावरणीय लाभ दिए जा सकते थे। और UWP की समस्या तकनीक से ज़्यादा packaging और Store के साथ उसके ज़िद्दी coupling में थी, जो Windows जैसे OS के अस्तित्व के तरीके से टकराती थी
    • जिनकी रुचि हो, वे अपने executable के application manifest में heapType को SegmentHeap पर सेट करके इस behavior को opt-in कर सकते हैं। दस्तावेज़ में इसका विवरण है
    • इसी तरह के व्यावहारिक tips ही HN की असली value लगते हैं। जिज्ञासा थी कि global registry key के लिए reboot चाहिए या यह executable शुरू होते ही तुरंत लागू हो जाता है
    • यह सामग्री forum comment से बढ़कर blog post के रूप में रहने लायक दिलचस्प थी
    • पहले मैंने इस global setting को 0 बनाम non-zero के रूप में समझाया गया देखा था, इसलिए यह जानने की उत्सुकता हुई कि value खास तौर पर 3 ही क्यों है। 2 का क्या मतलब है, और ऐसे values का अर्थ खुद कहाँ से verify किया जा सकता है, यह भी जानना था
  • लेख में "ARM ऊँचे boost clock के पीछे नहीं भागता और steady performance देता है" जैसी बात थोड़ी बढ़ा-चढ़ाकर कही हुई लगी। मैंने जो भी ARM systems इस्तेमाल किए, वे सब frequency scaling करते थे, और उस मामले में x86 जैसे ही व्यवहार करते थे। आख़िरकार फ़र्क बस इतना लगा कि वे कितनी ऊँचाई तक जाते हैं
    • यह workload पर निर्भर हो सकता है, लेकिन जिन कई संगठनों के cloud environments में मैंने काम किया, वहाँ x86 से सिर्फ ARM migration करने भर से भी लागत में काफ़ी कमी आई। instance कीमत कम थी और efficiency भी बेहतर थी। खासकर एक संगठन में, जहाँ सैकड़ों Kubernetes nodes dynamic autoscaling के साथ चल रहे थे, वहाँ बिना किसी अतिरिक्त बदलाव के सिर्फ x86 -> ARM से ही सावधानीपूर्ण अनुमान में भी लगभग 15% बचत की उम्मीद थी, और वह वास्तव में हासिल भी हुई। अगर workload CPU-bound हो और x86-specific features पर कम निर्भर हो, तो यह 15% से कहीं ज़्यादा भी हो सकता है
  • अगर ARM CPU की कम डगमगाने वाली और ज़्यादा predictable performance ही मुख्य कारण थी, तो desktop CPU की जगह Epyc जैसे server CPU से भी ऐसा ही लाभ मिल सकता है। server CPUs में clock variation कम होता है और boost policy भी कम aggressive होती है। यहाँ तक कि मौजूदा desktop hardware पर भी BIOS में Turbo बंद करके Intel CPU को base clock पर fix किया जा सकता है, जिससे भले performance कम हो, लेकिन stable और predictable behavior बनाकर तुलना की जा सकती है
    • power management plan में भी turbo behavior बंद किया जा सकता था। हालाँकि संभव है कि वह setting GUI में default रूप से दिखाई न दे
  • यह जानने की उत्सुकता थी कि Windows on ARM VBS या Virtualization Based Security का उपयोग करता है या नहीं, और क्या VM के अंदर nested virtualization के साथ उसका support मिलता है। साथ ही यह भी महत्वपूर्ण लगा कि CPU vulnerability mitigations VM में दोहरी परत के रूप में लागू होकर performance को प्रभावित कर रही हैं या नहीं। आजकल Windows को VM में चलाने पर दिखने वाली performance समस्याओं का बड़ा हिस्सा यहीं से आता है। लेकिन लेख में इसका ज़िक्र नहीं था, जो थोड़ा खला
  • दोनों systems की RAM और storage configuration जानने की इच्छा थी। Snapdragon पक्ष में packaged RAM होने से interconnect तेज़ हो सकता है, जबकि x86 पक्ष में DIMM होने से traces लंबे हो सकते हैं। storage या CPU model भी performance gap को बहुत प्रभावित कर सकते हैं। benchmark अक्सर system के किसी एक हिस्से को ज़रूरत से ज़्यादा stress करते हैं, इसलिए संभव है कि असली अंतर ARM architecture से ज़्यादा RAM, syscall, SSD जैसे दूसरे कारकों से आ रहा हो
    • दोनों systems में motherboard पर soldered DDR5 और NVMe SSD इस्तेमाल हुए थे। बल्कि Intel पक्ष का SSD, Snapdragon वाले Foresee से तेज़ Samsung model था
  • Linux पर सब कुछ बेहतर चलता है, और monitoring overhead में cycles बर्बाद नहीं होते, ऐसा महसूस हुआ
  • लेख ऐसा लगा मानो Intel processor कौन-सा था, यह बात जानबूझकर टाली गई हो, इसलिए उत्सुकता हुई कि कहीं मैं कुछ मिस तो नहीं कर रहा
    • इस्तेमाल किया गया CPU 14th Gen Intel Core i9 था
  • HV servers में आम तौर पर C States disable करना, power management को high पर रखना जैसी चीज़ें की जाती हैं ताकि x86 downclock न करे। CPU को ऊपर-नीचे डगमगाने से रोका जाए तो performance काफ़ी सुधर सकती है। हालाँकि ऐसी चीज़ें आम तौर पर personal या lab machines पर नहीं की जातीं
    • या फिर बस turbo boost disable कर देना भी काफ़ी है
  • लेख पढ़ने के बाद लगा कि मूल बात दो हिस्सों में बँटी है। पहला, ARM64 शायद x64 की तुलना में कम "smart" है, इसलिए Core i9 की तरह aggressive boost और throttling को बार-बार दोहराने के बजाय स्थिर performance देता है, जिससे OS scheduling आसान हो जाती है। दूसरा, Windows पर ARM में x64 की तुलना में ऐतिहासिक बोझ कम है, इसलिए ARM build खुद में ज़्यादा efficient हो सकती है। आख़िरकार जिज्ञासा यही रही कि क्या CPU throttling इतनी ज़्यादा "चतुर" हो गई है कि अब उलटा नुकसान पहुँचाने लगी है
    • हालाँकि इसे इस संदर्भ में भी देखना चाहिए कि यह server OS को desktop x86 CPU पर टेस्ट करने का मामला था। AMD Epyc या Intel Xeon जैसे x86 server CPUs में clock variation की सीमा कम होती है और policy भी कम aggressive होती है, इसलिए वे desktop CPUs की तुलना में ज़्यादा स्थिर और predictable performance देते हैं। ऐसी विशेषताएँ multithreaded workloads में फ़ायदा देती हैं, जबकि desktop CPUs single-thread peak performance के लिए tuned होते हैं, इसलिए multithreaded काम में उलटा नुकसान भी हो सकता है