TechPowerUp warten mit der erstaunlichen Meldung auf (in Berufung allerdings auf eine Auskunft durch AMD), das der Polaris 30 Chip für die Radeon RX 590 nicht nur von GlobalFoundries gefertigt wird, sondern auch von Samsung. Bei den vorhergehenden Polaris-Chips war diese Strategie mit zwei Chipfertigern schon bekannt – dort aber auch extrem einfach zu realisieren, da die 14nm-Fertigung von GlobalFoundries technologisch eine Lizenz der 14nm-Fertigung von Samsung darstellt, entsprechende Chip-Designs also ohne wirkliche Anpassungen bei beiden Auftragsfertigern produziert werden können. Laut TechPowerUp soll nun aber Samsungs 11nm-Fertigung der 12nm-Fertigung von GlobalFoundries ausreichend genau entsprechen, auf das dieses System auch auf Polaris 30 übertragbar ist – womit AMD unabhängiger etwaiger Kapazitätsengpässe wird, was eingedenk der aktuell hohen Auslastung von GlobalFoundries sicherlich seine Vorteile hat. Ob man Samsungs 11nm-Fertigung dann auch für die aktuellen Pinnacle-Ridge-Prozessoren der Zen+ Generation verwenden könnte, ist dabei sicherlich eine interessante Frage: Auf den ersten Blick sollte dies funktionieren, andererseits hat Samsung bislang keine echten Hochtaktdesigns (Richtung 4 GHz) mit dieser Chipgröße sowie in Großserie hergestellt, ergo könnte dies in der Praxis schwieriger sein als gedacht.

Bei Tom's Hardware hat man sich mit einem speziellen BIOS-Programmierungs-Gerät daran versucht, bei einer GeForce RTX 2070 ein non-A-BIOS durch ein A-BIOS von nVidias Turing zu ersetzen. Als Grundlage hierfür dienten die MSI-Modelle "Armor" sowie "Gaming Z", welche nahezu baugleich sind. Leider antwortete das Testexemplar auf den erfolgreichen Flash mit einem nicht erfolgreichen Bootvorgang, kann also trotz eines größeren Datensatzes, als welchen NVflash oder GPU-Z auslesen können, nicht mit dem BIOS eines A-Modells starten. Tom's Hardware gehen demzufolge von einer Hardware-Barriere aus – was auch nicht wirklich gänzlich überraschend ist, selbige existiert bekannterweise schon im Quadro-Bereich, um die Umwandlung einer (vergleichsweise) günstigen GeForce- in eine teure Quadro-Karte zu verhindern. Ergo wird es wohl keine einfache Lösung geben, um an die höherwertigen BIOS-Versionen asugehend von einem non-A-Modell zu kommen. Die non-A-Modelle werden also immer einen gewissen Hardware-Unterschied aufweisen und damit insbesondere für den Übertaktungseinsatz eher ungeeignet bleiben.

Bei Phoronix hat man eine erhebliche Performance-Differenz zwischen den Linux-Versionen 4.19.1 und 4.20 festgestellt, welche in einzelnen Benchmarks durchaus 30% betragen kann. Als primärer Grund hierfür wurde ein neuer Spectre-Schutz ermittelt: Die Schutzmaßnahme "Single Thread Indirect Branch Predictors" (STIBP) richtet sich gegen eine von Spectre V2 provozierte Lücke speziell unter HT/SMT-Systemen. Ein nachfolgender Artikel geht dann dem insgesamten Performance-Einfluß von Meltdown & Spectre unter Linux 4.20 nach – indem mit/ohne aller diesbezüglichen Schutzmaßnahmen getestet wurde. Hierbei ergab sich ein beachtlich hohes Ergebnis von +19,4% Performancegewinn ohne Meltdown/Spectre-Fixes bzw. -16,2% Performance-Verlust mit Meltdown/Spectre-Fixes – ermittelt über ein breites Feld von Server- und Workstation-Benchmarks. Weniger betroffen war dabei Anwendungs-Software wie GIMP oder diversen Render-Programmen, dort lagen die Performanceverluste zumeist geringer als im allgemeinen Schnitt.

Unter Server-Benchmarks (zu PHP, HTTP, Kontext-Switching, Speicherperformance, etc.) fiel das Ergebnis mit +30,7% bzw. -23,5% dann noch einmal etwas drastischer aus – und erreicht damit Dimensionen, welche sogar grob oberhalb der Deaktivierung von HyperThreading bzw. SMT gehen. Jetzt waren Server-Umgebungen aufgrund der zumeist abwechselungsreichen Lasten und des höheren Einflusses der Speicherperformance schon immer Performance-anfälliger auf die früheren Meltdown/Spectre-Fixes, speziell die STIBP-Schutzmaßnahme unter Linux 4.20 treibt das ganze nun jedoch ernsthaft auf die Spitze. Somit dürften im professionellen Umfeld jetzt durchaus einige Server nicht mehr diese Performance erbringen können, für welche jene einstmals gedacht waren – womit Nachrüstungen oder gar ein Neukauf anzutreten wären. Angesichts der weiterhin nicht behobenen 14nm-Lieferprobleme bei Intel kommt dies natürlich auch noch zum ungünstigst möglichen Zeitpunkt. Unklar bleibt hingegen, ob jene STIBP-Schutzmaßnahme nicht auch unter Windows anzusetzen wäre – wobei sich Microsoft sicherlich schwer darin tun wird, derart viel Performance auf einen Hieb zu opfern.

WinFuture notieren die Arbeit Apples an einem lokalem Siri-System – welches also die Sprachanalyse nicht mehr über Apples Cloud-Server löst, womit Apple dann eben auch nicht all das persönlich gesprochene Wort in den eigenen Datenbestand einsortieren kann. Dies resultiert zum einen aus der technologischen Entwicklung, das heutige Smartphone-SoCs leistungsfähig genug werden, um diese Aufgabe lokal (auf dem Gerät selber) zu erledigen. Zum anderen aber liegt hier auch eine Strategieentscheidung Apples zugrunde, Datenschutz regelrecht als Verkaufsargument zu benutzen – ein erstaunlicher Paradigmenwechsel bei Apple, aber deswegen um so mehr zu begrüßen. Apple kommt hierbei natürlich auch die konkrete Situation zu gute, das man eher ein Hardware-Hersteller ist und daher nicht wie viele Kontrahenten darauf angewiesen ist, an den Daten der eigenen Kunden zu verdienen. Apples spezielle Konstruktion als "Komplettanbieter mit Hardware & Software aus einer Hand" hat demzufolge sogar mal einen handfesten Vorteil. Abzuwarten bleibt (leider), wie lange Apple diese Strategie durchhalten kann – denn irgendwann ist da ein größerer Konflikt mit diversen Regierungen vorprogrammiert, welche sich ihre Untertanen-Überwachungsmöglichkeiten ungern wegnehmen lassen.