CRE114 LLVM

Die "Low Level Virtual Machine" Compiler-Infrastruktur

Episode image forCRE114 LLVM LLVM (Low Level Virtual Machine) steht für eine neue Infrastruktur für Compiler, die sich anschickt, der GNU Compiler Collection (gcc) Konkurrenz zu machen. Es stellt eine umfangreiche Modulsammlung bereit, aus der sich Entwickler bedienen können, um performante Compiler für neue oder existierende Programmiersprachen zu erzeugen. Im Gespräch mit Tim Pritlove erläutert Tim Sander von seinen Erfahrungen mit dem System. Zur Sprache kommen die Architektur der LLVM-Infrastruktur, bislang existierende Frontends und Backends, Lizenz und Anwendungsfälle von LLVM.

Dauer: 1:01:33

On Air
avatar Tim Pritlove Paypal Icon Bitcoin Icon
avatar Tim Sander
Support
avatar Max Merz
Shownotes
Shownotes:

Intro

00:00:00

Jon Stewart — CRE Intro.

Begrüßung

00:01:01

Tim ist immer noch auf Reisen — LLVM (Low Level Virtual Machine) — Tim Sander — TU Darmstadt.

Hardware Software Co-Design

00:02:01

Compiler — Bus — Multiplexer — CPU — Registersatz — Pipeline — GCC — Anwendungsfälle für Hardware Software Co-Design — Koprozessor — FPGA — Fehlertoleranz — Grundlagenforschung — Grafikkarte — Moore’s Law — Transistor — Parallelisierung.

LLVM Überblick

00:09:03

GCC — The LLVM Compiler Infrastructure — LLVM ist modular aufgebaut — Geschichte von LLVM — Lifelong Optimization — JIT-Compilation (“JITing”) — Skriptsprachen — Interpreter — Bytecode — Maschinencode — Dynamische Typisierung — Javascript — Komponenten von LLVM — llvmc (LLVM Compiler Driver).

LLVM Frontend

00:15:56

GCC-Frontend — Brainfuck — Zwischencode — Static Single Assignments — GCC hat mit Version 4 auf SSA umgestellt — Alle LLVM-Optimierungsläufe laufen auf der internen Beschreibungssprache — Parser — Java — C — C++ — Fortran — Objective-C — GPL — LLVM Lizenz — University of Illinois/NCSA Open Source License — BSD — Andere Frontends — clang (Wikipedia — Projekt-Homepage)  — Assembler.

LLVM Middleware

00:23:41

Optimierungsläufe — Dead Code elimination.

LLVM Backend

00:25:53

Beschreibung der Ziel-Maschine — Von-Neumann-Architektur — Harvard-Architektur — x86 — ADM64 — ARM — PowerPC — Vektorrechner — SIMD (Single Instruction, Multiple Data) — OpenGL — Shader — Zusammenfassung.

Vergleich zum GCC

00:30:36

Java VM — LLVM und GCC setzen auf Static Single Assignments auf — Unterschiede liegen in der Implementierung — LLVM Dokumentation — Softwarearchitektur — GCC Gimple — GCC RTL — “Gnade der späten Geburt”.

LLVM Zwischensprache

00:34:43

Die Operationen sind ähnlich zu Assembler — Register — In SSA ist jeder Datenplatz ein-eindeutig — Modulgröße im Backend — Compilezeiten — Fehlermeldungen von clang — Apple und clang — Chris Lattner — Mutmaßungen zur Strategie von Apple (Fehlermeldungen — Compilezeiten)  — JIT-Kompilierung — Zwischensprache ist sehr kompakt und kann mitgespeichert werden — Parallelisierung — Multiple Cores — SIMD (Single Instruction, Multiple Data) — Parallelisierung des Compile-Vorgangs — Parallelisierung des produzierten Codes — Flynnsche Klassifikation — AltiVec — SSE — Dynamische Typisierung — Skriptsprache — Runtime.

Praktische Anwendung

00:49:04

Wo kommt LLVM schon zum Einsatz? — Adobe Flash — LLVM Developer Meeting 2008 — Vortrag von Scott Petersen (Vortragsfolien — Video Hi — Video Lo) .

Ressourcen

00:51:58

LLVM Developer Meetings — Vortrag von Tim Sander (Vortragsfolien — Video Hi — Video Lo)  — Google Tech Talk: Chris Lattner: LLVM 2.0 — LLVM Developer Meeting 2008 — Doxygen — LLVM Doxygen Dokumentation — LLVM Online Compiler.

