-
Speicheroptimierungsfunktionen
Autor: /mecki78 09.08.23 - 11:35
Alle gravierenden Intel CPU Schwachstellen der letzten 10 Jahre sind auf Optimierungen zurück zu führen, denn nur durch solche Tricks kann x86 überhaupt noch Leistungssteigerungen verbuchen.
Die x86 CPU Architektur ist zu komplex, um den Takt noch groß weiter hochschrauben zu können. Hier hat man schon lange einen Peak erreicht:
Heute lässt sich die Performance hauptsächlich durch mehr Kerne steigern, nur auch hier hat x86 ein Problem: x86 CPUs geben viel mehr Garantien als andere Architekturen. Diese Garantien müssen aber über all Kerne und alle geteilten Caches hinweg eingehalten werden, was zunehmend zum Problem wird, je mehr es davon gibt. Das Ergebnis sind extrem komplexe Bus Systeme, die viel Strom verschlingen und die am Ende zum Flaschenhals werden können.
Echte Performancegewinne ergeben sich daher bei x86 nur noch aus neuen CPU Anweisungen, die aber die Architektur immer unübersichtlicher und inkonsistenter zu sich selber machen und nur etwas bringen, wenn Code diese auch sinnvoll nutzen kann (was sowieso immer nur auf neuen Code zutrifft und auch nur dann, wenn Compiler da mitspielen) oder eben durch Optimierungstricks. Und letzteres führen regelmäßig zu Sicherheitsproblemen, denn Sicherheit steht bei Optimierung nicht im Vordergrund.
/Mecki -
Re: Speicheroptimierungsfunktionen
Autor: MarcusK 09.08.23 - 11:46
/mecki78 schrieb:
--------------------------------------------------------------------------------
> Alle gravierenden Intel CPU Schwachstellen der letzten 10 Jahre sind auf
> Optimierungen zurück zu führen, denn nur durch solche Tricks kann x86
> überhaupt noch Leistungssteigerungen verbuchen.
>
> Die x86 CPU Architektur ist zu komplex, um den Takt noch groß weiter
> hochschrauben zu können. Hier hat man schon lange einen Peak erreicht:
>
> i.postimg.cc
> Heute lässt sich die Performance hauptsächlich durch mehr Kerne steigern,
> nur auch hier hat x86 ein Problem: x86 CPUs geben viel mehr Garantien als
> andere Architekturen. Diese Garantien müssen aber über all Kerne und alle
> geteilten Caches hinweg eingehalten werden, was zunehmend zum Problem wird,
> je mehr es davon gibt. Das Ergebnis sind extrem komplexe Bus Systeme, die
> viel Strom verschlingen und die am Ende zum Flaschenhals werden können.
>
> Echte Performancegewinne ergeben sich daher bei x86 nur noch aus neuen CPU
> Anweisungen, die aber die Architektur immer unübersichtlicher und
> inkonsistenter zu sich selber machen und nur etwas bringen, wenn Code diese
> auch sinnvoll nutzen kann (was sowieso immer nur auf neuen Code zutrifft
> und auch nur dann, wenn Compiler da mitspielen) oder eben durch
> Optimierungstricks. Und letzteres führen regelmäßig zu
> Sicherheitsproblemen, denn Sicherheit steht bei Optimierung nicht im
> Vordergrund.
du schreibt es, als ob hier x86 das Problem ist. Aber auch ARM ist von Spectre betroffen gewesen. Es ist also ein generelles Problem bei der Optimierung.
Und mehr CPUs führ leider auch zu mehr Overhead. -
Re: Speicheroptimierungsfunktionen
Autor: /mecki78 09.08.23 - 12:07
MarcusK schrieb:
--------------------------------------------------------------------------------
> du schreibt es, als ob hier x86 das Problem ist.
Ist es weitgehend auch. Natürlich verwenden auch andere Architekturen manchmal die gleichen Optimierungen, aber anders als x86 sind diese nicht zwingend auf diese angewiesen. Andere Architekturen tun sich viel leichter damit die Anzahl der Kerne weiter zu erhöhen bzw. noch etwas mehr an der Taktrate zu schrauben und können daher ihre Leistung auch ohne diese Optimierungstricks immer noch steigern.
Denn was viele übersehen, man kann diese Sicherheitslücken oft nicht beheben, ohne die entsprechende Optimierung weitgehend abzuschalten. Die Fixes für Meltdown, Spectre und Spetcre-NG haben Intel CPUs erhebliche Performanceeinbußen gebracht, aber die meisten veröffentlichten Benchmarks dieser CPUs zeigen die Ergebnisse vor diesen Fixes. In Wahrheit sind die CPUs dadurch in der Praxis aber teilweise drastisch langsamer geworden in bestimmten Situationen.
Von den über zwei dutzend Lücken aus diesem Bereich bei Intel (das sind nur Oberbegriffe, Spectre ist z.B. nicht nur eine einzige Lücke, sondern es gibt verschiedene Anweisungen, die davon unterschiedlich betroffen waren), war ARM aber nur etwa von einem halben dutzend überhaupt betroffen und bei weiten nicht jede ARM CPU von jeder Lücke. Der wichtigere Punkt ist aber, dass ARM CPUs durch die Fixes viel weniger Performance verloren haben als Intel und selbst ganz ohne diese Optimierung noch immer eine deutliche Leistungssteigerung gegenüber der vorherigen Generation aufweisen, während bei Intel die meisten Leistungssteigerungen gegenüber der vorherigen Generation nur noch auf solche Optimierungstricks basieren und musst du die dann abdrehen, dann bleibt eben nicht mehr viel übrig.
/Mecki -
Re: Speicheroptimierungsfunktionen
Autor: MarcusK 09.08.23 - 12:24
/mecki78 schrieb:
--------------------------------------------------------------------------------
> Der wichtigere Punkt ist aber,
> dass ARM CPUs durch die Fixes viel weniger Performance verloren haben als
> Intel und selbst ganz ohne diese Optimierung noch immer eine deutliche
> Leistungssteigerung gegenüber der vorherigen Generation aufweisen, während
> bei Intel die meisten Leistungssteigerungen gegenüber der vorherigen
> Generation nur noch auf solche Optimierungstricks basieren und musst du die
> dann abdrehen, dann bleibt eben nicht mehr viel übrig.
was auch klar ist, denn die Pro Core Performance ist bei Intel immer noch besser als bei ARM. Arm musste also noch gar nicht tief in die Trickkiste greifen um schneller zu werden.
Klar hat der Apple M2 schon gut aufgeholt, aber wurde denn dort nach solchen Lücken überhaupt schon gesucht? Ist ja kein Standard-ARM mehr. Sie werden genauso durch Optierungen die Leistung gesteigert haben wie auch Intel und AMD. Und es werden mit hoher Wahrscheinlichkeit dort genau solche Fehler vorhanden sind.
Eventuell wird es in Zukunft 2 Verwendungszwecke für CPUs geben, einmal für Sicherheitskritische dinge die langsamer sind. Und einmal wo maximal Leistung gefordert wird und die Sicherheit keine rolle spielt. ( Wettermodelle, KI, Games )
Wenn man nur eigenen Code auf einer CPU ausführt, dann spielen die Lücken alle gar keine rolle, das will man maximal Leistung bei möglichst wenig Energiebedarf. -
Re: Speicheroptimierungsfunktionen
Autor: me2 09.08.23 - 12:50
/mecki78 schrieb:
--------------------------------------------------------------------------------
> Die x86 CPU Architektur ist zu komplex, um den Takt noch groß weiter
> hochschrauben zu können. Hier hat man schon lange einen Peak erreicht:
>
In dieser Grafik geht die blaue Linie vielleicht von 1988 bis 2008. Und bis heute fehlen 15 Jahre an Daten! Und auf der anderen Seite war die Statistik gerade mal 20 Jahre lang, und bestenfalls 2 Jahre davon deuten auf den prognostizierten Trend hin.
Zudem ist sehr offensichtlich, dass diese Grafik anscheinend erstellt wurde um ganz gewusst einen falschen Eindruck zu vermitteln:
- Wenn man sich die schwarzen Punkte anschaut, ist klar ein Trend nach oben zu erkennen. Aber nach der Grafik nach kommt ein überraschender Knick. 64-Kern-Prozessoren gäbe es gar nicht.
- Der grüne und der blaue Trend wird bewusst nicht nur als stagnierend sondern sogar als sinkend dargestellt. Die statistischen Daten allein geben das aber nicht her.
- Die Gesamt-Performance ist bewusst nicht aufgeführt, nur die Single-Thread Performance.
Diese Grafik erinnert mich eher an die vielen immer wiederholenden Behauptungen schon in den 1990er Jahren, dass bald aus technologischen Gründen keine Leistungs-Steigerung mehr möglich wäre. Und dann hat man es einfach ein bisschen anders gemacht und schon war die angebliche Grenze wieder gebrochen. Und dann kam die nächste Behauptung, dass jetzt bald keine Steigerung mehr möglich wäre. Vermutlich wurden in diesem Sinne die Trendlinien erstellt.
Aber das Moorsche Gesetz und seine vielen falschen Adaptionen ist ein Zombie. Kaum denkt man, man hätte es getötet, taucht es leicht verwandelt wieder auf und lebt einfach weiter in etwas anderer Form.
Hast du nicht aktuelle Zahlen um deine Behauptung zu untermauern? Denn prinzipiell, ist die dahinter stehende Aussage ja nicht ganz falsch. Letztlich sind es Pipeline-Verkürzung, Effizienter machen, Parallelisierung, Spezialisierung (GPU/GPPU/AI cores/...) oder schlicht Beschleunigung an viel entscheidenderer Stelle (SSD, Speicherschnittstellen, ...), die uns die Gesamt-Performance immer mehr nach oben bringen. Allerdings ist es auch kein reines x86 Architektur-Problem, auch wenn sich x86 aufgrund der vielen Altlasten sehr viel schwerer damit tut. -
Re: Speicheroptimierungsfunktionen
Autor: Brian Kernighan 09.08.23 - 13:03
/mecki78 schrieb:
--------------------------------------------------------------------------------
> MarcusK schrieb:
> ---------------------------------------------------------------------------
> -----
> > du schreibt es, als ob hier x86 das Problem ist.
>
> Ist es weitgehend auch. Natürlich verwenden auch andere Architekturen
> manchmal die gleichen Optimierungen, aber anders als x86 sind diese nicht
> zwingend auf diese angewiesen.
Das ist so nicht richtig. Ohne Out of Order Execution, spekulative Ausführung und tiefe Pipelines erreichen auch CPUs mit klassischen RISC ISAs niemals die Performance, die heute gefordert wird. Für die Klasse Bugs, die auf Seitenkanaleffekten basieren sind somit alle arten von CPUs mit Optimierungen anfällig.
Kann schon sein, dass durch die komplexen Instruktionen bei CISC ISAs, die nur intern RISC sind noch mehr Bugs existieren, aber ich denke da kommen eher welche in Frage, die aus der schieren Komplexität erwachsen.
Grundsätzlich ist es ein Tradeoff zwischen Performance und Sicherheit, und hier wäre es wünschenswert, wenn es für die CVEs eine bessere Klassifizierung gäbe. Für einen großen Teil der Usecases sind viele der Sicherheitsprobleme nämlich kaum relevant bzw. so aufwändig auszunutzen, dass der Tradeoff zwischen Risiko und Nutzen des verwundbar bleibens deutlich Richtung letzteres ausschlägt.
So muss jeder Furz gefixt werden, der für 95% der User egal ist, aber teils die Performance um eine Größenordnung verschlechtert (bei Spectre/Meltdown selbst gesehen, auf Systemen wo nie ein externer User drauf käme oder überhaupt einen direkte Verbindung zum Internet bestanden hätte).
> Andere Architekturen tun sich viel leichter
> damit die Anzahl der Kerne weiter zu erhöhen bzw. noch etwas mehr an der
> Taktrate zu schrauben und können daher ihre Leistung auch ohne diese
> Optimierungstricks immer noch steigern.
Können sie nicht. Die Taktfrequenz ist auch bei RISC irgendwo nicht mehr weiter zu erhöhen aufgrund rein physikalischer Gegebenheiten. Und ohne Optimierungen laufen die auch nicht mit der nötigen Performance. -
Re: Speicheroptimierungsfunktionen
Autor: Brian Kernighan 09.08.23 - 13:19
me2 schrieb:
--------------------------------------------------------------------------------
> Letztlich sind es Pipeline-Verkürzung, Effizienter machen,
> Parallelisierung, Spezialisierung (GPU/GPPU/AI cores/...) oder schlicht
> Beschleunigung an viel entscheidenderer Stelle (SSD,
> Speicherschnittstellen, ...), die uns die Gesamt-Performance immer mehr
> nach oben bringen.
Ich stimme Dir grundsätzlich in allem zu, aber seit wann hat Pipeline-Verkürzung irgendwas schneller gemacht? Tatsächlich wurden die CPUs immer schneller wegen immer längerer Pipelines, die die vorhandenen Rechenwerke stärker auslasten und besser mit den starken Verzögerungen durch Cache-Misses zurecht kommen.
Dazu muss man halt ganz viel spekulativ und Out of Order ausführen, um Pipeline-Stalls auf ein Minimum zu reduzieren. Da kommen dann ja auch die ganzen Seitenkanal-Bugs her.
Oder meintest Du das ernst mit der Pipeline-Verkürzung? Dann bitte genauer erklären/verlinken, das hab ich bisher noch nicht gehört.



