8

Hardware- und Nachrichten-Links des 8. Juni 2020

Heise berichten über das Fortschreiten der Arbeiten an PCI Express 5.0 & 6.0: So soll PCI Express 5.0 demnächst sein Regelwerk zum Erstellen von Zertifizierungs-Tests bekommen. Damit können Gerätschaften nach PCI Express 5.0 dann auch darauf geprüft werden, womit man nachfolgend auch offiziell damit werben darf. PCI Express 6.0 ist derzeit in einer augenscheinlich mittleren Entwicklungsphase, mit einer finalen Spezifikation darf im Laufe des Jahres 2021 gerechnet werden. Die dazu ausgebreitete aktuelle PCI-Express-Roadmap des Standardisierungsgremiums PCI-SIG bezieht sich bei den genannten Jahrenzahlen auch nur auf diese Spezifikations-Termine – sprich, PCI Express 4.0 ist hierbei schon im Jahr 2017 eingezeichnet, obwohl es erste sprechende Gerätschaften im PC-Bereich erst spät im Jahr 2018 gab. Mit einer gewissen Verzögerung bis zur Markteinführung ist also zu rechnen – gerade da im PC-Bereich aufgrund des (durch PCI Express) nach oben gehenden Stromverbrauchs inzwischen überlegt werden muß, wo die neueren PCI-Express-Normen noch jeweils Sinn machen.

Eben aus diesem Grund hatte AMD bei der Zen-2-basierten "Renoir"-APU auch nur PCI Express 3.0 (auf nur 8 Lanes) angesetzt, weil dies im Mobile-Bereich durchaus einen gewissen Stromspar-Effekt hat – welchen man dann bei einer festgesetzten TDP den Rechenwerken der CPU zukommen lassen kann. Bei allen weniger an der TDP hängenden Gerätschaften dürften man eher an den neuen PCI-Express-Normen interessiert sein, gerade aus dem Server-Bereich kommen derzeit klare Anforderungen hinsichtlich mehr I/O-Bandbreite. Denkbar ist allerdings, das im PC-Bereich dennoch irgendwann das Interesse nachläßt: Angesichts der jeweils nominellen Bandbreiten-Verdopplung ist der im PC-Bereich herauskommende Performance-Effekt doch eher marginal – gerade wenn man jetzt nach PCI Express 4.0 noch an 5.0 sowie 6.0 denkt. Gut möglich, das auch im PC-Bereich die neuen PCI-Express-Normen eines Tages eher dazu benutzt werden, die jeweiligen Interfaces zu verkleinern (PCI-E 6.0 x8 anstatt PCI-E 5.0 x16), da man die Mehr-Bandbreite nicht benötigt, eine einfachere und energieeffizientere Technik den größeren Gewinn ergibt.

PCI Express 4.0 PCI Express 5.0 DDR5-Speicher
AMD – Desktop-CPUs Matisse (2019) nicht vor 2023 mglw. Zen 4 (2022)
AMD – HEDT-CPUs Castle Peak (2019) nicht vor 2023 Zen 4 (2022)
AMD – Server-CPUs Rome (2019) mglw. Genoa (2022) Genoa (2022)
AMD – APUs mglw. Renoir-Nachfolger (2021) unklar "Zen 3+" APU (2022)
AMD – Consumer-Grafikkarten Navi 10 (2019) mglw. Navi 3X (2022) -
AMD – HPC-Grafiklösungen Vega 20 (2018) mglw. CDNA2 (2022) -
Intel – Mobile-CPUs Tiger Lake (2020) unklar Tiger Lake (2020)
Intel – Desktop-CPUs Rocket Lake (2021) unklar Alder Lake (2022)
Intel – HEDT-CPUs unklar unklar unklar
Intel – Server-CPUs Cooper Lake & Ice Lake SP (2020) Sapphire Rapids (2021) Sapphire Rapids (2021)
nVidia – Consumer-Grafikkarten whrschl. Ampere GA10x (2020) mglw. Hopper (2022) -
nVidia – HPC-Grafiklösungen Ampere GA100 (2020) mglw. Hopper (2022) -

