Also was ich vergessen habe, ja ist es tatsächlich besser, was ich vergessen habe,

was ich nicht geschafft habe, war die Hardware-Analyse. Da gehen wir wieder in den Bereich der Pessimisten.

Wir haben das ja schon mal angesprochen. Ich hatte ganz am Anfang gesagt, wir hatten diese drei Prozessoren.

Einmal diesen uralten Motorola 16-Bit, dann einen etwas moderneren Power PC und dann für damalige Verhältnisse

aktuellen Power PC, wie sie in den Macs noch verbaut wurden. Und wir haben gesehen, dass das halt wahnsinnig gestreut hat.

Also die Zeit, die der Prozessor braucht, um ganz einfache Instruktionen auszuführen zwischen wenigen Takten

und mehreren Hundert-Taktzyklen, je nachdem, was für Heuristiken, was für Mechanismen in den Prozessoren

angeschlagen sind. Und das möchte ich noch mal ganz kurz thematisieren und euch zeigen, wo da die Stolpersteine liegen.

Das ist letztendlich etwas, wo man wiederum eine eigene Vorlesung draus machen könnte.

Also es ist eine sehr, sehr komplexe Problematik, eine Problematik, die diese Hunderttausenden bis Millionen

von Euro kostet, wenn man die Werkzeuge, diese statischen Analysewerkzeuge, denn auch tatsächlich

die Designprozessorderivat anpassen möchte. Das ist also hier drin, in dieser Hardware-Analyse versteckt sich

eigentlich ein Großteil der Komplexität, die ja in dieser statischen Code-Analyse eben steckt.

Gut, trotzdem sollte man ja ungefähr verstehen, was da vor sich geht und das wollen wir uns eben anschauen.

Also hier wieder so ein ganz einfaches Beispiel. Wir haben hier eine Funktion, die uns Werte aus dem Speicher lädt.

Und wenn man da letztendlich wieder pessimistisch dran geht und einfach mal aufsummiert, was kosten mich diese Instruktionen

im schlimmsten Fall, dann in diesem einfachen Beispiel, ohne da jetzt größeren Kontext noch dazu zu geben,

wären das jetzt 80 Zyklen. Und auf diese 80 Zyklen kommt man eben immer, indem man halt diese oberen Schranken hernimmt.

Also man sagt für jede Instruktion, naja, wir gehen mal davon aus, im schlimmsten Fall dauert die so und so lange und dann summieren wir das auf.

Und das ist auch wie in dem Beispiel, das ich eingangs in dem Foliensatz verwendet habe, eigentlich relativ offensichtlich,

dass das eine sehr unbefriedigende Schranke ist, denn wir sehen hier vier Binaercode, also vier Assembly-Instruktionen,

die der Prozessor ausführen soll. Normalerweise würde man erwarten, dass das nicht länger als vier Takte dauert.

80 Takte ist also schon ziemlich, ziemlich schlecht. Gut, das heißt, das Problem an der ganzen Sache, das Problem an dieser

Hardware-Analyse und an diesem pessimistischen Abschätzen ist, dass es unfassbar pessimistisch wird, ja, bis zu dem Punkt, wo es nicht mehr verwendbar ist.

Also wir haben uns das letzte Woche mal so imaginär uns überlegt, wenn ich statt zehn Takten immer 100 Takte annehmen muss, dann habe ich eine 10-fache Überabschätzung.

Das bedeutet, ich kann meinen Prozessor im schlimmsten Fall halt nur noch zu 10 Prozent auslassen. Das widerspricht wieder dem, ja, den Wirtschaftlichkeitsaspekten,

also keine Firma wird bereit sein, Hardware zu kaufen und dann nur zu 10 Prozent auszulassen, weil das einfach viel zu teuer ist.

Das kann im Umstand sogar falsch sein, also man darf sich von dem hier nicht verleiten lassen. Wir werden das am Ende vom Semester nochmal kurz

in einer eigenen Vorlesung thematisieren, was Laufzeitanomalien sein können. Also bisher gehen wir eigentlich davon aus, dass immer, wenn wir irgendwas besser machen,

also sprich, wenn unsere Funktion kleiner wird, wenn wir weniger Instruktionen brauchen, um diese Funktionen zu implementieren, um dieselbe Funktionität zu erreichen,

dann wird auch ihr Laufzeitverhalten besser werden. In der Realität ist es aber leider nicht immer so, sondern es kann tatsächlich Fälle geben,

wo wir augenscheinlich was besser machen, was kleiner machen, was schneller machen und es in der Summe dann aber trotzdem länger braucht.

Das nennt man dann Laufzeitanomalien. Ein ganz prominentes Beispiel dafür ist halt eben die Hardware. Also wenn der Prozessor halt eine Heuristik eingebaut hat,

dann kann es durchaus sein, dass nur weil wir den Code kleiner gemacht haben, kann es eben passieren, dass die Heuristik mit diesem Code schlechter zurande kommt,

eine schlechtere Vorhersage trifft und die Ausführung dieses vermeintlich kürzeren, schnelleren Stückchen Codes einfach am Ende länger dauert.

Das wäre dann eine Laufzeitanomalie. Das heißt, was man beachten muss, ist, dass unumständlich die Summe von mehreren Instruktionen langsamer wird,

als man das aus den Einzelwerten eben ableiten würde. Gott sei Dank ist das selten der Fall.

Also Prozessoren, wie man sie in eingebetteten Systemen heutzutage einsetzt, die haben normalerweise diese Laufzeitanomalien eben nicht,

aber bei so einem Intel kann man sich eigentlich nicht sicher sein, dass auch so eine pessimistische Abschätzung, wie hier am Ende tatsächlich stimmt.

Woher kommt es? Nochmal ganz kurz, haben wir letzte Woche schon diskutiert, also sowas wie Out-of-Order-Execution, Pipelines, die Caches.

Ganz wichtige, die Hauptquelle und auch die, mit der wir uns rumschlagen müssen.

Also das ist die Quelle für Pessimismus, für Probleme in der Hardware-Analyse, die wir auch heute schon in eingebetteten Systemen haben.

Also die aktuellen Prozessor-Generationen, die von der Industrie heute eingesetzt werden, die haben Caches.

Sehr einfache Caches, meistens nur einstufig, maximal zweistufig, aber das ist letztendlich das, wo wir uns heute schon rumschlagen müssen.

Genau, und die Frage ist jetzt, wie kriegen wir das in den Griff?

Und man kriegt das in den Griff oder man kann es zumindest verbessern, indem man diesen Analysewerkzeugen halt beibringt, was die Hardware tut.

Also wenn das Analysewerkzeug weiß, wie sich die Hardware verhält, dann kann es ohne Umstände die Abschätzung halt verbessern.

Und genau das macht man mit einer Hardware-Analyse.

Wir hatten am Anfang von dem Kapitel gesagt, das teilt sich auf in diese Programmiersprache-Ebene und in die Hardware-Ebene, und jetzt sind wir eben genau auf dieser Hardware-Ebene.

Die Hardware-Analyse selbst, die kann man jetzt wieder aufteilen, die kann man integrieren in die Analyse, man kann sie separat halten, das ist quasi nicht festgeschrieben, das hängt davon ab, was der jeweilige Ansatz benutzt, was der jeweilige Hersteller von dem Tool für einen Ansatz verfolgt, aber man kann im Prinzip sagen, wir können es integrieren.