18

Hardware- und Nachrichten-Links des 18. April 2019

Bei WCCF Tech hat man sich ebenfalls die RayTracing-Performance von GTX-Beschleunigern angesehen – in diesem Fall speziell die von den eher kleineren Karten GeForce GTX 1660 und 1080 sowie dies allein unter der FullHD-Auflösung. Jene gibt den Karten einige Performance-Reserven, welche man dann für RayTracing einsetzen kann – womit die Ergebnisse passabel ansprechend aussehen, hier und da sogar eine vernünftige Spielbarkeit erreicht wird. Allerdings passiert jene eben auch nur unter der FullHD-Auflösung, wofür speziell die GeForce GTX 1080 nominell eigentlich nicht wirklich gedacht ist – und natürlich zumeist unter niedrigen RayTracing-Qualitäten. Es reicht somit für ein Hereinschnuppern ins Kapitel "RayTracing", aber sicherlich kaum für zukünftige Spieletitel mit (vermutlich) verstärktem RayTracing-Einsatz. Wahrscheinlich war seitens nVidia hierbei auch nie etwas anderes gedacht: Dem GTX-Nutzer soll vorgeführt werden, wie schwach die GTX-Karten unter RayTracing doch sind – wenn beispielsweise unter RayTracing die GeForce RTX 2060 die (nominell schnellere) GeForce GTX 1080 durchgehend klar schlägt.

GeForce GTX 1660 GeForce GTX 1080
Battlefield V FullHD @ "High", DXR=low 40 fps 45 fps
Metro Exodus FullHD @ "High", DXR=high 33 fps 49 fps
Shadow of the Tomb Raider FullHD @ "High", DXR=medium 48 fps 59 fps
gemäß der Benchmarks von WCCF Tech

Derzeit gibt es einige Meldungen zu TSMCs 7FF+ Prozeß und den darauf basierenden Zen 3 bzw. Ryzen 4000 Prozessoren – in welchen betont wird, das über die Fortschritte dieses Fertigungsverfahren die entsprechenden AMD-Prozessoren mit einer um 20% höherer Transistorendichte samt einem um 10 Prozent reduzierten Strombedarf antreten können. Ausgangspunkt dieser Meldungen ist jedoch nicht irgendeine Wortmeldung von AMD oder mit AMD-Bezug – sondern liegt allein in den technischen Daten von TSMCs 7FF+ Fertigung, welche auch schon seit Monaten bekannt sind. Anders formuliert: Das TSMCs 7FF+ Prozeß diese technischen Vorteile bietet, bedeutet erst einmal gar nichts bezüglich AMDs Zen 3 bzw. Ryzen 4000. Die höhere Packdichte wird AMD sicherlich mitnehmen (was nicht zwingend bedeutet, das man dafür dann mehr Transistoren verbaut), beim Stromverbrauch kommt es hingegen entscheidend auf die mit den finalen Produkten letztlich gebotenen Taktraten an – die TSMC-Angabe gilt schließlich wie üblich nur bei gleicher Taktrate. Generell ist das ganze eigentlich eine "Nicht-Meldung", denn abgesehen von den (bekannten) Spezifikationen zu TSMCs 7FF+ Prozeß ergibt sich hieran keinerlei verwertbare Aussage zu Zen 3 bzw. Ryzen 4000. Eher interessant zu Zen 3 dürfte die hierfür angesetzten Architektur-Änderungen sein, beispielsweise dürften dann durchgängiges PCI Express 4.0 und womöglich der Wechsel auf DDR5-Speicher auf dem Plan stehen.

