Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Windows Server 2025 Runs Better on ARM

jasoneckert.github.io

Post reply on HN
Print view View original

121–130 of 156 posts

Re: Windows Server 2025 Runs Better on ARM

#121

Post by cloudbonsai »

adrian_b wrote: post #110
cloudbonsai wrote: post #69

Reading the article, it seems to boil down to the following two observations: 1. ARM64 is actually less "smart" than x64. While Intel's Core i9 tries to be clever by aggressive boosting and throttling, Snapdragon just delivers steady and consistent performance. This lack of variability makes it easier for the OS to schedule tasks. 2. It is possible that the ARM build is more efficient than the x64 build, because Wind…

It should be noted that this is a server OS, but it has been tested on a desktop x86 CPU. The x86 server CPUs, like AMD Epyc or Intel Xeon, have a lower range within which the clock frequency may vary and their policies for changing the clock frequency are less aggressive than for desktop CPUs, so they provide a more constant and predictable performance, which favors multi-threaded workloads, unlike in desktop CPUs,…

That makes a lot of sense!

> The x86 server CPUs, like AMD Epyc or Intel Xeon, have a lower range within which the clock frequency may vary and their policies for changing the clock frequency are less aggressive than for desktop CPUs

Probably we need to compare Xeon/EPYC with something like AWS Graviton or Ampere Altra to get an accurate picture here. That said, I think "Windows Server works fast on Snapdragon" is both crazy and fascinating; I wasn't even sure if that was possible.

Re: Windows Server 2025 Runs Better on ARM

#122

Post by p_ing »

Melatonic wrote: post #101
p_ing wrote: post #18

Earlier quoted context omitted.

Azure services run on [customized] Hyper-V, thus Windows Server. Azure networking is Linux. EDIT: Marvel at the NT4 style Task Manager [0]. [0] https://techcommunity.microsoft.com/blog/windowsosplatform/a...

Guessing some of Azure networking (or storage controllers) might even be BSD based ?

Azure networking is Microsoft's own Linux: Azure Linux [0]. I don't know what they use for storage controllers.

[0] https://en.wikipedia.org/wiki/Azure_Linux

Re: Windows Server 2025 Runs Better on ARM

#123

Post by josephg »

Melatonic wrote: post #100
jasoneckert wrote: post #59

Earlier quoted context omitted.

Both systems have DDR5 soldered to the mainboard and NVMe SSDs (the Intel system has a faster Samsung model compared to the Foresee model in the Snapdragon system).