Für wen ist LLVM interessant?

00:54:50

Sample Frontend — Tims Optimierungslauf — Macht Spaß in der Forschung — Compilerbau — “Und dann kam die Aussage: ‘Compilerbau ist doch tot, da entwickelt sich doch nichts mehr.’” (Tim Sander) — “Und für jemanden, der Informatik studiert und noch ein schönes Diplomthema braucht wäre das dann vielleicht auch der richtige Sandkasten, in den man sich mal reinsetzt um mal ordentlich mit Sand zu werfen.” (Tim Pritlove).

Abschluss

01:00:11

CRE Outro.

22 Gedanken zu “CRE114 LLVM

  1. Pingback: zahlenzerkleinerer

  2. Ich bin hocherfreut, am Ende der Sendung zu hören, dass du noch eine Sendung zum Thema Compilerbau auf der Liste hast. In Anbetracht gegenwärtiger Studiencurricula ist mein Eindruck ähnlich dem des Gesprächspartners, in den Vorlesungsverzeichnissen vieler Hochschulen sind die letzten regelmäßigen Veranstaltungen zum Thema vor dem Jahrtausendwechsel datiert, inzwischen scheint man zu Sonderveranstaltungen übergegangen zu sein, die nicht mehr als reguläre jährlich stattfindende Veranstaltungen angeboten werden, sondern nur in manchen Jahren mal angeboten werden, wenn überhaupt. Diese Sendung dürfte ruhig ein längere werden. Sehr erfreut mich auch, dass du nochmal deine Absicht bekundest, nicht nur technische Themen behandeln zu wollen, die letzten Sendungen waren ja zumeist mehr oder minder stark software- oder kommunikationstechnisch orientiert. Vielen Dank für CRE!

  3. Interessanter erster Einblick, auch wenn man es normalerweise gewohnt ist, in einzelne Teilbereich wie clang noch wesentlich tiefer einzusteigen.

  4. Habs bis zum Schluss gehört und diesmal merkte ich, dass ich viel zu wenig Ahnung habe, um wirklich zu verstehen, um was es geht.
    Interessant fand ich, dass es bisher keine gute Lösung für viele Prozessoren gibt und dass es bisher nur schwer verständliche Fehlermeldungen gibt.
    Mich hätte noch interessiert wie das Projekt hinsichtliche eines Zeitplans zur Fertigestellung aussieht.
    Und was heißt Fertigstellung?

  5. Nur eine Stunde für dieses schöne Thema. Sehr schade.
    Mehr programming languages, mehr nerdiges filosofieren, abgefahrene Languages wie haskell, O’caml, mehr Dylan :-) na schon klar denk ich.
    warum nicht auch mal “mainframe” technologie?

  6. Von Compilerbau habe ich keine Ahnung weshalb ich beim ersten Hören auch nur wenig verstanden habe. Dann habe ich mich etwas schlauer gemacht und beim zweiten Hören ging es dann sehr gut. Mein Eindruck bei LLVM ist, dass man da beim Compilieren und beim Linken jeweils optimiert. Und das Optimieren des codes zur “run-time” finde ich auch interessant. Dann gibt es noch das Optimieren zur idle-time. Auf http://www.llvm.org/pubs/2004-01-30-CGO-LLVM.pdf heißt es dazu: “It can even reoptimize an application multiple times in response to changing usage patterns over time (or optimize differently for users with differing patterns).” Wohl weil der Zwischencode für das jeweilige Programm dem Programm-Anwender mitgegeben werden kann. Beispielsweise ein Betriebssystem das sich auf meinem Rechner ständig optimiert, faszinierend!

  7. Sehr interessant finde auch die optimierung zur install time, das programm liegt im installer als llvm code und wird dann beim installieren auf den jeweiligen Prozessor optimiert. Also quasi gentoo fuer closed source produkte :).

  8. Sehr investigativ! ;) Eine Frage hat aber noch gefehlt: Kann man eigentlich auch in diesem Zwischencode selbst Programme schreiben?

  9. Wenn der Übersetzer es kann, könnten natürlich auch von Hand Programme in Zwischencode geschrieben werden. Wem der Nerdfaktor von Java zu gering ist, schreibt seine Programme schließlich auch direkt in Bytecode.

  10. Ich hätte gerne über das Projekt, and dem Tim mit LLVM gearbeitet hat etwas mehr gehört, so dass er so richtig aus dem Nähkästchen hätte plaudern können. So musste Tim öfters sagen “ja weiss ich nicht so genau, war in meiner Arbeit nicht so Thema”.
    Aber als Überblick war’s dennoch ganz gut. Vielleicht mal noch ein Teil 2 irgenwann?

  11. @Trulli Wulli: Kann man eigentlich auch in diesem Zwischencode selbst Programme schreiben?
    Ja, das geht. Es nennt sich llvm-as. Wobei das as für Assembler steht. Wenn man sich die syntax anschauen will, kann man llvm-dis verwenden auf ein entstehenden bytecode, oder direkt auf der LLVM Webseite den Testdrive anklicken.
    Tim

  12. @cgerum: Der Code ist noch nicht öffentlich, da er leider noch nicht ganz funktionstüchtig ist. Falls jemand gesteigertes Interesse hat und nicht zu bremsen ist, kann sie/er sich ja gerne an mich wenden.

    Tim

  13. @Luz: “Ich hätte gerne über das Projekt, and dem Tim mit LLVM gearbeitet hat etwas mehr gehört, so dass er so richtig aus dem Nähkästchen hätte plaudern können.”

    Ja, dass wäre dann aber noch spezieller geworden als es eh schon war… zum anderen wollte Tim P. verständlicherweise den Fokus eher auf LLVM richten.

    Tim

  14. @cegerum: ” Also quasi gentoo fuer closed source produkte :).”

    Naja, wenn du den LLVM Bytecode hast, ist ein reverse Engeneering deutlich einfacher als mit echten Assembler. Dies liegt vor allem daran, dass LLVM auf SSA basiert und damit der Datenfluß sich ganz einfach extrahieren läßt.

    Tim

  15. Auch wenn der Gast an einigen Stellen nicht weiter wusste, habe ich trotzdem einiges dazu gelernt.
    Ist mir auf jeden Fall lieber, wenn man das dann gleich sagt, statt u.U. mit gefährlichem Halbwissen zu glänzen und Unwahrheiten zu verbreiten.

    Ich bin mir aber noch nicht sicher, ob das mit der “Virtual Machine”, die eigentlich gar keine ist, richtig bei mir angekommen ist:
    Braucht man um LLVM-Code auszuführen eine eigene Runtime-Umgebung oder Bibliotheken auf dem Systen? Ich tippe eher auf nein.
    Die Möglichkeit, zur Laufzeit Optimierungen vorzunehmen, wie in einer VM, wäre dann quasi in das Programm “mit rein kompiliert”.
    Stimmt das denn soweit?

  16. @F30:
    Die “Virtual Machine” benennung ist leicht irreführend und meines erachtens Historisch bedingt. Die zwischendarstellung des LLVM (also llvm bytecode) kann man als sehr kompakte Assemblersprache auffassenm, die auf einer ziemlich idealen Maschine mit unendlichen Registersatz läuft.

    Was das ausführen von LLVM angeht gibt es Just In Time Compile ansätze und wohl auch einen Interpreter. Die lebenslange Optimierung wir dadurch erreicht, dass nicht nur die assembly sondern auch der Bytecode zusammen gespeichert wird und damit auch im nachhinein optimiert werden kann. Das ist meines erachtens aber sehr akademisch.

    Ich hoffe das ist jetzt etwas klarer geworden.
    Tim

  17. Pingback: dysternis

  18. Hallo,

    nettes Thema.
    Soweit ich das verstanden habe nutzt also llvm statische einmal-Zuweisungen, die wohl eine “Weiterentwicklung” vom 3-Adress-Code sind,
    in dem sinne, daß man jedem Teilergebnis einen neuen Namen zuweist…
    …es also intern eigentlich nur Konstanten und keine Variablen gibt…

    …das bedeutet doch wohl, daß kurzlebige Zwischenwerte auch früh wieder “deallokiert” werden können, man also sozusagen eine “automatische Garbage-Collection” gleich mitgeliefert bekommt?

    Kann man das so zusammenfassen?

    Was runtime-optimization betrifft, erinnert mich das an FFTW,
    das macht das wohl auch, aber ob das llvm die selben Mechanismen nutzt?

    Zur Hardware-Entwicklung im Rahmen mit llvm….
    … wie wird das denn umgesetzt? Im Interview klang es so, als ob man eine weitere llvm-Optimierung startet und als Ergebnis eine bessere Hardware-Implementierung bekommt.
    Wie war das denn gemeint?

    Läuft der llvm-Code denn direkt auf der entwickelten Hardware,
    schluckt also direkt das llvm-Kompilat (llvm-machine (nicht-virtuell))?

    Oder wird das llvm-Kompilat in VHDL umkompiliert und daraus eine neue Hardware erzeugt, die dann das Programm nativ komplett in Hardware laufen lässt?

    Oder irgendwas dazwischen?

    Was die Darstellung paralleler Strukturen angeht… hmhhh
    vielleicht kann da ja auf bereits voirhandenes zurück gegriffen werden.
    Die Polykontexturalitätstheorie (PKL bzw. PCL) von Gotthard Günther, die Fortentwicklung seiner als mehrwertiger Logik angefangener Überlegungen, die kann vielleicht helfen.

    Mit ihr kann man widerspruchsfrei Paradoxien abbilden, da die Logik nicht ins Zwangskorsett einer Serialisierung gepresst wird, sondern die Zusammenhänge räumlich verteilt darstellt.

    Das heißt, das Problem der Beschreibung räumlich verteilter, paralleler Prozesse ist damit vollständig abbildbar!
    Das führt jedoch nicht zur Auflösung des Problems der Serialisierbarkeit. Manches wird sich wohl nicht serialisieren lassen, das ist ja das grundlegende der Parallelität. Aber vielleicht hilft die Darstellug mithilfe der PKL dazu, die Kluft zwischen hardware und Software zu überbrücken, bzw. Verständnislücken auszuräumen.

    Die PKL geht weit über das, was unsere heutige Hardware an Möglichkeiten bietet, hinaus. So ist damit aufzeigbar,
    wann man Parallelität in der Weise braucht, daß sie in “Nullzeit” Daten übertragen muß. Das geht zwar mit unserer heutigen Hardware nicht, aber man kann ja schon mal an Quantencomputer denken, wo dieses Problem der Lichtgeschwindigkeit als begrenzender Faktor der Ausbreitungsgeschwindigkeit wohl kein Problem mehr darstellt.

    Das heisst, die Analysewerkzeuge sind vorhanden, nur nicht weitgehend bekannt.

    Die PKL hat potentiell übrigens auch weiteren Einfluss auf die gesamte Wissenschaft, weil die PKL poly-kontextural arbeitet, die herkömmliche wissenschaft aber monokontextural. So lässt sich das System der natürlichen Zahlen durch die PKL HERLEITEN!

    Es liegt dem, was wir an Wissenschaft heutzutage als gültig ansehen, und was mit so manchen Axiomen daher kommt, noch wesentlich grundlegenderes zugrunde, als gemeinhin angenommen wird.

    Ich bin auf dem gebiet leider auch nur interessierter Laie, aber obige Aussagen habe ich machen können aufgrund Lesens einiger interessanter Texte, die man im Netz so findet. Günthers Originale habe ich mir noch nicht rein gezogen; einige seiner Schriften wurden aber vor ein paar Jahren neu aufgelegt (z.B.: G.G.: Das Bewusstysein der Maschinen).

    Weiterentwickelt wurde die PKL von Rudolf Kaehr und einigen weiteren Leuten.

    Folgendes als Lesetips:

    Introducing and Modelling Polycontextural logics:
    http://www.thinkartlab.com/pkl/tm/plisp/ENGLISH.EPS

    Erkennen und Wollen:
    http://www.vordenker.de/ggphilosophy/e_und_w.pdf

    Einschreiben in die Zulkunft:
    http://www.vordenker.de/ggphilosophy/kaehr_einschr-in-zukunft.pdf

    Weiterhin auch viele weitere Artikel auf thinkartlab.com und vordenker.de.

    Auch der die Begriffe “Morphogrammatik” und “Kenogrammatik” sind in diesem Zusammenhang wichtig, und dazu gibt es auch pdf’s im Netz.

    Nochmal zurück zu der Sendung: wie schon jemand anderes hier schrieb, fände ich weitere Compiler-Beiträge interessant, auch den Teil-2 dieser Sendung, wo der Ansatz llvm/Hardware aufgegriffen werden könnte, fände ich interesant.

    P.S.: Eine “preview”-Option auf den Feedback-Seiten wäre ganz praktikabel.

  19. Pingback: CRE122 Compilerbau und Typtheorie | CRE: Technik, Kultur, Gesellschaft

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *