Abo
  1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Freier Compiler LLVM soll…

Plattformunabhängige Binaries

  1. Thema

Neues Thema Ansicht wechseln


  1. Plattformunabhängige Binaries

    Autor: *v* 21.11.05 - 12:45

    Plattformunabhängigkeit scheint mir bei den vielen von Linux und BSD unterstützten Systemarchitekturen doch ein sehr reizvolles Thema zu sein. Die Erzeugung von Binaries mit einem virtuellen Befehlssatz in Verbindung mit einem JIT-Compiler birgt allerdings wieder potentielle Performance-Nachteile und höheren Ressourcen-Verbrauch. Damit disqualifiziert es sich schon mal für den Einsatz in sehr zentralen Anwendungen, wie z.B. X-Server oder Desktop-Umgebung.
    Daher eine vielleicht dumme Idee:
    Wäre es nicht denkbar Pakete mit dem virtuellem Befehlsatz (plattformunabhängig) auszuliefern) und die Anpassung auf die eigene Plattform anstatt von einem JIT-Compiler von einer Komponente des Paketmanagers (rpm, dpkg etc.) übernehmen zu lassen. Also ein schneller Compiler während der Installation. Das sollte sehr viel schneller und einfacher zu machen sein, als die direkte Installation à la Gentoo (oder ähnliche Projekte). Andererseits würde es die ständige Neucompilierung während der Laufzeit à la Java überflüssig machen.
    Aber vielleicht ja nur eine dumme Idee von jemandem, der zu wenig Ahnung hat...

    *v*
    ( )
    "="===============================================
    two and two is five - for very large values of two

  2. Re: Plattformunabhängige Binaries

    Autor: chr1701 21.11.05 - 13:08

    Wäre sicher möglich. aber im endeffekt ist das ja auch ein JIT-compiler. normalerweise übersetzt der JIT-compiler den bytecode in maschinencode, und zwar vor der programmausführung. Dein Vorschlag macht die übersetzung halt schon früher, bei der Installation. Sonst ist es nix neues :)

    Andererseits hat ein Bytecode viele Vorteile, vor allem zum Debuggen. Und der Geschwindigkeitsunterschied fällt heutzutage nur noch sehr selten ins Gewicht - höchstens bei wissenschaftlichen Anwendungen oder Server-Prozessen, die im hintergrund laufen und möglichst wenig Ressourcen verbrauchen sollen.

    grüsse
    chris

  3. Re: Plattformunabhängige Binaries

    Autor: Slark 21.11.05 - 13:38

    Das ist gar nicht dumm und wird auch schon gemacht (wobei ich nicht weiß, ob man das im Zusammenhang mit LLVM auch schon gemacht hat). In der Windowswelt dürfte wohl C#(/CIL) das prominenteste Beispiel sein, bei dem dies während der Installation möglich ist.

    Ich wäre auf jedenfall daran interessiert, dass man so etwas ermöglicht. Ob es nun über CIL oder LLVM geht, ist mir relativ egal, da ich nicht weiß welche der beiden Techniken für mich die bessere wäre.

    Was mich aber wirklich geschockt hat, ist das ersetzen vom Tree-SSA-Optimizer. Ich hoffe nur, dass wirklich nur der Optimizer und nicht die ganze Tree-SSA Darstellung ersetzt wird. Vielleicht meinte man ja auch nur den Teil, der direkt architekturspezifisch Optimiert (zum Beispiel Vektorisierung, etc.).

  4. Re: Plattformunabhängige Binaries

    Autor: erwin 21.11.05 - 15:09

    chr1701 schrieb:
    -------------------------------------------------------
    > Wäre sicher möglich. aber im endeffekt ist das ja
    > auch ein JIT-compiler. normalerweise übersetzt der
    > JIT-compiler den bytecode in maschinencode, und
    > zwar vor der programmausführung. Dein Vorschlag
    > macht die übersetzung halt schon früher, bei der
    > Installation. Sonst ist es nix neues :)

    Nicht ganz, was du jetzt meinst ist ein AOT(ahead-of-time)-Compiler. Ein JITter übersetzt es immer noch während der Ausführung, also just-in-time. Aber ansonsten wäre es trotzdem ein brauchbare Lösung. Durch den Byte-Code würden die Applikationen dann auch wesentlich kleiner ausfallen.

  5. Re: Plattformunabhängige Binaries

    Autor: *v* 21.11.05 - 17:36

    chr1701 schrieb:
    -------------------------------------------------------
    > Wäre sicher möglich. aber im endeffekt ist das ja
    > auch ein JIT-compiler. normalerweise übersetzt der
    > JIT-compiler den bytecode in maschinencode, und
    > zwar vor der programmausführung. Dein Vorschlag
    > macht die übersetzung halt schon früher, bei der
    > Installation. Sonst ist es nix neues :)

    Nicht nur frueher, sondern auch nur ein einziges Mal. Und man braeuchte keine parallel laufende VM.

    > Andererseits hat ein Bytecode viele Vorteile, vor
    > allem zum Debuggen. Und der
    > Geschwindigkeitsunterschied fällt heutzutage nur
    > noch sehr selten ins Gewicht - höchstens bei
    > wissenschaftlichen Anwendungen oder
    > Server-Prozessen, die im hintergrund laufen und
    > möglichst wenig Ressourcen verbrauchen sollen.

    Fuer einzelne Anwendungen ist Bytecode + JIT-Compiler sicherlich O.K. Wollte man das allerdings zum allgemeinen Prinzip der Paketinstallation erheben, also auch fuer Systemkomponenten, evtl. auch fuer den Kernel selbst (bei Kernel-Updates), dann sollte man das vielleicht nicht unbedingt ueber eine Software-VM machen.



  6. Re: Plattformunabhängige Binaries

    Autor: Tropper 21.11.05 - 20:50

    erwin schrieb:
    -------------------------------------------------------
    > chr1701 schrieb:
    > --------------------------------------------------
    > -----
    > > Wäre sicher möglich. aber im endeffekt ist
    > das ja
    > auch ein JIT-compiler. normalerweise
    > übersetzt der
    > JIT-compiler den bytecode in
    > maschinencode, und
    > zwar vor der
    > programmausführung. Dein Vorschlag
    > macht die
    > übersetzung halt schon früher, bei der
    >
    > Installation. Sonst ist es nix neues :)
    >
    > Nicht ganz, was du jetzt meinst ist ein
    > AOT(ahead-of-time)-Compiler. Ein JITter übersetzt
    > es immer noch während der Ausführung, also
    > just-in-time. Aber ansonsten wäre es trotzdem ein
    > brauchbare Lösung. Durch den Byte-Code würden die
    > Applikationen dann auch wesentlich kleiner
    > ausfallen.

    Um mal bei den dummen Fragen zu bleiben, ich hab mich mal gefragt warum Java nicht (wenn auch nur optional) einen Mechanismus verwendet mit dem die Ergebnisse des JIT-Compiler gespeichert werden. So das er einmal kompilierten Code beim nächsten Start einfach von der Platte laden kann. Ich hab zwar keine Ahnung wieviel Zeit für den JIT-Compiler wirklich draufgeht, aber ich stell mir das beim 2. Start halt doch einen Tick schneller vor.

    Es müßte dann natürlich eine Art temporären Cache geben in dem die "wirklich" kompilierten Planttformanhägigen Binärie-Class Dateien liegen so das die Leute beim Kopieren nur die Plattform unabhängigen .class Dateien weiter geben und nicht die echten Binäries. Und ich muss die Möglichkeit haben den Cache expliziet zu löschen bzw. ich muss ein maximum an Plattenplatz bestimmen können den er verwendet und bei erreichen halt ältere Binäries die ich nicht so oft verwende löschen um Platz für neue Binarier zu erstellen.

    Tropper




    1 mal bearbeitet, zuletzt am 21.11.05 20:52 durch Tropper.

  7. Re: Plattformunabhängige Binaries

    Autor: firedancer 23.11.05 - 02:48

    *v* schrieb:
    -------------------------------------------------------
    > Plattformunabhängigkeit scheint mir bei den vielen
    > von Linux und BSD unterstützten
    > Systemarchitekturen doch ein sehr reizvolles Thema
    > zu sein. Die Erzeugung von Binaries mit einem
    > virtuellen Befehlssatz in Verbindung mit einem
    > JIT-Compiler birgt allerdings wieder potentielle
    > Performance-Nachteile und höheren
    > Ressourcen-Verbrauch.

    Tja. Gleichzeitig bringt er potentielle Performance-Vorteile, da der Bytecode prozessoroptimiert übersetzt werden kann. Dieser dürfte dann um etliches schneller laufen als Standard-Binaries.

    Ist in jedem Fall eine interessante Technik. Die Frage ist nur, ob Gentoo sowas nicht vollkommen obsolet macht ;-))))))))

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Fraunhofer-Institut für Arbeitswirtschaft und Organisation IAO, Esslingen am Neckar
  2. INTENSE AG, Würzburg, Köln, Saarbrücken
  3. Dataport, verschiedene Standorte
  4. Statistisches Bundesamt, Wiesbaden

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 69,99€ (Release am 25. Oktober)
  2. (-12%) 52,99€
  3. 4,99€
  4. 4,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Cyberangriffe: Attribution ist wie ein Indizienprozess
