Test AMD Ryzen 7 1800X, 1700X, 1700 im Test: König in Anwendungen, Prinz in Spielen

Es verschwendet keine Resourcen, es weist sie zu und da kann man regulierend eingreifen via Priorisierung. Nichts anderes macht der Gamemode.
 
ZeroZerp schrieb:
Die Tools (Virenscanner, Windows Update etc.) sind heutzutage so intelligent, den Computer nur zu belasten, wenn er gerade im Idle- Modus ist oder sonst nur unter schwacher Last steht.
Nein, wenn Virenscanner den Arbeitsspeicher überwachen, entsteht gerade Aktivität bei speicherintensiven Anwendungen mit vielen Dateien. Etwa beim Übersetzen von Quellcode (super skalierbar auf viele Threads) schluckt ein Virenscanner gern mal 20% Leistung im Schnitt (da sind also Spitzen von 80/90% drin).
 
Richtig- Deshalb gibts ja bei den meisten Scannern inzwischen auch eine Art "Gaming- Mode" und eine intelligente Pattern- basierte Suche, so dass nicht jedes Stück Code untersucht werden muss...

Die Zeiten, in denen die Virenscanner auf Binärebene per Bruteforce alles überwacht haben, sind schon länger vorbei (außer man setzt entsprechende Optionen). Damit könnte man dann den Prozessor und das restliche I/O System in der Tat ärgern.

Grüße
Zero
 
Zuletzt bearbeitet:
Das erklärt so einiges. Auch die "Gaming-Schwäche" und warum dieser nur in DX12 titeln und auch da nur in manchen auftritt:
https://www.youtube.com/watch?v=nIoZB-cnjc0
Hab das Video aus einem anderen CB-Topic...der Link ist genial um das mindeste zu sagen.

Das erklärt auch warum der RAM so einen Impact hat, vor allem aber die RAM-Latenz.

Ich frage mich echt warum MS so lange mit DX12 gewartet wenn es so offensichtlich war dass man den Draw-Call Thread nicht umgehen kann und man mehr und mehr ins limit lief...

Vor allem, aber in Kombination mit den alten Boebachtungen ext3h (Oktober 2015): http://ext3h.makegames.de/DX12_Compute.html
Ergibt das nun alles ziemlich Sinn. Ich hatte mich eben schon lange gewundert wie so plötzlich nVidia den DX11 Treiber beschleunigen konnte.
Geniale Idee den Command-List Server im Treiber einzubauen um die "Krücke" DX11 zu umgehen !

The differences between GCN and Maxwell/Kepler are quite significant, and so is the effect of using the compute engines, respectively multiple queues in general. I will address possible approaches to utilize the platform to full extent or to avoid common misconceptions.
AMD

Compute engines can be used for multiple different purposes on GCN hardware:

Long running compute jobs can be offloaded to a compute queue.
If a job is known to be possibly wasting a lot of time in stalls, it can be outsourced from busy queues. This comes at the benefit of achieving better shader utilization as 3D and compute workload can be interleaved on every level in hardware, from the scheduler down to actual execution on the compute units.
High priority jobs can be scheduled to a dedicated compute queue.
They will go into the next free execution slot on the corresponding ACE. They can not preempt running shaders, but they will skip any queued ones. Make proper use of the priority setting on the compute queue to achieve this behaviour.
Create more back pressure.
By providing additional jobs on a compute engine, the impact of blocking barriers in other queues can be avoided. Barriers or fences placed on other queues are not causing any interference.

Due to the possible performance penalties from using compute commands concurrently with draw calls, compute queues should mostly be used to offload and execute compute commands in batch.

There are multiple points to consider when doing this:

The workload on a single queue should always be sufficient to fully utilize the GPU.
There is no parallelism between the 3D and the compute engine so you should not try to split workload between regular compute and 3D queues arbitrarily.
Pay close attention not to stall the GPU with solitary compute jobs limited by texture sample rate, memory latency or anything alike. Other queues can't become active as long as such a command is running.
Compute commands should not be scheduled together with draw calls in a single batch.
Doing so will hurt the performance measurably. The reconfiguration of the SMM units will impair performance significantly.
In the worst case, the GPU will even be partitioned inefficiently. This can result e.g. in the SMM units dedicated to graphics to run idle, while the compute shader running in parallel starves due to a lower number of SMM units available.
Make sure to always properly batch both draw calls and compute commands. Avoiding a mixture ensures that all resources are allocated to either type.
Consider the use of a draw call with a proxy geometry instead when batching and offloading is not an option for you. This will still save you a few microseconds as opposed to interleaving a compute command.
Make 3D and compute sections long enough.
Switching SMM units between compute and 3D mode results in a full flush of all pipelines. The GPU should have spent enough time in one mode to justify the penalty for switching.
Beware that there is no active preemption, a long running shader in either engine will stall the transition.

Ryzen nun ZEIGT diese Treiberproblematik eben deutlich auf...wegen der InfinityFabric läuft das nVidia-Konstrukt die DX11-Schwäche mit eine Cmd-List zu umgehen in DX12 bei ungünstiger Konstellation der Game Engine ins leere....die Cmd-List muss dann ständig im Cache geflushed werden was auf Ryzen zu einem massiven Latenzproblem führt.

Ryzen zeigt auch wie schlecht eben die games auch oftmals programmiert sind...

Es zeigt sich aber dass es mittel-, langfristig allerdings massiv aufwärts gehen wird mit Ryzen. Das wird eine richtig langlebige Architektur...
Damit ist meine Entscheidung gefallen...das CPU-Upgrade wird auf Sommer vorgezogen ! Auch wenn mein alter FX-6300 für meine R9 380 immer noch grade so reicht...es muss eh eine neue Zukunftsfähige Plattform her. Da scheint mir nun AM4 die richtige Wahl und P/L sowieso.
 