Ein interessanter Artikel bei Heise widmet sich den Schwierigkeiten einer Programmierung für Mehrkern-Prozessoren bzw. zur Ausnutzung von deren Rechenkraft. Die Seiten 2-4 des Artikels gehen dann eher auf Dinge ein, welche nur für Software-Programmierer selber interessant sein, die erste Artikelseite widmet sich hingegen den grundsätzlichen Schwierigkeiten – welche darin bestehen, das nicht jede Software eigentlich wirklich gut parellisierbar ist. Um richtig auf Performance zu kommen, reicht es eben nicht aus, das man die gesamte Arbeit in (weitgehend) unabhängige Teile auftrennen kann – man muß sie auch noch möglichst gleichmäßig aufteilen können, ansonsten bleibt der Performance-Effekt von Mehrkern-Prozessoren begrenzt bzw. wird in jedem Fall deren maximale Performance niemals erreicht. Genau diese Problematik liegt derzeit im PC-Bereich insbesondere bei PC-Spielen vor: Man kann die CPU-Aufgaben eines Spiels durchaus auftrennen – Spielverwaltung, Rasterizer, KI, Sound, usw. – aber dies bedeutet noch überhaupt nicht, das alle diese Rechenaufgaben dann gleich viel Prozessorenzeit benötigen.

Insbesondere wenn man Rechenaufgaben nur nach ihrer Klasse bzw. Herkunft auftrennen kann, wird sich immer die Problematik ergeben, das einzelne Aufgaben besonders wenig bzw. besonders viel Rechenleistung verschlingen. Die kleineren Aufgaben sind dann teilweise so klein, das jene keinen eigenen CPU-Kern benötigen – was auch bedeutet, das hierbei Parallelisierung (oberhalb von Zweikern-Modellen) keinen Performance-Fortschritt ergibt. Und die großen Aufgaben sind teilweise derart dominierend, das alle anderen Aufgaben auf jene warten müssen, die Grenze der Parallelisierung hier also recht schnell erreicht ist. Nachstehendes Beispiel aus dem Heise-Artikel stammt zwar eher aus der Betriebswirtschaft, zeigt das ganze aber trotzdem ganz gut auf: Trotz vier parallel ausführbarer Aufgaben dominiert letztlich die Aufgabe #3 die Schnelligkeit der insgesamten Ausführung. Auf CPU-Verhältnisse übertragen würde hierbei also ein Dreikern-Prozessor den bestmöglichen Performancezuwachs ergeben, ein Vierkern-Prozessor wäre demgegenüber nicht schneller. Wäre die Aufgabe #3 noch etwas dominanter, würde umgehend auch nur ein Zweikern-Prozessor ausreichend (bzw. gleich schnell) sein.

An dieser Stelle liegt ein erhebliche Unterschied von Spiele-Software gegenüber Anwendungs-Software verborgen: Die meiste Anwendungs-Software enthält massig an Rechenaufgaben, welche gleichförming und trotzdem in sich selber parallelisierbar sind. Bestes Beispiel sind Packprogramme, wo die Aufgabe immer wieder dieselbe ist, diese Hauptaufgabe selber aber schon parallelisierbar ist – es wird dann einfach an unterschiedlichen Datenteilen gearbeitet. Damit sind dort auch erhebliche Performancegewinne durch MultiCore- und ManyCore-Prozessoren zu erreichen. Bei PC-Spielen werden dagegen zumeist nur die einzelnen CPU-Aufgaben aufgeteilt, damit jene unabhängig voneinander ausführbar sind. Damit lebt man dann allerdings auch mit dem jeweils unterschiedlichen Rechenzeitbedarf dieser Aufgaben sowie der dabei herauskommenden nur durchschnittlichen Rechenkern-Skalierung. Zudem stößt dieses System irgendwann an seine Grenzen, speziell ManyCore-Prozessoren sind darüber kaum noch auszunutzen. Irgendwann muß es auch auch bei PC-Spielen dann zu einer Parallelisierung einzelner CPU-Aufgaben kommen, wenn man die vielen CPU-Kerne aktueller und kommender PC-Prozessoren (unter Spielen) noch ausnutzen will. Die gleichen hohen Rechenkern-Skalierungen wie bei Anwendungs-Software zu sehen sind von Spiele-Software aber kaum jemals zu erwarten.