[Work-Log] Aufrüsten auf einen 5800X3D! Was ist an Leistung möglich!

[sp00n.82]

Mysticial, der Author von y-Cruncher, hatte das hier auf overlock.net gepostet bzgl. der neuen Versionen:

y-cruncher went through a major rewrite starting from v0.8.1 to v0.8.5. Basically that massive collection of old algorithms which had been accumulating for 15 years finally got cleaned out and replaced with a smaller number of modernized ones which run better (faster) on modern hardware. (and also modernized from a coding perspective)

So all those algorithms are gone. Completely removed from the codebase as they've become a developer maintenance burden.

Already Removed: HNT, N32, N64, VST, C17
To be Removed: SFT, FFT (will be removed in v0.8.6)

New Algorithms: N63 (rewrite of N64), VT3 (rewrite of VST and C17)
To be Added: SFTv4, FFTv4 (rewrites of SFT and FFT) (will be added in v0.8.5)

Since VST, N64, SFT, and FFT have been (or will be) directly replaced, the command line options for them will alias to their replacements. (VST -> VT3, N64 -> N63, etc...)

HNT and N32 have no replacements. They are mathematically obsolete and thus there is no reason to rewrite them.

VT3 is a weird one actually since it's the rewrite of either VST or C17 depending on the binary. VST and C17 are mathematically identical, but differ in how they are implemented. (one uses pure floating-point while the other uses either pure integer or a mix of int/FP)

When I rewrote the algorithm (eventually named VT3), I decided to combine them with the choice of implementation (VST or C17) being a compile-time flag based on the binary.

• VT3 behaves like C17 on 18-CNL and 22-ZN4.
• Otherwise, it behaves like VST on all other binaries.
• VT3 on the upcoming Zen5 binary (24-ZN5) will also use the C17 implementation.

As much as I wanted to keep both simultaneously for the purpose of stress-testing, the new design didn't allow for it. And I wasn't doing to duplicate 50k lines of code just for stress testing.

 

[Creekground]

Weder weicher noch härter. Nur anders. Somit stelle ich mit VT3 und N63 jetzt mal meine Cores ein. Schau mer a mal was raus kommt.

@sp00n.82


running N63 -> 0bits/sec ???

 

[sp00n.82]

Ja, hab ich auch schon gesehen beim Testen. Vielleicht ein Anzeigebug, bei einem anderen Test liefs dann wieder normal. Solange der Kern ausgelastet wird, müsste es eigentlich korrekt laufen.

 

[BreadPit]

Aber mir sind die "neuen" Versionen zu lasch/schwach
....
Es gibt kein zu hart! Es kann nie hart genug sein!

Bin ganz Deiner Meinung. Die Idee muss ja sein, den härtesten Test zu nehmen den es gibt, damit es dann eben keine Workload geben kann, die den Rechner instabil machen kann.

Weder weicher noch härter. Nur anders.

In der Theorie ja, in der Praxis klar nein = weicher. Wenn die deutlich weniger Spannung erlauben sind die einfach softer. Ich empfehle daher auch die alten ycruncher Algos für Stresstesting, aber eingebettet in CoreCycler 0.9.5.2 mit der YCRUNCHER_OLD Config, hab ich euch eh angehängt.

running N63 -> 0bits/sec ???

Ist bei mir genauso?

 

[sp00n.82]

running N63 -> 0bits/sec ???

Ich hab das jetzt nochmal gecheckt, kurz nachdem ich CoreCycler 0.9.5.2 released hatte, gab es auch eine neuere Version von y-Cruncher (v0.8.5.9539, seit gestern noch ein Bugfixrelease), in der ist der Anzeigefehler dann behoben.

Allerdings gibt es dort dann wieder ein paar neue Tests, deswegen wollte ich eigentlich warten, bis die Version mit Zen5-Unterstützung rauskommt, was ja eigentlich noch diesen Monat der Fall sein sollte.

 

[BreadPit]

Insbesondere für alle geschätzten Ryzen & RDNA Besitzer hier, vielleicht interessiert euch mein RTSS Overlay. Ich hab mich ne Weile umgesehen und kein OVL gefunden, das auf einen Blick alle wesentlichen Metriken kompakt & dynamisch farblich visualisiert, und mich auch optisch anspricht.

Also hab ich ein Overlay gebaut, in 10 Varianten. Font size 100% & 80%, Ryzen & RDNA full sensor support mit HWiNFO, alternativ basic sensor support via RTSS HAL für alle CPUs & GPUs, und das Ganze in vertical or horizontal layout:

https://github.com/BreadPitch/THE-RTSS-Overlay

Vielleicht gefällts euch ja auch, finde es ganz praktisch quasi alles live auslesen zu können. RAM Temp Sensoren wären vielleicht noch gut, aber die hab ich halt nicht

 

