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

131–140 of 156 posts

Re: Windows Server 2025 Runs Better on ARM

#131

Post by layer8 »

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.

You could say that Windows is giving you options while defaulting to backwards compatibility.

Re: Windows Server 2025 Runs Better on ARM

#132

Post by Panzer04 »

jasoneckert wrote: post #46
1970-01-01 wrote: post #39

>Across multiple runs of each test, the Snapdragon system produced consistent, repeatable timings nearly every time. On the Intel system, results varied significantly, occasionally beating the Snapdragon, but most of the time falling behind. The Snapdragon was the clear winner on each test overall. They blogged everything to generate the setup, including the hunch and test code but the anecdotal results are missing.…

I intentionally left out screenshots of the output for a couple of reasons: 1) They’d distract from the main point (I wasn’t aiming to write a benchmarking post), and 2) They can be misleading, since results will vary across ARM hardware and even between Snapdragon X Elite variants. Instead, I included the PowerShell snippets so anyone interested can reproduce the results themselves. For a rough sense of the outcome:…

When the numerical differences are that big I'd always be a little suspicious of something not operating correctly.

I haven't seen ARM outperform X86 by a margin that large anywhere else.

Re: Windows Server 2025 Runs Better on ARM

#133

Post by vrighter »

ryncewynd wrote: post #95
Alupis wrote: post #6

Earlier quoted context omitted.

The only people using MSSQL Server are people deep, deep in the Microsoft ecosystem. Think government work, and those unlucky enough to work at a pure Microsoft shop where every problem looks like a Microsoft or Azure solution. It's not a dominant database anywhere on the outside.

I've worked for plenty of companies using MsSql. They have all been dotnet ecosystem, but self hosted rather than Azure I think the latest versions of SQL Server also run on Linux now.

and it doesn't support NTLM auth afaik! Which is an extra bonus, as I don't remember there being a way to disable it in the windows version

Re: Windows Server 2025 Runs Better on ARM

#134

Post by lowbloodsugar »

Panzer04 wrote: post #132
jasoneckert wrote: post #46

Earlier quoted context omitted.

I intentionally left out screenshots of the output for a couple of reasons: 1) They’d distract from the main point (I wasn’t aiming to write a benchmarking post), and 2) They can be misleading, since results will vary across ARM hardware and even between Snapdragon X Elite variants. Instead, I included the PowerShell snippets so anyone interested can reproduce the results themselves. For a rough sense of the outcome:…

When the numerical differences are that big I'd always be a little suspicious of something not operating correctly. I haven't seen ARM outperform X86 by a margin that large anywhere else.

1988 would like a word.

Re: Windows Server 2025 Runs Better on ARM

#135

Post by p_ing »

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.

I don't see how this is a 'problem', but rather a tunable. And any decent OS has tunables. Would you rather not have this option?

Re: Windows Server 2025 Runs Better on ARM

#136

Post by fortran77 »

I love Windows on Arm. Except for a few edge cases with specialized device drivers, everything just works much better. My Widnows Arm Laptops feel fast and the battery lasts all day.

The biggest reason I still keep a Xeon and Threadripper server around is NVidia support.

Re: Windows Server 2025 Runs Better on ARM

#137

Post by chaps »

trollbridge wrote: post #58
chaps wrote: post #22

Earlier quoted context omitted.

These days I think airtable and other "no code" systems fit this bill well.

MSSQL doesn’t come with usage based pricing.

Sure, but you're just shifting that cost elsewhere. Not defending the no-code services (they're extremely predatory), just that it's not as simple as cost-vs-no-cost.

Re: Windows Server 2025 Runs Better on ARM

#138

Post by ww520 »

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 feel there should be a PowerToy applet to turn Segment Heap on or off.

Re: Windows Server 2025 Runs Better on ARM

#139

Post by kh9000 »

ack_complete wrote: post #130
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 per…

It's complicated. It's not always a straightforward space vs time tradeoff. For chromium's allocation patterns, it sounds like segment heap was slower. But BinaryNinja reported the opposite! See https://github.com/Vector35/binaryninja-api/issues/2778

Side note on the Chromium topic: Google Chrome decided NT Heap is still best for their usage, but Microsoft Edge, which is also built on the Chromium, uses segment heap. Not sure what Firefox uses. You can check by attaching WinDbg and doing !heap. Note that not every heap will be segment heap, even if you globally opt into segment heap. Some code paths explicitly create their own heaps as NT heaps.

At the very least, using fewer pages to allocate the same amount of data improves memory locality slightly. Folks should test and see what works best in their applications.

Another benefit of segment heap that we haven't discussed yet is that it's more strict and proactive about detecting problems and terminating. From what I understand, heap metadata is now stored separately from heap data, and they use guard pages. So heap buffer overruns don't overwrite the heap manager's bookkeeping. With NT heap, crashes due to use-after-free might manifest much later and more indirectly. Like, maybe it overwrote the free list, or it overwrote some newer allocation that landed on the same address. So, the crash is usually in some unlucky 'innocent bystander' call stack that worked with the corrupted region. With segment heap, you tend to get earlier, more actionable, specific crashing call stacks, closer to the site of the original bug. So, if you're an engineer who looks at a lot of difficult windows crash dumps involving memory corruption, segment heap makes the challenge slightly more surmountable.

Re: Windows Server 2025 Runs Better on ARM

#140

Post by kh9000 »

ww520 wrote: post #138
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 feel there should be a PowerToy applet to turn Segment Heap on or off.

This is a great idea, honestly. PowerToys is open source. There's a decent change that they would be open to such a contribution.

It is a crime that segment heap is over a decade old and still so underutilized. Gamers in particular go to such great lengths to tweak and optimize their windows machines for perf, but I still haven't seen that crowd discussing segment heap anywhere. It's more important than ever with the recent explosion in RAM cost.

Post reply on HN