1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Meltdown und Spectre: "Dann sind wir…

Das Kochbeispiel

  1. Thema

Neues Thema Ansicht wechseln


  1. Das Kochbeispiel

    Autor: Keridalspidialose 18.01.18 - 12:05

    Wäre es nicht eher so dass der Prozessor Nudeln, Reis, Katoffeln, Bohnen, Sauerkraut und Pommes vorbereitet...?

    Wenn ich das Rezept bis zum Ende lese, und sehe dass ich Reis benötige, dann ist da nichts Spekulatives.

    ___________________________________________________________

  2. Re: Das Kochbeispiel

    Autor: intergeek 18.01.18 - 12:11

    Keridalspidialose schrieb:
    --------------------------------------------------------------------------------
    > Wäre es nicht eher so dass der Prozessor Nudeln, Reis, Katoffeln, Bohnen,
    > Sauerkraut und Pommes vorbereitet...?
    >
    > Wenn ich das Rezept bis zum Ende lese, und sehe dass ich Reis benötige,
    > dann ist da nichts Spekulatives.

    Ja das ist wirklich ein schlechtes Beispiel, vor allem als Mensch sollte man sich ein Rezept schon mal anschauen bevor man anfängt ;) Es wäre eher spekulativ wenn ich eine Suppe kochen will und weder das Rezept noch meinen Kühlschrank kenne und auf gut Glück in den Supermarkt gehe und dort Dinge kaufe die ich evtl. brauchen könnte für meine Suppe ;)

  3. Re: Das Kochbeispiel

    Autor: _BJ_ 18.01.18 - 12:17

    Das Beispiel ist gut. Du musst dir das Rezept als das Programm vorstellen das auf dem Prozesor läuft. Nein Pommes macht er dafür definitiv nicht. Aber der Prozessor würde z.B. Fleisch braten obwohl man die vegetarische Variante möchte. Er führt also Varianten des Rezeptes aus die später wieder verworfen werden.

  4. Re: Das Kochbeispiel

    Autor: lottikarotti 18.01.18 - 12:18

    > Wenn ich das Rezept bis zum Ende lese, und sehe dass ich Reis benötige,
    > dann ist da nichts Spekulatives.
    Das war eigentlich nur ein Beispiel für das *Problem*, welches der Prozessor mit Speculative Execution lösen will und nicht für die Vorgehensweise an sich.

    R.I.P. Fisch :-(

  5. Re: Das Kochbeispiel

    Autor: MrAnderson 18.01.18 - 12:22

    Ich find das Beispiel super .... im Gegensatz zu den Kfz-Vergleichen :)

    In meinem Zwischenspeicher liegen z.B. auch immer spekulativ Reis, Nudeln, Kartoffeln und Knödel. Oft entscheidet sich nämlich erst während des Prozesses (Kochen), welche Beilage verwendet wird.

  6. Re: Das Kochbeispiel

    Autor: Anonymer Nutzer 18.01.18 - 12:43

    Keridalspidialose schrieb:
    --------------------------------------------------------------------------------
    > Wenn ich das Rezept bis zum Ende lese, und sehe dass ich Reis benötige,
    > dann ist da nichts Spekulatives.
    Stell dir vor im Rezept steht, "Kartoffeln oder Reis als Beilage".

    Nun hast du ein erstes Date und kochst einfach mal beides und das Date kann sich dann aussuchen, ob sie Reis oder Kartoffeln nimmt. Du nimmst dann das gleiche und kannst das, für das sie sich nicht entschieden hat, "verwerfen".

    Sprich du weißt vorher nicht, welchen der beiden Zweige du "bearbeiten" sollst und machst "speckulativ" erstmal beide.

  7. Re: Das Kochbeispiel

    Autor: rapunzel666 18.01.18 - 13:13

    speckulativ wäre aber nicht vegetarisch :-)

  8. Re: Das Kochbeispiel

    Autor: JohnDoeJersey 18.01.18 - 14:31

    DAUVersteher schrieb:
    > Stell dir vor im Rezept steht, "Kartoffeln oder Reis als Beilage".
    >
    > Nun hast du ein erstes Date und kochst einfach mal beides und das Date kann
    > sich dann aussuchen, ob sie Reis oder Kartoffeln nimmt. Du nimmst dann das
    > gleiche und kannst das, für das sie sich nicht entschieden hat,
    > "verwerfen".

    Nein, Branch Prediction mit Speculative Execution bei CPUs bedeutet: die letzten fünf Male hat deine Freundin einmal Kartoffeln und viermal Reis gewählt, deshalb kochst du schonmal Reis. Entscheidet sie sich für Reis: Glück gehabt, Zeit gespart. Entscheidet sie sich aber für Kartoffeln, wirfst du den Reis weg und kochst die Kartoffeln, Essen gibt es daher erst 25 Minuten später. Beim ersten Date hast du keine Vorinformationen und kannst nur raten.

    Wenn die CPU *beide* Zweige spekulativ ausführen würde, würde das in vielen Situationen (verkettet if-Abfragen o.ä.) ganz schnell explodieren und die Ressourcen des Prozessors sprengen. Stattdessen wird seit 20 Jahren viel Arbeit dareingesteckt, die Vorhersage, *welche* Abzweigung genommen wird, immer besser zu machen. Und genau hier liegt die Crux von Spectre, wenn der Angreifer weiss, wie die CPU diese Vorhersagen macht, kann er das gezielt beeinflussen.

  9. Re: Das Kochbeispiel

    Autor: %username% 20.01.18 - 07:14

    rapunzel666 schrieb:
    --------------------------------------------------------------------------------
    > speckulativ wäre aber nicht vegetarisch :-)
    Applaus, Applaus :D

    1337 mal bearbeitet, zuletzt am 32.13.2599 13:61 durch %username%.

  10. Re: Das Kochbeispiel

    Autor: intergeek 21.01.18 - 09:45

    Aber mal eine ganz doofe Frage. Ist dieses spekulative Vorarbeiten einer CPU nicht eigentlich Unsinn? In meinen Augen macht es ja keinen Sinn wenn die CPU schon dutzende Varianten was der Nutzer als nächstes tut errät wenn am Ende eh nur eine Option richtig sein kann bzw. der User etwas ganz anderes macht. Ist der Zeitgewinn da wirklich so hoch? Eigentlich könnte die CPU wenn nichts zu tun ist ja einfach Strom sparen.

    Dieses Spekulieren könnte ja die Software genau so, vermutlich sogar besser. Eine Software kann ja vom Entwickler, Compiler oder im besten Fall von beiden optimiert werden. Der Entwickler weiß ja was es in welcher Situation für Optionen gibt und dann können die nächsten Schritte ja schon geplant werden.

    Wobei in den meisten Fällen ist diese Spekulation ja eh sinnfrei da der Nutzer die für das Ergebnis benötigten Parameter meist erst liefert.

  11. Re: Das Kochbeispiel

    Autor: CupOfJoe 22.01.18 - 11:02

    Witzig, dass er ein Kochbeispiel bringt. Hier hatte ich es schon einmal im Detail versucht:
    https://www.heise.de/forum/p-31701730/

  12. Re: Das Kochbeispiel

    Autor: thomas42 22.01.18 - 11:03

    Jein.
    Ja, du hast Recht, spekulative Ausführung ist letztendlich ein abmindern einer nicht optimalen Codequalität.
    Nein, sehr viele Entwicklungen der letzten 20 Jahren zielen darauf ab, dem Entwickler Arbeit abzunehmen, damit er sich auf die Fachlichkeit im Code konzentrieren kann. Bestes Beispiel ist Java, wo ich sehr viel Performance opfere um den Entwickler von dummen Fehlern abzuhalten.
    Performance (und, vor allem Security,) interessieren die meisten Entwickler nicht mehr.

  13. Re: Das Kochbeispiel

    Autor: Tuxgamer12 22.01.18 - 12:08

    intergeek schrieb:
    --------------------------------------------------------------------------------
    > Aber mal eine ganz doofe Frage. Ist dieses spekulative Vorarbeiten einer
    > CPU nicht eigentlich Unsinn? In meinen Augen macht es ja keinen Sinn wenn
    > die CPU schon dutzende Varianten was der Nutzer als nächstes tut errät wenn
    > am Ende eh nur eine Option richtig sein kann bzw. der User etwas ganz
    > anderes macht. Ist der Zeitgewinn da wirklich so hoch? Eigentlich könnte
    > die CPU wenn nichts zu tun ist ja einfach Strom sparen.

    Nein! Absolut keine doofe Frage! So etwas lernt man Informatikstudium so drittes Semester - völlig klar, dass nicht jeder den technischen Hintergrund kennen kann. In deinem Fall hast da etwas einfach nicht richtig verstanden.

    Spekulatives Ausführen hat (in diesem Kontext) rein gar nichts mit Nutzerinteraktion zutun. Kann sein, dass du in z.B. irgendwelchen Spielen schon Frames im Vorraus berechnest ohne zu wissen, was der Nutzer macht - das machst du aber dann auf Anwendungs-Ebene und hat mit dem Prozessorfeature nicht viel zutun.

    Der Witz ist, dass jeder Befehl, den du letztendlich ausführst, verschiedene Phasen hat - also z.B. etwas in der Richtung:

    * Musst erst mal den Befehl aus dem Speicher holen
    * Dann den Befehl dekodieren
    * Die Operationen aus dem Speicher holen
    * Die eigentliche Berechnung ausführen
    * Das Ergebniss irgendwo hinschreiben

    Das muss ja letztendlich alles auf das Silikon. Jetzt ist die Sache die: Während du z.B. deinen Befehl dekodierst, steht der größte Teil deines Chips einfach da ohne etwas zu machen. z.B. auch dein eigentliches Rechenwerk steht signifikante Zeit einfach da ohne Aufgabe, weil die Befehle vorbereitet werden müssen.

    Und das hat man irgendwann gemerkt und ist auf die Idee gekommen, wieso wir das nicht Parallelisieren.
    Also während der Befehl ausgeführt wird, könnten wir doch schon den nächsten Befehl aus dem Speicher holen und vorbereiten.

    Bedeutet: Auf dem selben Kern und Thread führen wir nicht nur einen Befehl ausgeführt, sondern gleichzeitig 5 (aufeinanderfolgende) Befehle eines Programms. -> Pipeline
    Grob vereinfacht: Wenn alles gut läuft, sprechen wir von möglichen Zeitgewinn von Faktor 5 (!). Also um deine Frage zu beantworten: Der Zeitgewinn ist gigantisch.

    Und jetzt könnte ein Programm so aussehen:

    x=1+1
    wenn x == 2; dann
    Befehl 1
    sonst
    Befehl 2

    Und Programmcode besteht aus lauter solchen bedingten Sprüngen.

    Wie du siehst, hängt da auch nichts von Nutzereingabe ab. Trotzdem - während 1+1 und x==2 gerechnet wird, steht ein signifikanter Teil unseres Chipes leer, wo wir GRATIS Sachen rechnen könnten. Der Prozessor hat aber schlicht und einfach noch nicht berechnet, wie es weitergeht.

    Und jetzt kommt die spekulative Ausführung: Wir führen also einfach mal spekulativ Befehl 1 aus - und mit etwas Glück waren wir richtig und konnten bestimmte Sachen gratis ausführen (-> Zeiterspraniss) oder wir haben Pech gehabt.

    Im obrigen Fall hätten wir mit einer Wahrscheinlichkeit von 50% Zeitgewinn von praktisch Faktor 5 - und mit 50% Pech gehabt. Um das weiter zu optimieren, haben Prozessoren eine sogenannte Sprungvorhersage (-> Meltdown Variante 2). Man schaut einfach, wo das wenn das letzte mal hingegangen ist - und optimiert so seine Wahrscheinlichkeit.

    Meltdown kommt dann ja noch out-of-order dazu - also dass du die Reihenfolge der Befehle abänderst um noch besser Befehle gleichzeitig ausführen zu können - kann ja sein, dass du so etwas hast wie:

    x=1
    y=x
    z=1+1

    währen du x=1 ausführst, kanst du wohl schlecht y=x ausführen (hast da ja eine Abhängigkeit). Aber du kannst z=1+1 ausführen - deshalb ziehst du z=1+1 vor.

    Hoffe, das war einigermaßen verständlich. Wie du siehst, reden wir hier keinesfalls von unnötigen Schnick-schnack, sondern extremen Grundlagen, ohne denen moderne Prozessoren mit der heutigen Geschwindigkeit nicht möglich wären.



    1 mal bearbeitet, zuletzt am 22.01.18 12:10 durch Tuxgamer12.

  14. Re: Das Kochbeispiel

    Autor: intergeek 22.01.18 - 16:50

    Tuxgamer12 schrieb:
    --------------------------------------------------------------------------------
    > Hoffe, das war einigermaßen verständlich. Wie du siehst, reden wir hier
    > keinesfalls von unnötigen Schnick-schnack, sondern extremen Grundlagen,
    > ohne denen moderne Prozessoren mit der heutigen Geschwindigkeit nicht
    > möglich wären.

    Sagen wir mal so, so verständlich wie das ein Techniker einem Nichttechniker wohl erklären kann ;) Danke erst einmal!

    Wobei es doch auch irgendwie faszinierend ist das es Leute gibt die so komplexe Dinge bauen und verstehen können. Eigentlich ist es ja erstaunlich das diese zusammenschaltung von Milliarden Transistoren so zuverlässig funktioniert ;)

    Also kann ich mir als normaler Programmiere das ganze am ehesten mit der Asynchronität von JavaScript vorstellen. Während ein Befehl ausgeführt wird versucht der Prozessor während er z.B auf langsamere Dinge wie Speicherzugriffe wartet schon einmal zu erraten was danach kommen könnte um dann mit etwas Glück erneute langsame Zugriffe auf irgendwas zu vermeiden.

  1. Thema

Neues Thema Ansicht wechseln


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. DRÄXLMAIER Group, Vilsbiburg bei Landshut
  2. MEIERHOFER AG, München
  3. Mainova AG, Frankfurt am Main
  4. Information und Technik Nordrhein-Westfalen (IT.NRW), Düsseldorf, Köln

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (u. a. Ryzen 5 5600X 358,03€)
  2. (u. a. Ryzen 7 5800X für 469€)


Haben wir etwas übersehen?

E-Mail an news@golem.de