Cyberangriffe
Attribution ist wie ein Indizienprozess

Russland hat den Bundestag gehackt! China wollte die Bayer AG ausspionieren! Bei großen Hackerangriffen ist oft der Fingerzeig auf den mutmaßlichen Täter nicht weit. Knallharte Beweise dafür gibt es selten, Hinweise sind aber kaum zu vermeiden.
Von Anna Biselli

  1. Double Dragon APT41 soll für Staat und eigenen Geldbeutel hacken
  2. Internet of Things Neue Angriffe der Hackergruppe Fancy Bear
  3. IT-Security Hoodie-Klischeebilder sollen durch Wettbewerb verschwinden

Rabbids Coding angespielt: Hasenprogrammierung für Einsteiger
Rabbids Coding angespielt
Hasenprogrammierung für Einsteiger

Erst ein paar einfache Anweisungen, dann folgen Optimierungen: Mit dem kostenlos erhältlichen PC-Lernspiel Rabbids Coding von Ubisoft können Jugendliche und Erwachsene ein bisschen über Programmierung lernen und viel Spaß haben.
Von Peter Steinlechner

  1. Transport Fever 2 angespielt Wachstum ist doch nicht alles
  2. Mordhau angespielt Die mit dem Schwertknauf zuschlagen
  3. Bus Simulator angespielt Zwischen Bodenschwelle und Haltestelle