Andregee schrieb:
Ach Gott, Bei mir sind auf dem Desktop bereits 6GB Ram belegt, ich habe noch weitaus mehr Hintergrundprozesse als das bischen von dir genannte aktiv und dennoch belastet das die CPU nicht nennenswert. Pentium 1 Zeiten sind längst Geschichte in denen ein Browser das System nennenswert belastet hat.

Mit genügend freien kernen ist das kein Problem aber der Browser an sich ist auch nicht das Problem sondern die ganzen "tollen" Werbeeinblendungen und diverse Seiten mit aktiven Inhalten. Mit genug offenen Seiten können die dir schnell mal 1-2 Kerne dicht machen.
Zu Pentium 1 Zeiten hätten sie sich die Seitenbetreiber eine solche Ressourcenverschwendung noch nicht einmal erlauben können und da wurden zum Spielen regelmäßig alle anderen Programme beendet um möglichst viel Rechenleistung frei zu haben, Singlecore eben.
 
Wadenbeisser schrieb:
Mit genügend freien kernen ist das kein Problem aber der Browser an sich ist auch nicht das Problem sondern die ganzen "tollen" Werbeeinblendungen und diverse Seiten mit aktiven Inhalten. Mit genug offenen Seiten können die dir schnell mal 1-2 Kerne dicht machen.
Zu Pentium 1 Zeiten hätten sie sich die Seitenbetreiber eine solche Ressourcenverschwendung noch nicht einmal erlauben können und da wurden zum Spielen regelmäßig alle anderen Programme beendet um möglichst viel Rechenleistung frei zu haben, Singlecore eben.


Jo. Ich kann mich noch erinnern an früher als man noch im DOS rumfimmeln musste dass man ja >600kB RAM frei hat damit das Game startet...
Und vor 10 Jahren rum war "browsen" während dem Gamen ein totales no-Go...überhaupt so etwas wie "raus-Tabben" während dem Game...gabs vor 15 Jahren noch 0 und vor 10 Jahren fing das erst so langsam an mit der breiteren Verbreitung von mind. 2-Kernern....
Mittlerweile hat man ja oft ein Casual Game und ein hardcore game parallel offen, nebst Browsergame etc :)
(leicht übertrieben)
 
@Iscaran
Danke für das Video, letztendlich sagt es genau das was ich auch beobachten konnte. Die Geforce Modelle profitieren in DX11 von einer besseren Lastverteilung, ein Vorteil der unter DX12/Vulkan/Mantle entfällt. Nix mit besserer Treiber Overhead, eher das Gegenteil ist der Fall aber es fällt nicht auf weil idR. genug freie CPU Laufzeit rumgammelt.
Das mit der deutlich anderen Thread Sheduling war mir allerdings neu.
 
Dann soll man dem i7 7700k auch 3600Mhz Ram geben und nicht "nur" 3200Mhz,genauso wie bei Ryzen. Dann sehen die Ergebnisse wieder leicht anders aus.
 
@Dreamliner:

Na, nicht so sehr. Der 7700k skaliert bei diesem hohen Ram kaum noch. Ryzen hingegen schon, da der IF daran gekoppelt ist.
 
@Dreamliner

Das macht bei Intel nichts aus, hat der Typ im Video doch gesagt. Die Mehrleistung liegt im Bereich der Messtoleranz.
 
Das behauptet er. ^^ Gibt genügend Benchmarks, dass Intel auch mit schnellerem RAM noch zulegt. Dachte das sei bekannt.

Man muss ja auch immer mal kritisch sein bei solchen Videos. Wenn er behauptet das mache bei Intel nichts aus, kann er es ja testen.

http://www.techspot.com/article/1171-ddr4-4000-mhz-performance/page3.html

Das zeigt doch, dass es mitnichten so ist. Manches erscheint einem schon sehr pro Ryzen. YT Leute verkünden nicht immer die pure Weisheit.
 
Zuletzt bearbeitet:
Ja aber würde ich dennoch mal gerne sehen das Beide den gleichen Ram nutzen,damit die Grundbedingungen gleich sind.
 
Das ändert am Ergebnis ja auch nicht viel, da Ryzen bereits mit 3200 gegen den 7700K mit 3200 sehr gut aussieht
 
Klar aber auf der anderen Seite warum mehrere Stunden rein stecken für effektiv nichts? Ich kann das schon nachvollziehen und es gibt auch genug Videos wo man sehen kann, dass schnellerer RAM bei Intel eben nichts bringt.
 
Der Ramtakt wurde über den Referenztakt angehoben. Werden 3600 Mhz über den Ram-Teiler möglich (soll ab Mai per Update freigegeben werden), sollte die Performance nochmal ein Stück mehr zulegen.
 
@imaginez: Übrigens liegen die Unterschiede in deinem Link auch bei fast allen Spielen im Bereich von 2-3fps, in den Bereichen vom 150-180fps auch mal 5-6fps und damit irgendwo bei 2-3%. Fallout 4 wie bekannt als einziger großer Ausreißer.

Und hier wurde 3000 gegen 3600 getestet. Würde man 3200 gegen 3600 testen, kämen wir nur noch auf 1% Unterschiede, die es mindestens auch bei Ryzen geben wird, eher mehr.
 
Zuletzt bearbeitet:
Jo, und was sehen wir im Video? Das sind auch nur 2% bei Battlefield bei Ryzen von 3200 auf 3600. So what? Der Intel läge dann auch wieder 2% weiter vorne.
 
Und muss trotzdem die Drops in den Multiplayer-Gefechten von 170 auf 100 ertragen :/
 
Zurück
Oben