CachyOS has also put out a repository of packages compiled for zen4/5 [1], which I'm fairly sure Phoronix has shown an interest in doing an updated comparison against the current x86_64-v2/v3/v4/etc versions
The background for this really puzzles me. AMD said you should be seeing more improvement for zen 5 over zen 4. They go back and forth, AMD says run it as super root. Zen 5 gets faster. But zen 4 gets faster too. The improvement basically disappears again when the "fix" is applied universally. So why was AMD testing with two different setups?
The phoronix bench suite showed performance in line of expectations. Its specifically games on windows that regressed. I have no clue how windows scheduler works but that can have a huge impact in games specifically.
Compared to Zen4, Zen5 has much higher latency between cores on different chiplets. It's possible that a scheduler + app combo could regress on Zen5 for this reason. It sounds basically impossible for single-threaded apps to be impacted because timeslices are really big. Multithreaded apps where threads are communicating constantly could easily run slower if the scheduler sees all the cores as identical and interchangeable.
I don't know much about this topic, but it seems like Windows uses Processor Groups for scheduling[0], and generally tries to fit each NUMA node into 1 Processor Group (as long as it has at most 64 cores in it). Since the issue here is latency between chiplets and no NUMA is involved, all the cores go in the same Processor Group.
This sounds like a trivial fix: put the two chiplets into separate processor groups, because that's effectively what they are.
This feature was originally about non-uniform memory access (NUMA), but effectively it is "core-to-socket" mapping. If a processor has chiplets on it, then it's effectively sockets-within-sockets. The software needs just a minor update to consider the chiplets to be the scheduling boundary instead of the AM5 socket.
Windows 'processor groups' aren't at all similar to linux NUMA aware scheduling, which is the proper method regardless,
There's 64 bits that represent all cores on the system, setting those bits defines how a process is assigned to a core. The 'processor groups' is a hack that keeps the same bitmask that they originally used.
My understanding was that a thread is only eligible to be scheduled in a single processor group at any given time, and that windows will not change the group. Is that wrong?
That WAS correct. They corrected that after realising a 96-core processor has less cores available than a 64-core processor since processor groups split cores evenly.
my guess is there is a bug in Windows related to scheduling which makes Zen 5 slower and by using the admin accounts for testing but comparing to Zen 4 tests results without admin account it was obfuscated.
I mean on Linux Zen 5 seems to be clearly faster then Zen 4 by a good margin.
The usual consensus I've heard is that UAC is always on even after turning the slider all the way off, while using the admin account doesn't use UAC (changing the EnableLUA in reg also works).
This is the first I'm reading that UAC has a performance impact and I'd like to know more.
I have a PC that I literally use for single player games and nothing else (I do not have a web browser installed, or even Steam, games are installed from a network share). I have no use for UAC and I'd like to squeeze everything out of my CPU.
UAC is not a security boundary. Its only there to prevent the user from accidentally making changes to the system that they didn't intend, but it provides no security except from your own mistakes. Its so much not considered a security boundary that microsoft doesn't even offer a bug bounty for UAC bypasses.
> Its only there to prevent the user from accidentally making changes to the system that they didn't intend, but it provides no security except from your own mistakes
If you somehow bypass UAC and gain the Administrators-level access then you already run with Administrator level privileges in the first place, just with a medium mandatory level.
A rope on the edge of a cliff isn't there to prevent you from falling, it's there to notify you what you should be careful. Rope works. UAC works.
Oh, user separation is not a security boundary? I was not aware! Let’s all work as root then! /s
The fact that this was the norm on single-user Windows workstations until Windows Vista is astonishing, to say the least. How anyone could want that back is beyond me. It enabled malware to compromise the entirety of the computer with ease. No exploits or anything required! Certainly not one of these pesky UAC prompts!
Can you still shoot yourself in the foot with UAC? Yes. You own the PC. You should be able to shoot yourself in the foot, by willingly deciding to. Not accidentally.
>One of the common misconceptions about UAC and Same-desktop Elevation in particular is: it prevents malware from being installed, or from gaining administrative rights. First, malware can be written not to require administrative rights. And malware can be written to write just to areas in the user's profile. More important, Same-desktop Elevation in UAC isn't a security boundary. It can be hijacked by unprivileged software that runs on the same desktop. Same-desktop Elevation should be considered a convenience feature. From a security perspective, Protected Administrator should be considered the equivalent of Administrator. By contrast, using Fast User Switching to sign in to a different session by using an administrator account involves a security boundary between the administrator account and the standard user session.
UAC is not a security boundary, it's not the same thing as sudo on Unix. You only have a security boundary in place if Windows asks you for a password when trying to run as Administrator.
You might be mistaken because what you are quoting specifically talks about Same-desktop Elevation. While on Windows, UAC uses Secure Desktop by default, which is by definition a security boundary.
> You only have a security boundary in place if Windows asks you for a password when trying to run as Administrator.
Per the last sentence of the information that you quoted:
> By contrast, using Fast User Switching to sign in to a different session by using an administrator account involves a security boundary between the administrator account and the standard user session.
Fast User Switching requires the user to enter the administrator credentials in the UAC prompt.
This is why I mentioned that the PC in question is a gaming box exclusively. There's really nothing to steal here. Maybe you could plant a virus on my network drive to leap to other computers, but that seems pretty far fetched, especially since any software is coming from that drive in the first place.
Is there any good reason for Microsoft to not open-source Windows? They are dangerously close to creating the Year of the Linux Desktop if they continue proving Wirth right.
How is the built-in Administrator account faster than a named account?
I wonder if its a bloatware effect. They need to test with all bloatware removed. No control flow guard, defender, firewall, appearance to performance, no sounds, no background, microcode dll's deleted, mitigations disabled in regedit, storport disabled, every service disabled, every app deleted, edge deleted etc.
From the article it sounds like it’s a change to scheduling priorities not what is running (from other comments it sounds like there’s a change in latency related to moving processes across cores in different packages?)
There is absolutely no detail here. Tl;dr maybe Ryzen CPUs are a handful of percent faster when testing under the admin account instead of non-admin. Is it reproducible? Who knows. What does Windows 11 have to do with it? Who knows. We know nothing after reading the article.
9950X is 14% faster than 7950X on Ubuntu. And 10% faster on Windows.
Ubuntu is 10% faster than Windows on the same hardware.