1. Foren
  2. Kommentare
  3. PC-Hardware-Forum
  4. Alle Kommentare zum Artikel
  5. › RISC-V: MIPS gibt eigene…

In Order Execution

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema


  1. In Order Execution

    Autor: M.P. 11.05.22 - 13:34

    Ist das nicht auch sicherer?
    Gibt ja eine ganze Klasse von Sicherheitslücken, die Out-of-Order-Execution gerissen hat - Spectre ist die Bekannteste...

  2. Re: In Order Execution

    Autor: MarcusK 11.05.22 - 14:07

    M.P. schrieb:
    --------------------------------------------------------------------------------
    > Ist das nicht auch sicherer?
    ja, aber auch das langsamste.

    Out of Order macht man weil es schneller ist, nicht weil es unsicherer ist.

  3. Re: In Order Execution

    Autor: M.P. 11.05.22 - 14:13

    Der Artikel ist da etwas schwammig. Für das In-Order-Design wird "höherer Effizienz" konstatiert.

    Ist die Frage, was damit gemeint ist...
    Wenn die In-Order-Einheit mehr MIPS pro Watt schafft, als die Out-Of-Order-Einheit, kann das je nach Anwendung schon ein Kriterium sein ...

  4. Re: In Order Execution

    Autor: /mecki78 11.05.22 - 14:29

    M.P. schrieb:
    --------------------------------------------------------------------------------
    > Ist das nicht auch sicherer?
    > Gibt ja eine ganze Klasse von Sicherheitslücken, die Out-of-Order-Execution
    > gerissen hat - Spectre ist die Bekannteste...

    Spectre hat nichts mit Out-of-Order Execution sondern mit Sepuclative Execution zu tun.

    Out-of-Order Execution verändert nur die Reihenfolge, in der Operationen ausgeführt werden. Also statt

    a = b + c
    b = d + e
    c = a * f

    macht die CPU

    a = b + c
    c = a * f
    b = d + e

    weil das ggf. so schneller von der CPU abgearbeitet werden kann und die Reihenfolge der zwei unteren Operationen egal ist für das Endergebnis, da sie in keiner Weise voneinander abhängen.

    Bei Spectre hingegen geht es darum, dass eine CPU Code ausführt, nur weil sie denkt, dass sie diesen Code gleich sowieso ausführen muss, also

    Op1
    Condition = Op2
    if (Condition) {
    Op3
    }
    Op4

    Ob Op3 ausgeführt werden muss oder nicht, hängt von Condition ab. Den Wert von Condition kennt die CPU aber erst nach Op2, d.h. sie muss auf Op2 warten um entscheiden zu können, wie es danach weitergeht. Jetzt kann es aber sein, dass Op3 gar nicht von Op2 abhängt und die CPU während sie auf Op2 wartet eigentlich schon Op3 ausführen könnte, sie aber nicht weiß, ob sie das jemals tun muss.

    Wenn daher ihre Sprungvorhersage (Branch Prediction) besagt, dass die letzten x-Mal als diese Code lief immer Op3 ausgeführt wurde, muss das diesmal zwar nicht wieder der Fall sein, aber es ist zumindest sehr wahrscheinlich, dass es wieder der Fall sein wird. Also führt sie einfach Op3 auf Verdacht aus (also rein "spekulativ").

    Stellt sich heraus, dass das korrekt war, dann liegt das Ergebnis von Op3 bereits vor, wenn Op2 durch ist und die CPU kann sofort mit Op4 weiter machen, das spart Zeit und bringt mehr Leistung. War die Einschätzung falsch, tja, dumm gelaufen, dann muss die CPU eben wieder alles rückgängig machen was Op3 verändert hat und das ist teuer. Im Realbetrieb liegt aber die Sprungvorhersage heute in mehr 93% der Fälle korrekt (bei sehr kleinen Code schleifen sogar in über 97% der Fälle), so dass CPUs dank dieses Technik viel schneller arbeiten können, da sie weniger oft auf Operationen warten müssen.

    Und wenn sie mal falsch lag, dann merkt niemand was davon, denn die CPU räumt ja auf und ist dann wieder im Zustand wie vor der fälschlicherweise ausgeführten Operation. D.h., nicht ganz. Wenn die Operation das Cache verändert hat, dann wird das nicht wieder aufgeräumt, sondern bleibt verändert, was ja egal ist, weil es kann ja niemand in das Cache schauen ... dachte man zumindest, bis Spectre kam.

    Denn Spectre kann zwar auch nicht ins Cache schauen, nutzt aber die Tatsache aus, dass Daten, die aus dem Cache kommen viel schneller zu Verfügung stehen als Daten, die das nicht tun. Misst man also die Zeit, die die CPU gebraucht hat, um bestimmte Daten zu liefern, kann man so einen Rückschluss ziehen, ob diese Daten aus dem Cache kamen oder nicht. Somit weiß man, was im Cache steht und dass wiederum erlaubt Rückschlüsse wie eine Operation verlaufen sein muss, die das Cache verändert hat und rein spekulativ ausgeführt wurde, obwohl sie eigentlich nie hätte ausgeführt werden sollen (denn am Ende war "Condition" eben falsch).

    Und wenn man jetzt noch eine spekulative Operation so baut, dass durch die Art und Weise wie sie das Cache verändert man erkennen kann welcher Wert an eines bestimmten Speicheradresse gestanden ist, dann lässt sich so der Wert an dieser Adresse ermitteln, auch dann wenn der Code selber nie direkt Zugriff auf diese Adresse hätte bekommen können und so lassen sich dann z.B. Passwörter aus geschützten Speicherbereichen "auslesen" (also eigentlich rückgewinnen, denn direkt ausgelesen wurden die nie).

    /Mecki

  5. Re: In Order Execution

    Autor: schnedan 11.05.22 - 15:34

    richtig und falsch...

    bei Intel und ARM waren nur CPUs betroffen die OutofOrder hatten, weil nur diese auch Sprungvorhersagen nutzen. Außerdem war Meltdown eine OOO Lücke...

    Alte Intel Atom z.B. waren in Order und nicht betroffen.

  6. Re: In Order Execution

    Autor: M.P. 11.05.22 - 15:37

    Bedingt nicht Out-Of-Order Execution auf CPUs, die im Befehlssatz bedingte Sprünge haben Speculative Execution?

    Ich denke, die Out of Order Version des RISC-V wird auch Speculative sein, da das sonst zu viele Penalties kostet ...

  7. Re: In Order Execution

    Autor: /mecki78 11.05.22 - 16:28

    schnedan schrieb:
    --------------------------------------------------------------------------------
    > bei Intel und ARM waren nur CPUs betroffen die OutofOrder hatten, weil nur
    > diese auch Sprungvorhersagen nutzen.

    Das eine hat aber nichts mit dem anderen zu tun, nur weil das zufällig bei diesen beiden Herstellern der Fall war. PowerPC CPUs hatten schon ewig Out-of-Order Execution, auch schon bevor sie Sprungvorhersage bekamen.

    > Außerdem war Meltdown eine OOO Lücke...

    Meltdown und Spectre sind zwar paar Schuhe. Bei Meltdown geht es um die Umgehung der Priviledge Escalation, bei Spectre um die Umgehung von Speicherschutz.

    Meltdown hat sich die Tatsache zu Nutzen gemacht, dass die CPU auch dann auf Kernelspeicher zugreift, wenn sie bemerkt, dass dieser Zugriff aufgrund von Rechtebeschränkungen eigentlich gar nicht hätte erfolgen dürfen. Denn weil das Prüfen dieser Beschränkungen teuer und langwierig ist, wartet die CPU nicht ab, bis diese geprüft wurden, sondern geht grundsätzlich davon aus, Software wird schon keine absichtliche Zugriffsverletzung auslösen, da diese sowieso zum scheitern verurteilt wäre, also was sollte das bringen? Wenn so etwas passiert, dann doch wohl nur aufgrund eines Bugs und den würde man dann ja wohl fixen wollen, weil sonst funktioniert die Software ja nicht richtig.

    Also wird der Zugriff als gegeben angesehen und beretis ausgeführt, während im Hintergrund die Prüfung noch läuft und wenn die Prüfung merkt "Hoppla, das darf der Prozess ja gar nicht", dann löst das einen entsprechenden Fehler aus und die CPU tut so, als wäre der Zugriff nie erfolgt. Faktisch aber ist er aber zu dem Zeitpunkt schon erfolgt und das lässt sich ausnutzen, denn die Auswirkungen dieses Zugriffs lassen sich im Cache nachweisen.

    Bei Spectre hingegen ist es so, dass das System den Speicherschutz nur dann prüfen muss, wenn die Sprungvorhersage korrekt war. Der Trick ist hier die CPU glauben zu machen, dass ein bestimmter Sprung garantiert kommen wird (die Sprungvorhersage ist sich sicher, der Sprung wird erfolgen), dann aber dafür zu sorgen, dass er eben nicht erfolgt. Dann findet die Prüfung nämlich gar nicht mehr statt, weil die CPU sich dann sagt "Huch, ich sollte ja gar nicht auf den Speicher zugreifen; na gut, in dem Fall spielt es natürlich auch kein Rolle ob ich diesen Zugriff hätte machen dürfen oder nicht, weil der ist ja nur erfolgt, weil ich falsch vorhergesagt habe und dafür kann ich ja das Programm nicht abstrafen", aber das Cache wurde eben trotzdem bereits verändert.

    /Mecki

  8. Re: In Order Execution

    Autor: schnedan 11.05.22 - 16:45

    soweit ich es verstehe nutzt man bei der Sprungvorhersage den temporären Puffer den man eh für OutofOrder benötigt... Wahrscheinlich kann man das auch anders lösen, aber wenn du eh schon OOO hast, bietet es sich wohl an.

  9. Re: In Order Execution

    Autor: /mecki78 11.05.22 - 17:11

    M.P. schrieb:
    --------------------------------------------------------------------------------
    > Bedingt nicht Out-Of-Order Execution auf CPUs, die im Befehlssatz bedingte
    > Sprünge haben Speculative Execution?

    Nein. Die CPU kann ja auch nur immer nur solange Out-of-Order ausführen, bis sie zu einem bedingten Sprung kommt und dort dann warten, bis feststeht, ob der Sprung erfolgt oder nicht.

    Out-of-Order heißt einfach nur, dass die CPU die Reihenfolge der Anweisungen, die ihr gegeben wurde, frei bestimmen kann, solange das keinen Einfluss auf das Endergebnis hat. Viele CPUs haben das schon vor ewigen Zeiten getan, z.B. bei der Reihenfolge in der sie Speicherzugriffe durchgeführt haben, lange bevor sie Sprungvorhersage hatten.

    Speculative Execution heißt einfach nur, dass die CPU bei bedingten Sprüngen nicht pausiert, sondern einfach weiter Anweisungen ausführt und dabei den Sprungpfad folgt, den sie selber für a wahrscheinlichsten hält. Dabei muss sie aber Anweisungen nicht umsortieren, sondern kann sich strikt an die ihr vorgegebene Reihenfolge vor und nach dem Sprung halten.

    Beides kann also für sich alleine existieren und beides bringt schon für sich alleine Geschwindigkeitsvorteile und beides führt zu weniger Pipeline-Stalls und einer besseren CPU Auslastung.

    Out-of-Order macht sich auch dann schon bezahlt, wenn man z.B. eine Multiplikation vorzieht, wie in meinem Beispiel, da Additionen vielleicht alle von der gleichen Recheneinheit ausgeführt werden und daher nur nacheinander erfolgen können, Multiplikationen aber von einer anderen Einheit ausgeführt wird, die unabhängig ist und parallel zur Additionseinheit arbeiten kann. Ist also die Reihenfolge Add, Add, Mul, dann muss die ersten Addition auf die zweite warten und die Multiplikation kann nur parallel zur zweiten Addition laufen. Ist sie aber Add, Mul, Add, dann läuft die Multiplikation bereits parallel zur ersten Addition und parallel zur zweiten könnten bereits eine weitere Multiplikation laufen, usw.

    Umgekehrt kannst du in diesem Code:

    olatile int mixUp = 1; // Note the "volatile"!!!
    int result = 0;
    for (int x = 0; x < size; x += 2) {
    result ^= value[x];
    if (mixUp) result ^= (result << 1 + value[x + 1]);
    }

    nichts Out-of-Order ausführen. Der Code muss genau in dieser Reihenfolge laufen, wie er dort steht, sonst stimmt das Ergebnis nicht mehr. Du kannst aber Code spekulativ ausführen, denn wenn mixUp die letzten 5x true war, dann wird es wohl bis zum Ende der For-Schleife true bleiben und umgekehrt. Hier also auf das Ergebnis des Tests zu warten ist unsinnig.

    Und ja, das "volatile" ist wichtig, wenn ohne das würde der Compiler sagen "mixUp kann sich sowieso nicht in der Schleife ändern" und wirft dann das if komplett raus und macht das daraus:

    int result = 0;
    for (int x = 0; i < size; x += 2) {
    result ^= value[x];
    result ^= (result << 1 + value[x + 1]);
    }

    abgesehen davon, dass die meisten Compiler selbst mit volatile am Ende das daraus machen werden:

    volatile int mixUp = 1; // Note the "volatile"!!!
    int result = 0;
    if (mixUp) {
    for (int x = 0; i < size; x += 2) {
    result ^= value[x];
    result ^= (result << 1 + value[x + 1]);
    }
    } else {
    for (int i = 0; i < size; i += 2) {
    result ^= value[x];
    }
    }

    Wodurch der Sprung aus der Schleife raus ist und daher nur einmal am Anfang der Schleife stattfindet. Also bitte keine Erbsenzählerei, das ist nur ein demonstratives und kein realistisches Beispiel.

    Und ja, RISC-V wird hier natürlich beides haben, wer heute Speculative Execution einbaut, der baut auch Out-of-Order ein, und umgekehrt, schon alleine deswegen, da sich beide bestimmte Funktionen der Implementierung teilen können und somit sehr gut Hand in Hand arbeiten. Nur grundsätzlich bedingt das eine nicht das andere und Spectre ist ohne Speculative Execution nicht möglich, auch dann nicht, wenn die CPU Out-of-Order Execution beherrscht.

    /Mecki



    2 mal bearbeitet, zuletzt am 11.05.22 17:14 durch /mecki78.

  1. Thema

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Sachbearbeiter (m/w/d) Filial-Hotline
    Dirk Rossmann GmbH, Burgwedel
  2. EDV-Organisationsberater*in IT-Administration
    Evangelische Kirche in Hessen und Nassau, Darmstadt
  3. App Entwickler (w/m/d)
    Digital Building Solutions GmbH, Sendenhorst (Münster)
  4. SAP Senior Inhouse Consultant MM/LE (m/w/d)
    OMIRA GmbH, Ravensburg

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 499,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de