Internetprovider: P(y)ures Chaos
Internetprovider
P(y)ures Chaos

95 Prozent der Kunden des Internetproviders Pyur bewerten die Leistung auf renommierten Bewertungsportalen mit der Schulnote 6. Ein Negativrekord in der Branche. Was steckt hinter der desaströsen Kunden(un)zufriedenheit bei der Marke von Tele Columbus? Ein Selbstversuch.
Ein Erfahrungsbericht von Tarik Ahmia

  1. Bundesnetzagentur Nur 13 Prozent bekommen im Festnetz die volle Datenrate

  1. Arbeitsspeicher: Gskill bringt DDR4-4000 mit scharfer CL15-Latenz
    Arbeitsspeicher
    Gskill bringt DDR4-4000 mit scharfer CL15-Latenz

    Hoher Takt und niedrige Latenz: Von Gskill kommt eine optimierte Version des Trident Z mit DDR4-4000 und CL15-16-16-18. Der Speicher eignet sich für schnelle CPUs wie den Core-i9-9900K oder den Ryzen 9 3900X.

  2. Mailinglisten: Yahoo Groups wird deutlich eingeschränkt
    Mailinglisten
    Yahoo Groups wird deutlich eingeschränkt

    Mit kurzer Vorwarnzeit wird der Service Yahoo Groups massiv eingeschränkt. Bald können keine neuen Dateien mehr hochgeladen werden, bestehende Daten werden größtenteils im Dezember gelöscht.

  3. Hyperloop: rLoop kauft Reste von Arrivo
    Hyperloop
    rLoop kauft Reste von Arrivo

    Im Dezember vergangenen Jahres hat das Hyperloop-Unternehmen Arrivo Insolvenz angemeldet. Das Startup rLoop hat das geistige Eigentum übernommen und will die Projekte weiterführen.


  1. 15:56

  2. 15:29

  3. 14:36

  4. 13:58

  5. 12:57

  6. 12:35

  7. 12:03

  8. 11:50