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

111–120 of 156 posts

Re: Windows Server 2025 Runs Better on ARM

#111

Post by adrian_b »

whatever1 wrote: post #55

I mean we were suspecting for some time that smartphone processors have reached parity with laptop class ones. MacBook Neo proved it. Not clear how both Amd and Intel not only lost the smartphone fight but also lost in their own field (aka servers, laptops, desktops) 15 years ago if I told you that windows would be running better on ARM you would call me crazy.

For now, in server applications the ARM CPUs can win when the workloads are not computationally intensive, i.e. they consist mostly in data transfers and searches, for example in Web servers, database servers, storage servers, networking appliances, etc.

There still are applications where ISA matters, like technical/scientific computing, where the performance can be dominated by array operations or operations with big numbers. For such workloads the x86 CPUs with AVX-512 can provide a performance per watt and per dollar that cannot be reached by the current ARM-based CPUs.

Re: Windows Server 2025 Runs Better on ARM

#112

Post by adrian_b »

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…

I have no longer used Windows servers for a very long time, but when I still worked in a company that used Windows servers, the problem was not that we had to pay for it.

The problem was that the cost was not fixed and predictable, because every now and then we wanted to extend our activities, and that was conditioned by buying extra Microsoft licenses, for additional users, additional CPU cores or sockets, additional services, and so on.

This was extremely annoying in comparison with using a FreeBSD or Linux server, where the operating costs were the same regardless of how we decided to use it.

I agree that in a less dynamic environment, where the requirements for the server are stable and unlikely to ever be changed, using a Windows server may be OK.

However in any organization where this is not true, I believe that using any Windows server is a loser strategy, due to the financial friction that it causes against any improvements in the IT environment.

Re: Windows Server 2025 Runs Better on ARM

#113

Post by pjc50 »

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…

This is the sort of extremely valuable hint that makes HN worthwhile.

Does that global registry key require a reboot, or does it just take effect on executable launch?

Re: Windows Server 2025 Runs Better on ARM

#114

Post by baq »

jdw64 wrote: post #102
phwbikm wrote: post #8

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

In practice, Windows is still the de facto standard in industrial software. At least in my experience I’m based in Korea and have worked on code that goes into enterprise systems — most MES and related systems are still built around MS SQL. SQL Server is very much alive in that space. It may feel outdated from a modern app development perspective, but the reality is that it’s deeply embedded through vendor lock-in. W…

SQL Server is an amazing RDBMS. Expensive as hell, too.

Re: Windows Server 2025 Runs Better on ARM

#115

Post by p_ing »

Melatonic wrote: post #98
p_ing wrote: post #2

Typical approach on an HV server is to disable C States, set power management to high, etc preventing x86 from downclocking. Keeping the CPU from seesawing can have big improvements. But you’re not going to do that in a lab/personal machine, usually.

Or just disable turbo boost

That’s not sufficient as you will still downclock.

Re: Windows Server 2025 Runs Better on ARM

#116

Post by garganzol »

lloydatkinson wrote: post #103
kh9000 wrote: post #85

Earlier quoted context omitted.

It's a combinination of bit flags. The lowest bit controls whether segment heap is on or off. The 2nd lowest bit bit controls some additional optimizations that go along with it, something about multithreading. A value of 3 (both flags set) gives you identical behavior to what specifying SegmentHeap in your application manifest does. Using the application manifest approach is the right way to ship software that opts…

Would the (not Framework) .NET apps I work on benefit from this?

Any app using memory allocation functions would benefit from a newer heap implementation independently of a technology it's created with, unless it's actively constrained by compatibility burdens. In case of .NET, the memory layout compatibility is not something you usually care about unless the app loads old 3rd party .DLLs through P/Invoke. So for 99.9% of .NET (not Framework) apps, the segment heap should work just fine.

Re: Windows Server 2025 Runs Better on ARM

#117

Post by garganzol »

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…

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 considerably larger amount of apps and its users would benefit from increased performance. Think better energy consumption and eco-friendliness as additional bonuses.

P.S. 2: The problem with UWP was not the technology itself, it was the stubbornness to have it packaged and tied to The Store, all of which contradicts the very existence of Windows as an OS.

Re: Windows Server 2025 Runs Better on ARM

#118

Post by jeroenhd »

garganzol wrote: post #117
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…

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 the new system (which they can with the manifest approach), I don't think it matters whether you're doing UWP or traditional Windows applications.

Microsoft has added a mishmash of flags in the app manifest and transparently supports manifest-less applications, so developers don't have a need to ever bother including a manifest either.

It'd annoy a lot of people, but if Windows would show a "this app has been written for an older version of Windows and may be slower than modern applications" warning for old .exes (or maybe one of those popups they now like about which apps are slower than they could be), developers would have an incentive to add a manifest to their applications and Microsoft could enable a lot more of these optimisations for a lot more applications.

Re: Windows Server 2025 Runs Better on ARM

#119

Post by chronogram »

adrian_b wrote: post #106

If indeed the supposition that the less variable and more predictable performance of the ARM CPU mattered for the observed system behavior is right, then using an x86 server CPU, e.g. an Epyc CPU, instead of a desktop CPU would provide similar benefits to the ARM CPU, because server CPUs have a lower range of variation for the clock frequency and they use less aggressive clock frequency boosting policies. This could…

You can also disable turbo behaviour in the power plan. The setting might not be available in the GUI by default though.

Re: Windows Server 2025 Runs Better on ARM

#120

Post by nikanj »

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…

I feel like this is a very common attitude amongst people who actually have delivered software as a day job for a few years. The raging sports-fan-esque Linux vs Windows fanboy battles are mostly fought by unemployed kids who still have time to customize their desktops.
Post reply on HN