[Creekground]

@BreadPit dafür hätte ich keine Muse. Aber cool das es Leute gibt die sich das basteln. Super. Wenn ich morgen mal Zeit habe werde ich es mal testen.

 

[Fas7play]

Tolle Arbeit!
Sagt mal, kann man "sowas" auch am passiven (Youtube/Discord/..) Monitor betreiben?
Am aktiven (Game) möchte ich keine Infos über mein System haben, nimmt/raubt mir das immersive Erlebnis.

 

[BreadPit]

@fas7play Gute Frage... Gibt Lösungen, aber ob das mit RTSS Overlay auch geht weiss ich ned. Die werden glaub ich in jedem Fenster angezeigt, das eine 3D Schnittstelle nutzt. Muss mal recherchieren.

@Creekground die Muße neben Job, Family und Hausbau ist eh ein Thema. Geht bei mir einfach auf Kosten der Zock-Zeit, die für Freude an Technik als Selbstzweck geopfert wird 😉 Kippe dann rein, wenn ich das Gefühl hab dass das richtig gut werden kann und imho eine Lücke füllt / auch für andere interessant sein kann. War auch gleich mein erstes kleines GitHub Projekterl, wollte da schon länger mal was machen.

 

[BreadPit]

@fas7play ja RTSS Overlay auf 2nd screen geht, einfach den DesktopOverlayHost anwerfen, wie unten gezeigt ein Applikationsprofil dafür erstellen, mit der Fensterposition oben links konfigurieren und das Fenster an die Overlaygröße anpasssen.

Dann entweder im "Global" Profil "On Screen Display support" = OFF, oder für die einzelnen Spiele über Applikationsprofile in den RTSS Settings das In-Game Overlay deaktivieren.

C:\Program Files (x86)\RivaTuner Statistics Server\DesktopOverlayHost.exe

Ergänzung (19. Juli 2024)

PS: danke für die Frage @fas7play , jetzt hab ich das auch noch entdeckt - ev check ich mir auch nen second screen dafür, ist ja großartig Hab das auch schon in der Readme auf GitHub hinzugefügt.

 

[Fas7play]

passt, wackelt und hat luft! (funktioniert!)
danke dir!

 

[Creekground]

@BreadPit das haut bei mir nicht so richtig hin:

 

[BreadPit]

Hast ja auch offensichtlich die Schriftart Lato nicht installiert und eingestellt

Und auch HWiNFO läuft nicht mit Shared Memory enabled. Steht alles genau in der Anleitung auf GitHub.

 

[BreadPit]

PS: wenn Du nicht so viele Metriken sehen willst, kannst Du alternativ zu HWiNFO auch das "Compact4all" Overlay nutzen, das hptsl. RTSS HAL Datenquellen nutzt. Aber so wie ich Dich kenne, hoffe ich doch sehr, dass Du auch vSOC, MCLK etc sehen willst

Für PCH, MOS, Systemtemps und Lüftersensoren musst Du in den Data Sources halt ggf die Sensoren Deines Mainboards hinzufügen, und in der Tabelle damit die von meinem MSI MoBo ersetzen.

 

[Creekground]

Ehrlich gesagt gefällt mir das alte Overlay besser. Das ist übersichtlicher (deutlicher).
Ich habe auch nur einen Monitor. Vergleich:

 

[BreadPit]

Mir eben gar nicht von Übersicht, Detailgrad, Farbgebung generell und intuitiver "Heatmap" durch lastbasierte Farben - deshalb hab ich meins gebaut Ist klar, dass das Geschmackssache ist, und bin Dir nicht böse dass du einen anderen hast.

Im Gegenteil, Du hast mich dazu gebracht v1.3 zu releasen, mit deutlich einfacherer Installation

Da Du HWiNFO offenbar nicht im Hintergrund laufen lässt, wäre bei Dir das "Compact4all" besser btw.
Wo nimmst du "Stuttering" her btw?

 

[Creekground]

Das Overlay ist von CapframeX. Das habe ich nicht selbst erstellt. ,😉

 

[BreadPit]

oh...

 

[Creekground]

@BreadPit seit ich deine Dateien ins Plugin Verzeichnis kopiert habe funktioniert der Framelimiter von RTSS nix mehr. Hab schon gelöscht. geht trotzdem nicht.

 

[BreadPit]

Oha? Verwende den nicht, InGame besser als RTSS besser als Treiber. Ev liegts an der Nutzung der Microsoft Detours API?

Oder hast Du wirklich nur nur die .ovl reinkopiert, oder auch die Settings?

Ergänzung (22. Juli 2024)

Grad bei mir versucht, da geht der Frame Limiter ganz normal sobald ich ihn einschalte?