Personal computing discussed
Moderators: renee, Flying Fox, morphine
chuckula wrote:OK:
1. Why didn't they turn on the "high performance" profile for the Intel processors?
2. Why is deactivating HPET... which is an important even timer that was actually originally developed by AMD in conjunction with Microsoft... so important for magical RyZen performance? If the HPET is so evil, why didn't AMD just tell the motherboard makers to make sure it's not even put on the board in the first place?
3. Did they turn HPET off on the Intel boards too?
Ryu Connor wrote:Is the HPET even doing anything on Ryzen?
I thought modern processors used an Invariant TSC instead?
srg86 wrote:It says to me that there must still be some bugs in the system, They could still just be because of immature BIOS, or things that could be fixed with a Microcode update, but you shouldn't have to do things like this to get best performance. Unless there are hardware bugs, but that could still be worked arond in Microcode.
Ryzen doens't suck for gaming (and never did), but still caviat, caviat, caviat.
ultima_trev wrote:People actually use Windows' Balanced profile?
just brew it! wrote:I use Linux as my primary OS, so I am effectively a beta tester for Linux desktop environments.
just brew it! wrote:I use Linux as my primary OS, so I am effectively a beta tester for Linux desktop environments. (At least I stick to Ubuntu LTS and Debian Stable now, so I'm not an alpha tester any more... )
ultima_trev wrote:People actually use Windows' Balanced profile?
Ryu Connor wrote:Lest I forget, the Ryzen sucks for gaming.
Ryu Connor wrote:Yes, the vast majority of people. Not only is it the default, it just works.
There are no objective tests that show the balanced profile as a problem.
Just mythical/subjective/anecdotal talk of stuttering and how "core parking" is breaking things.
caconym wrote:Running in balanced mode can definitely result in stuttering in music production applications. I have numerous synth-heavy tracks that are unplayable if I let Windows keep the minimum processor state at the default 5%. Nothing subtle or subjective about it.
derFunkenstein wrote:Up until last week, I never messed with Windows power profiles. I never needed to. I'm interested in the fix AMD mentioned coming later this spring.
I'm starting to feel like a beta tester.
Ryu Connor wrote:caconym wrote:Running in balanced mode can definitely result in stuttering in music production applications. I have numerous synth-heavy tracks that are unplayable if I let Windows keep the minimum processor state at the default 5%. Nothing subtle or subjective about it.
Thanks for the anecdote.
Ryu Connor wrote:Thanks for the anecdote.
Ryu Connor wrote:Thanks for the anecdote.
Ryu Connor wrote:caconym wrote:Running in balanced mode can definitely result in stuttering in music production applications. I have numerous synth-heavy tracks that are unplayable if I let Windows keep the minimum processor state at the default 5%. Nothing subtle or subjective about it.
Thanks for the anecdote.
derFunkenstein wrote:Way to be a jerk.
It's not just an anecdote. Avid (and Digidesign as its forebear) has long recommended this and lots of other tweaks to get the best and most performance out of Pro Tools. And lest ye think this is some AMD-specific crap, the system requirements are quite clear: go Intel or go home.
For the majority of people "it just works" (har) but those that need more know how to do it.
derFunkenstein wrote:
It's not just an anecdote. Avid (and Digidesign as its forebear) has long recommended this and lots of other tweaks
Just because you haven't experienced core parking performance degradation doesn't mean it doesn't exist.
Ryu Connor wrote:It doesn't exist and his anecdote wasn't even about parking(C6), but apparently his music app doesn't make Speedstep realize it needs to speed up. I thought those issues got sorted out during the Conroe days, personally. There's a lot of crap software out there though.
just brew it! wrote:The application code should not need to do anything special to let the system know it needs more CPU power. If the system's power management can't respond quickly enough due to either OS or hardware limitations, then disabling said power management is a reasonable workaround.
Thread affinity management — A multi-threaded application can enumerate processor topology and
assign processor affinity to application threads to prevent thread migration. This can work around the
issue of OS lacking multicore aware P-state coordination policy.
just brew it! wrote:It's not clear to me that the Pro Tools issue is even related to thread affinity. If the application has very "bursty" CPU demands this could be causing cores to jump between P-states even if the threads are staying put.
Interaction of OS scheduling and multicore unaware power management policy may create some situations
of performance anomaly for multi-threaded applications. The problem can arise for multithreading
application that allow threads to migrate freely.
13-11
POWER OPTIMIZATION FOR MOBILE USAGES
When one full-speed thread is migrated from one core to another core that has idled for a period of time,
an OS without a multicore-aware P-state coordination policy may mistakenly decide that each core
demands only 50% of processor resources (based on idle history). The processor frequency may be
reduced by such multicore unaware P-state coordination, resulting in a performance anomaly. See
Figure 13-5.
Bottom line is, Windows was not designed to be a "hard" real-time OS,
Ryu Connor wrote:Bottom line is, Windows was not designed to be a "hard" real-time OS,
Is there even a modern operating system that is designed to be that?
Ryu Connor wrote:FreeDOS?