15

Hardware- und Nachrichten-Links des 14./15. September 2019

Semiconductor Engineering haben mit Bill Dally und Jonah Alben von nVidia über zukünftige Chipentwicklungen gesprochen. Interessant sind hierbei insbesondere die Aussagen zu Chiplet-Verfahren im Grafikchip-Bereich, an welchen nVidia Grundlagen-Arbeit betreibt und sich bezüglich der Möglichkeiten dieses Ansatzes auch recht optimistisch gibt. Bezüglich des praktischen Einsatzes dieser Möglichkeiten zeigt man sich dagegen noch arg zugeknöpft: Einen Einsatz in absehbarer Zukunft (innerhalb der Nodes 7nm & 5nm) wollte man nicht bestätigen – hierbei sieht man den Punkt, wo Chiplets mehr Nutzen als Aufwand bringen, als noch nicht erreicht. Die Grundlagen-Arbeit daran diente wohl bislang nur dazu, jene Möglichkeit zukünftig im Portfolio zu haben – griffbereit für den Zeitpunkt, wo man jene wirklich braucht. Dies ist dann sicherlich auch keine Aussage dazu, ob es überhaupt jemals zu einem Chiplet-Einsatz im Grafikchip-Bereich kommen wird. Dies erfordert neben der technischen Realisierung von Chiplets eben dann doch noch erhebliche Anstregungen, um das Vorhandenensein mehrere Grafikchips treiberseitig so zu kaschieren, das die damit betriebene Software letztlich nur "einen" Grafikchip sieht – und somit keine eigenen Anstregungen unternehmen muß, mehrere Grafikchips vernünftig auszulasten. Die bisherigen Ansätze hierzu wie SLI & CrossFire haben diese Aufgabe der jeweilige Software aufgebührdet, konnten sich aber wie bekannt letztlich nicht halten – und dürften, da nun einmal in der Nische verschwunden, auch nicht wiederkommen. Die nächste MultiChip-Grafiklösung wird diese Problematik also in Hardware bzw. im Treiber angehen müssen – hier liegt die eigentlichen Schwierigkeit des Chiplet-Ansatzes im Grafikchip-Bereich.

Weitere Tests zur neuen AGESA-Version 1.0.0.3abba kommen von der8auer @ YouTube, Hardware Unboxed @ YouTube sowie (Freitag schon verlinkt) Legit Reviews. In allen Fällen konnte dabei das vom initialen Test seitens TechPowerUp bekannte Bild nachgestellt werden: Die maximale Boost-Frequenz geht leicht nach oben, genauso gibt es auch allgemeine Performance-Verbesserungen (meistens nur knapp oberhalb der 1-Prozent-Marke, manchmal auch etwas mehr) zu allerdings einer leicht höheren Leistungsaufnahme. Insbesondere bei Hardware Unboxed gab es teilweise auch mal größere Performancesprünge von 5-6% unter einzelnen Anwendungen – wobei hier ein Performance-Schnitt unter einer größeren Anzahl an Tests fehlt, um wirklich sagen zu können, ob dies allgemeingültige Ergebnisse oder eher nur Ausreißer sind. Bislang hat keiner der Hardwaretester eine CPU gefunden, wo der maximale Boost-Takt mit der neuen AGESA-Version wirklich unterhalb von AMDs Spezifikation lag (abseits minimaler Differenzen, welche über "Spread Spectrum" erklärbar sind). Allerdings konnte insbesonder der8auer herausarbeiten, das dieser maximale Boost-Takt auch wirklich nur "maximal" ist – sprich unter Last keineswegs dauerhaft, sondern allerhöchstens sporadisch anliegt. Oftmals ist der maximale Boost-Takt sogar nur bei geringfügigen Lasten zu sehen – dies reicht dann durchaus aus, um die Spezifikations-Vorgabe zu erfüllen, könnte aber weiterhin für Diskussionen sorgen, denn dies ist bei Intel dann teilweise anders bzw. besser gelöst.

Allerdings haben beide Boost-Verfahren auch einen grundverschiedenen Ansatz: Bei Intel wird jederzeit versucht, den maximalen Boost-Takt für die benutzte Anzahl an CPU-Kernen zu erreichen. Der Boost-Takt wird zudem vorab von Intel definiert und kann auch niemals überschritten werden, auch nicht für eine Millisekunde. AMDs Ryzen-Prozessoren takten sich (insbesondere bei Ryzen 2000 & 3000) dagegen eigentlich immer so hoch, wie es die intern definierten Grenzwerte zulassen – wobei die spezifizierte Taktraten überhaupt nicht zu diesen Grenzwerten zählen (bis auf den Base-Takt natürlich). Die von AMD genannten Taktraten stellen also viel weniger eine "Spezifikation" wie bei Intel dar, sondern sind eher eine nominelle Angaben gemäß Erfahrungswerten – die CPU wird aber nirgendwo (mit Ausnahme des Base-Takts) auf diese Taktraten gezwungen. Kurz formuliert: Intel legt zuerst die Boost-Taktraten fest und die CPU richtet sich dann danach, während bei AMD die CPU sich selbsttätig hochtaktet und die Boost-Taktraten dann einfach nur anhand der erreichten Praxis in die Spezifikations-Liste geschrieben werden. Gemäß dieser Ausgangslage dürfte klar sein, das es bei Intels Boost-Verfahren kein Problem mit dem Erreichen der maximalen Boost-Taktraten (bei ausreichenden äußeren Bedingungen) geben kann, während es bei AMD aufgrund des automatischen Boost-Verfahrens immer wesentlich mehr Spielraum in der Praxis geben wird, genauso wie AMD immer latent im Risiko lebt, das einzelne Prozessoren (wegen der Unterschiede im Silizium) ihre nominellen Boost-Taktraten dann doch nicht erreichen.

Im gewissen Sinne ist Intels Boost-Verfahren somit solider, da es weniger auf die Klasse des Siliziums angewiesen ist, sondern gewöhnlich schon unter einer äquadaten Kühlung spezfikationsgemäß funktioniert. Das verschiedene Prozessoren der gleichen Baureihe sich unterschiedlich gut takten lassen, gleicht Intel dann über seine Modell-Vielfalt mit vielen Taktraten-Abstufungen auf – etwas, was bei AMD wie bekannt speziell unter Ryzen 3000 nicht mehr gut funktioniert. AMDs Boost-Verfahren ist faktisch nur besser geeignet, um die Prozessoren schon im default-Zustand an ihr Performance-Maximum zu bringen – unter dem weitgehenden Verlust von Taktraten-Abstufungen sowie der Übertaktungseignung. Ironischerweise könnte Intel sich allerdings kurz- und mittelfristig dazu gezwungen sehen, mangels dem Vorhandensein eines echten Ryzen-3000-Gegners dem AMD-Weg des automatischen Boosts zu folgen – vielleicht mit anderem Namen und anderen Vorgehensweisen, aber letztlich doch mit der Zielsetzung, mehr default-Performance über eine bessere Boost-Automatik zu erzielen. Schließlich hat Intel derzeit für das Jahr 2020 nur "Comet Lake" in seiner Roadmap stehen, dessen maximal 10 CPU-Kerne unter weiterhin der Skylake-Architektur kaum dazu geeignet erscheinen, um sich mit Ryzen 3000 (und im Jahr 2020 dann Ryzen 4000 auf Zen-3-Basis) anzulegen. Das Ausnutzen der Reserven, welche ein automatischer Boost noch bietet, erscheint da durchaus als Möglichkeit, in dieser für Intel schwierigen Situation vor dem Umschwung auf neue CPU-Architekturen (mittels Ice Lake & Tiger Lake) noch einmal Mehrperformance zu generieren.

Bezüglich des vorläufigen Endes des bundesdeutschen Presse-Leistungsschutzrechts wäre zu diesem natürlich weitergehenden Zweikampf der großen Presseverleger gegenüber primär Google auch noch der Gedanke anzubringen, das Google hier zum Teil durchaus eigenverschuldet in der Schußlinie steht. Und dies nicht aus Gründen der unrechtmäßigen Bereicherung anhand der Erzeugnisse der Presseverleger, denn jene profitieren von Google mehr als es umgedreht der Fall ist (gut daran zu sehen, wenn Google mal die Drohung ausspricht, die Presseverleger komplett aus dem Google-Index herauszunehmen). Aber Google hat den taktischen Fehler begangenen, Lobby-technisch speziell in Europa bei weitem nicht so gut vernetzt zu sein wie die Presseverleger. Und ein anderer Fehler ist sicherlich, das Googles Steuer-"Optimierung" so gut gelungen ist, daß jener weltweit führende Großkonzern aus Sicht der Bundesfinanzen vollkommene Belanglosigkeit erreicht. Damit hat Google gegenüber der bundesdeutschen Politik einfach nicht denselben Einfluß, wie ihn die Presseverleger haben – trotz das Google wahrscheinlich in der Lage wäre, jene vollständig aus der Portokasse aufzukaufen. Gerade wenn Google eine solide Steuerposition in Deutschland innehätte, wäre dies ein gewichtiges Gegenargument für die Politik, Google mit dem Presse-Leistungsschutzrecht vors Schienbein zu treten. Die Steuervermeidungs-Strategie von Google weist in diesem Punkt ergo substantielle Nachteile auf: Wer keine Steuern zahlt, findet halt auch kein Gehör.

Semiconductor Engineering haben mit Bill Dally und Jonah Alben von nVidia über zukünftige Chipentwicklungen gesprochen. Interessant sind hierbei insbesondere die Aussagen zu Chiplet-Verfahren im Grafikchip-Bereich, an welchen nVidia Grundlagen-Arbeit betreibt und sich bezüglich der Möglichkeiten dieses Ansatzes auch recht optimistisch gibt. Bezüglich des praktischen Einsatzes dieser Möglichkeiten zeigt man sich dagegen noch arg zugeknöpft: Einen Einsatz in absehbarer Zukunft (innerhalb der Nodes 7nm & 5nm) wollte man nicht bestätigen - hierbei sieht man den Punkt, wo Chiplets mehr Nutzen als Aufwand bringen, als noch nicht erreicht. Die Grundlagen-Arbeit daran diente wohl bislang nur dazu, jene Möglichkeit zukünftig im Portfolio zu haben - griffbereit für den Zeitpunkt, wo man jene wirklich braucht. Dies ist dann sicherlich auch keine Aussage dazu, ob es überhaupt jemals zu einem Chiplet-Einsatz im Grafikchip-Bereich kommen wird. Dies erfordert neben der technischen Realisierung von Chiplets eben dann doch noch erhebliche Anstregungen, um das Vorhandenensein mehrere Grafikchips treiberseitig so zu kaschieren, das die damit betriebene Software letztlich nur "einen" Grafikchip sieht - und somit keine eigenen Anstregungen unternehmen muß, mehrere Grafikchips vernünftig auszulasten. Die bisherigen Ansätze hierzu wie SLI & CrossFire haben diese Aufgabe der jeweilige Software aufgebührdet, konnten sich aber wie bekannt letztlich nicht halten - und dürften, da nun einmal in der Nische verschwunden, auch nicht wiederkommen. Die nächste MultiChip-Grafiklösung wird diese Problematik also in Hardware bzw. im Treiber angehen müssen - hier liegt die eigentlichen Schwierigkeit des Chiplet-Ansatzes im Grafikchip-Bereich.