Would be good test those SSD to see when they thermally throttle. Most hit pretty fast (on desktop drives it's quite easy to add heat sinks and they make a big difference)

Yep. There's lots of things I'd want to test before assuming the ARM architecture is fundamentally better than x86 in some way.

Re: Windows Server 2025 Runs Better on ARM

#124

Post by cesarb »

jeroenhd wrote: post #118
garganzol wrote: post #117

Earlier quoted context omitted.

I've measured NT Heap vs. Segment Heap for my RAM and CPU intensive workloads and got a steady 7% overall performance improvement. The combined workload finishes 7% quicker with the Segment Heap. P.S. In Windows 95 - Windows Vista era, there was a good tradition of "Compatible with Windows XXX" certifications for apps. If MS did something like that for Windows 10/11 and included the segment heap tick mark into it, a…

UWP is not strictly tied to the Windows store (you can install UWP applications packaged in the right format(s) from the command line, for business deployments for instance), but it might as well be when it comes to consumers. I can't really complain, though. If UWP would've broken through, the Steam Deck would've probably been a much more massive undertaking to get working right. As long as developers can opt into t…

> As long as developers can opt into the new system (which they can with the manifest approach) [...] Microsoft has added a mishmash of flags in the app manifest

Could you please tell me, where are all these manifest flags documented? I asked about it a decade and a half ago at stackoverflow (https://stackoverflow.com/questions/5733085/application-mani...), and the only answer was "there isn't".

Re: Windows Server 2025 Runs Better on ARM

#125

Post by [deleted] »

bob1029 wrote: post #105
phwbikm wrote: post #8

Cant believe somebody is still using windows server? What’s the use case?

Mine is a ~10-person bank consultancy without time or energy to deal with elite neck beard problems. Windows server, mssql and .NET are a great combo. I wish we could separate the paid/oss aspects from the technical ones because Microsoft absolutely runs circles around every other stack when it comes to serious business software solutions, especially in resource constrained teams. I agree that oss and free software i…

[deleted]

Re: Windows Server 2025 Runs Better on ARM

#126

Post by nnevatie »

kh9000 wrote: post #37

Windows developer here. After reading this post, my gut instinct is that this is due to something called 'segment heap'. A bit of backstory: there are two, totally independent implementations behind the Windows heap allocation APIs (i.e. the implementation code behind RtlHeapAlloc and RtlHeapFree, which are called by malloc/free). The older of the two, developed uring the Dave Cutler era, is known as the "NT heap". T…

Ahh, a Windows problem surfaces - so does a registry hack allegedly fixing the problem. That's basically the (sad) story of Windows today.

Re: Windows Server 2025 Runs Better on ARM

#127

Post by creaturemachine »

nnevatie wrote: post #126
kh9000 wrote: post #37

Windows developer here. After reading this post, my gut instinct is that this is due to something called 'segment heap'. A bit of backstory: there are two, totally independent implementations behind the Windows heap allocation APIs (i.e. the implementation code behind RtlHeapAlloc and RtlHeapFree, which are called by malloc/free). The older of the two, developed uring the Dave Cutler era, is known as the "NT heap". T…

Ahh, a Windows problem surfaces - so does a registry hack allegedly fixing the problem. That's basically the (sad) story of Windows today.

One could also call it tuning.

Re: Windows Server 2025 Runs Better on ARM

#128

Post by jeroenhd »

cesarb wrote: post #124
jeroenhd wrote: post #118

Earlier quoted context omitted.

UWP is not strictly tied to the Windows store (you can install UWP applications packaged in the right format(s) from the command line, for business deployments for instance), but it might as well be when it comes to consumers. I can't really complain, though. If UWP would've broken through, the Steam Deck would've probably been a much more massive undertaking to get working right. As long as developers can opt into t…

> As long as developers can opt into the new system (which they can with the manifest approach) [...] Microsoft has added a mishmash of flags in the app manifest Could you please tell me, where are all these manifest flags documented? I asked about it a decade and a half ago at stackoverflow ( https://stackoverflow.com/questions/5733085/application-mani... ), and the only answer was "there isn't".

https://learn.microsoft.com/en-us/windows/win32/sbscs/applic... has the majority here.

I don't see why you'd need a separate flag for memory management, Windows version, printer driver isolation, awareness of long paths, and all of that jazz.

Still, https://learn.microsoft.com/en-us/windows/win32/sbscs/applic... has a setting to enable modern memory management.

Re: Windows Server 2025 Runs Better on ARM

#130

Post by ack_complete »

kh9000 wrote: post #37

Windows developer here. After reading this post, my gut instinct is that this is due to something called 'segment heap'. A bit of backstory: there are two, totally independent implementations behind the Windows heap allocation APIs (i.e. the implementation code behind RtlHeapAlloc and RtlHeapFree, which are called by malloc/free). The older of the two, developed uring the Dave Cutler era, is known as the "NT heap". T…

Two issues.

First, regarding application compatibility: the heap was already changed once prior to the segment heap. The Low Fragmentation Heap (LFH) was added in XP and made default in Vista, with applications no longer having to opt into it:

https://learn.microsoft.com/en-us/windows/win32/memory/low-f...

Second, the segment heap has different tradeoffs that make it not a guaranteed win to swap in, it trades off performance for working set:

https://issues.chromium.org/issues/40138716

Post reply on HN