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!

   Antworten ↓

3. Der Mann am Anfang ist übrigens John Stewart. http://de.wikipedia.org/wiki/Jon_Stewart

   Antworten ↓

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

   Antworten ↓

5. LLVM + Gallium 3D: Mixing a compiler with a graphics framework
   (Stéphane Marchesin,
   FOSDEM 2009 X.org devroom talk, summary + video recording):
   http://www.phoronix.com/scan.php?page=article&item=llvm_gallium3d&num=1

   Antworten ↓

6. Danke fuer das Thema. Gibt es eigentlich irgendwo noch weitere Informationen und evtl auch Code zu Tim Sanders arbeit.

   Antworten ↓

7. 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?

   Antworten ↓

8. 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?

   Antworten ↓

9. 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!

   Antworten ↓

10. 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 :).

    Antworten ↓

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

    Antworten ↓

12. 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.

    Antworten ↓

13. 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?

    Antworten ↓

14. @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

    Antworten ↓

15. @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

    Antworten ↓

16. @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

    Antworten ↓

17. @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

    Antworten ↓

18. 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?

    Antworten ↓

19. @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

    Antworten ↓

20. Pingback: dysternis

21. 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.

    Antworten ↓

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

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.