Laut einem (inzwischen bestätigten) Reddit-Beitrag hat Intel den Debug-Mode in seiner Code-Bibliothek "Math Kernel Library" (MKL) deaktiviert – mit welcher in Folge der Workaround zugunsten von AMD-Prozessoren (bei neu kompilierter Software) nicht mehr funktioniert und selbige drastisch langsamer laufen. Die MKL-Bibliothek wird für mathematische Software weithin genutzt, obwohl hieran doch das Problem augenscheinlich wird, den Programmcode eines Marktteilnehmers (Intel) anstatt eines unbeteiligten Dritten zu benutzen. Denn Intel dürfte den Debug-Mode sicherlich nicht per Zufall oder anderer Absicht herausgenommen haben – der Zweck ist augenscheinlich allein, AMD weitmöglichst zu stören. Dabei liegt die eigentliche Problematik eher darin, das Intel innerhalb der MKL-Bibliothek die AMD-Prozessoren nicht korrekt erkennen will, obwohl der Aufwand hierfür aufgrund bekannter Routinen zum Abfragen diverser CPU-Parameter grundsätzlich sehr einfach ist und von jedem semi-professionell erstellten Info-Tool beherrscht wird.

AMD hat diese Problematik die ganze Zeit über (leider) ignoriert, sollte nun aber spätestens im Zen-Zeitalter endlich einmal entsprechenden Wirbel & Druck machen. Normalerweise kann man Intel zwar nicht zwingen, irgendetwas in die Intel-Software zugunsten von AMD einzubauen – mit einer Ausnahme allerdings: Das korrekte Erkennen von CPU-Kapazitäten darf als absolut gegeben angesehen werden, das Gegenteil geht in Richtung eines Wettbewerbs-Verstoßes. Schließlich stehen die entsprechenden CPU-Register seit Jahrzehnten zur Verfügung, sind solcherart Dinge einfachstmöglich auszulesen. Im Endeffekt könnte Intel sich weigern, die AMD-Prozessoren vom Namen her korrekt auszulesen – aber nicht von den CPU-Features bezüglich AVX etc. her. Und genau da liegt schließlich die Problematik bei der MKL: Jene Code-Bibliothek läßt AMD-Prozessoren wegen der Nichterkennung der CPU-Features immer nur im non-AVX-Modus laufen, was jene teilweise drei Viertel (!) an Performance kostet. Ob auf diesem oder anderem Weg: AMD sollte hier energisch einhaken – denn selbst wenn es auf eine echte Schlammschlacht hinausläuft, stehen hier letztlich immer noch reale Performance-Auswirkungen im Bereich von Wissenschafts- und Mathematik-Software dahinter.

Der Planet 3DNow! berichtet über zwei weitere angekündigte Supercomputer auf Zen-3-Basis, in diesem Fall natürlich die "Zen 3" Server-Variante "Milan". Interessanterweise wird hierbei (auch im Original) von Systemen mit 128 CPU-Kernen berichtet, obwohl bislang eigentlich klar war, das Zen 3 auch in der Server-Variante nicht über 64 CPU-Kerne hinausgeht. Mit dem Chiplet-Verfahren wäre solches zumindest theroetisch möglich: Man bräuchte wohl einen neuen I/O-Chip und auf dem Package würde es dann ziemlich eng werden. Aber nur für einzelne Supercomputer wäre dies wahrscheinlich kostenmäßig gar nicht darstellbar – und am Ende bietet sich die ganz einfache Auflösung an, daß hierbei schlicht 2-Sockel-Systeme zum Einsatz kommen, wie sie im Server-Bereich sehr weit verbreitet sind. Mehr CPU-Kerne sind dann von nachfolgenden Zen-Generationen zu erwarten, welche zudem eine bessere Fertigungstechnologie zugunsten kleinerer Chips benutzen – sprich "Zen 4".

WinFuture machen auf die Problematik von smarten Kühlschränken hin, welche durchaus schon lange vor dem Ableben der reinen Technik ihre "Smart"-Fähigkeiten wegen mangelndem Hersteller-Support verlieren. Zum einen kann es zum Abschalten entsprechender Cloud-Dienste des Herstellers kommen, zum anderen könnte der Kühlschrank durch fehlende Sicherheits-Updates von seinen Smart-Fähigkeiten ausgeschlossen werden. Dabei garantieren die besten Hersteller gerade einmal 10 Jahre Sicherheits-Patches – was angesichts der üblichen Lebensdauer von Kühlschränken auch nicht besonders viel ist. Die Hersteller des Massenmarkts liegen zumeist weit unter dieser Marke oder lassen sich gleich gar nicht auf irgendeine bindende Aussage festnageln. Ob dies verbraucherschutzrechtlich langfristig durchgeht, darf jedoch bezweifelt werden – vermutlich muß sich da nur jemand finden, der das dann auch wirklich durchklagt. Der eigentliche springende Punkt ist, das man aufgrund dieser augenscheinlichen Sollbruchstelle jegliche "Smart"-Funktionalität in genau diesem Maßstab bewerten sollte, wie lange jene mittels garantierten Patches läuft. Sprich: Bei Modellen ohne wirkliche Garantien ist das Produkt dann letztlich genauso viel wert wie eines ohne jede "Smart"-Funktionalität.