PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : OS X Anwendungen "bald" ByteCode?


Ganon
2005-11-23, 22:07:51
Hi.

Ausgehend von dieser Meldung:

http://www.heise.de/newsticker/meldung/66556

Was meint ihr dazu? Würde so etwas gut gehen? Anscheinend scheint Apple das Projekt ja gut zu unterstützen.

Apple scheint ja JIT-Compiler zu mögen, was man ja auch schon an CoreImage sieht.

Halbwegs schnell scheint es auch zu sein:

The project is in early stages of development, but code performance and compile times are currently comparable to an unmodified GCC compiler on PowerPC.

Coda
2005-11-23, 22:19:18
Bei Java/C# und Konsorten ist ja nicht der Bytecode "langsam" (jaja) sondern der GC und das "Management" (Speicherbereichsüberprüfung etc.) sonst.

Wenn man den Output des Compilerfrontends nimmt und ihn erst auf der Architektur kompiliert auf dem das Program laufen soll spricht nichts dagegen dass es exakt gleich schnell ist.

Demirug
2005-11-23, 23:33:29
Bei Java/C# und Konsorten ist ja nicht der Bytecode "langsam" (jaja) sondern der GC und das "Management" (Speicherbereichsüberprüfung etc.) sonst.

Ein GC kann schneller als ein typischer Heapmanager sein. Auch das mit den Speicherbereichsüberprüfungen hält sich eigentlich in Grenzen weil man diese ja inzwischen auch in C/C++ Programme von Compiler einbauen lässt.

Im wesentlichen ist es das Problem das ein Jitter weniger Zeit hat zum Optimieren als ein Compiler.

Ganon
2005-11-24, 09:59:02
Im wesentlichen ist es das Problem das ein Jitter weniger Zeit hat zum Optimieren als ein Compiler.

Wobei aber bei einem Betriebssystem doch eher wenig Compilerseitig "optimiert" wird, oder? Da kann ein JIT zur Laufzeit doch sicherlich besser arbeiten (bzw. mehr für die CPU optimieren), als ein Compiler.

Oder es gibt sowas wie "Compile on Install", oder so.

Demirug
2005-11-24, 10:01:46
Wobei aber bei einem Betriebssystem doch eher wenig "optimiert" wird, oder? Da kann ein JIT zur Laufzeit doch sicherlich besser arbeiten, als ein Compiler.

Wieso sollte man bei einem Betriebssystem die Compileroptimierungen deaktivieren?

Ganon
2005-11-24, 10:05:29
Wieso sollte man bei einem Betriebssystem die Compileroptimierungen deaktivieren?

Ich meinte ja nicht die Standard-Optimierungen, sondern eher die CPU-spezifischen (SIMD, etc.).

maz
2006-01-17, 23:15:38
die frage ist was will apple damit machen?
nur den umstieg auf x86 vereinfachen - dafür gibt es ja schon die universal binaries und alles rundherrum

oder will man früher oder später dazu übergehen osx plattformunabhängig zu machen, um es auch von eigener hardware zu "entkoppeln"

spricht gegen apples philosophie, ist sehr riskant und eine one-way lösung ohne einen rückweg - es spricht aber auch einiges dafür

mehr gehirnwichsere morgen - geh jetzt schlafen....

Coda
2006-01-18, 00:45:27
Ich meinte ja nicht die Standard-Optimierungen, sondern eher die CPU-spezifischen (SIMD, etc.).Es gibt in einem Kernel glaube ich kaum Dinge für die SIMD verwendbar wäre, zudem ist ein Jitter da vor allem sehr problematisch, weil dafür ganz schön viel Compilerleistung vollbracht werden muss um Autovektorisierung zu ermöglich.

Ganon
2006-01-18, 13:57:23
Es gibt in einem Kernel glaube ich kaum Dinge für die SIMD verwendbar wäre, zudem ist ein Jitter da vor allem sehr problematisch, weil dafür ganz schön viel Compilerleistung vollbracht werden muss um Autovektorisierung zu ermöglich.

Naja. Muss ja nicht der Kernel sein, das dann besser optimiert ist. Können ja auch Systembibliotheken sein.

Liegt nun je nachdem wie man die SIMD-Einheit anspricht. Ob man quasi in dem ByteCode Segmente drinnen hat die man als SIMD-fähig kennzeichnet und der JITter denn, je nachdem, SSE, Altivec oder FPU-Code daraus macht.

Wäre eine Möglichkeit. Weiß jetzt nicht ob LLVM das bietet (denke mal nicht). Wie bei CoreImage unter OS X. Klar, das sind reine Bildverarbeitungs-Routinen. Das ist schon was anderes. Dort ist es dann leicht, FPU, Altivec, SSE oder OpenGL2-Shader zu erzeugen...

Wäre halt schön wenn man plattformunabhängigen, aber doch recht optimierten Code auf Compilier-Niveau hat.

Coda
2006-01-18, 16:54:28
Die Startup-Time ist halt schon deutlich höher. Intermediate->Native Code enthält einige Optimierungsschritt. Ich denke dass ist das Hauptproblem.

HellHorse
2006-01-18, 18:27:35
Ein GC kann schneller als ein typischer Heapmanager sein.
Paar Links, dazu:
http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html
http://www-128.ibm.com/developerworks/java/library/j-jtp10185/?ca=dgr-lnxw01Mustang-SO
Im wesentlichen ist es das Problem das ein Jitter weniger Zeit hat zum Optimieren als ein Compiler.
Man sollte einfach einen den Output speichern können, dann wär das kein Problem. Warum nicht einfach den JIT in einem eigenen Thread laufen lassen (wie die Server-VM), schon darf es länger gehen und man hat Verwendung für die zweite CPU ;) Auch sollte die Repräsentation nicht zu low-level sein (nicht so wie Java), denn um hochoptimierte Compilation zu machen muss man sonst decompilieren, was teuer ist.
Auch das mit den Speicherbereichsüberprüfungen hält sich eigentlich in Grenzen weil man diese ja inzwischen auch in C/C++ Programme von Compiler einbauen lässt.
Was man schon von Anfgang an hätte tun sollen. Aber C/C++ Programmierer wissen ja was sie machen, darum ist ja auch so gut wie kein C++ Programm anfällig für Bufferoverflows :rolleyes:

GCJ erlaubt ja explizit den Array-range-check für Java abzuschalten. Laut einem Classpath Mitglied bringt das etwa 2% Mehrleistung. Wenn man bedenkt, dass 50% aller Sichterheitslücken Bufferoverflows sind, ist die Entscheidung klar.

Die Startup-Time ist halt schon deutlich höher.
Bei der Client-VM ist der Anteil des JIT an der Startup-Time minimal.

So wie ich das verstanden habe, will man damit nicht so was wie die JVM nachbauen, sondern es geht mehr darum GCC `besser' zu machen. Daran kann Apple nur interessiert sein.

Und das ganze ist aaaaaaalt (http://www.osnews.com/story.php?news_id=12715)

Gast
2006-01-18, 20:49:35
@Hellhorse

Ich glaube nicht, dass Demirug explizit von der JAVA VM Gesprochen hat und bei der .NET VM z.B. gibt es keine Unterscheidung zw. Client oder Server VM.
Wie das mit dem extra Thread zum Jitten laufen soll, ist mir momentan nicht so klar. Das ganze soll ja eben Just in Time gejittet werden, da könnte man vielleicht einiges im Voraus nebenbei jitten (weiß nicht, wie das genau gehandhabt wird), aber das ändert trotzdem nichts, dass der Code, der eben gerade ausgeführt werden soll auch gejittet werden muss. Da kann ich nichts parallel machen.

Ganon
2006-01-18, 20:55:31
Und das ganze ist aaaaaaalt (http://www.osnews.com/story.php?news_id=12715)

Jetzt guck mal auf das Datum des Threads. ;)

HellHorse
2006-01-19, 00:05:39
Ich glaube nicht, dass Demirug explizit von der JAVA VM Gesprochen hat und bei der .NET VM z.B. gibt es keine Unterscheidung zw. Client oder Server VM.
Finde ich nicht so toll, C2 macht tradoffs die auf dem Server Sinn machen, auf dem Client aber nicht. Umgekehrtes gilt für C1.

Wie das mit dem extra Thread zum Jitten laufen soll, ist mir momentan nicht so klar. Das ganze soll ja eben Just in Time gejittet werden, da könnte man vielleicht einiges im Voraus nebenbei jitten (weiß nicht, wie das genau gehandhabt wird), aber das ändert trotzdem nichts, dass der Code, der eben gerade ausgeführt werden soll auch gejittet werden muss. Da kann ich nichts parallel machen.
Ein JIT compiliert bei Weiten nicht alles. Bloss ein kleiner Bruchteil des Codes, hotspots eben. Wenn also z.B. eine Methode 10'000 mal interpretiert wurde und die VM meint, es an der Zeit die mal durch den JIT zu jagen, macht man anstatt das man die Ausführung unterbricht bis sie gejitet ist einen Job in einem Threadpool sobald auf, der wenn er fertig ist, die gejitete Methode installiert.

Demirug
2006-01-19, 06:23:40
Ein JIT compiliert bei Weiten nicht alles. Bloss ein kleiner Bruchteil des Codes, hotspots eben. Wenn also z.B. eine Methode 10'000 mal interpretiert wurde und die VM meint, es an der Zeit die mal durch den JIT zu jagen, macht man anstatt das man die Ausführung unterbricht bis sie gejitet ist einen Job in einem Threadpool sobald auf, der wenn er fertig ist, die gejitete Methode installiert.

Bei .Net wird zwingend alles compiliert. Das Design sah dort niemals ein interpretieren vor.

Gast
2006-01-19, 08:20:20
Bei .Net wird zwingend alles compiliert. Das Design sah dort niemals ein interpretieren vor.

Eben. Imo werden die Framework Assemblies bei der Installation des Frameworks auch schon gejittet und somit liegt auf jeden Rechner mit .NET Framework auch die nativen Images der Framework Assemblies. Könnte ein Grund sein, warum mir subjektiv .NET Apps immer noch schneller vorkommen.

Demirug
2006-01-19, 08:29:55
Eben. Imo werden die Framework Assemblies bei der Installation des Frameworks auch schon gejittet und somit liegt auf jeden Rechner mit .NET Framework auch die nativen Images der Framework Assemblies. Könnte ein Grund sein, warum mir subjektiv .NET Apps immer noch schneller vorkommen.

Ja der Framework wird zu großen teilen pregejittet. Zum Framework gehört auch ein Programm mit dem man zusätzlich noch andere Assemblies prejitten kann. Beim 2.0 Framework erledigt das jetzt ein Service im Hintergrund. Allerdings ist das mit vorsicht zu genissen weil durch das prejitten ein paar optimierungen nicht mehr funktionieren. Wobei das im 2.0 Framework auch besser geworden ist.

HellHorse
2006-01-19, 09:51:34
Bei .Net wird zwingend alles compiliert. Das Design sah dort niemals ein interpretieren vor.
Was ja dann ein "Problem" von .Net und nicht JITs im allgemeinen ist. Wobei sich hier die Frage stellt, ob man das noch als JIT bezeichnen will.

grakaman
2006-01-19, 10:03:12
Was ja dann ein "Problem" von .Net und nicht JITs im allgemeinen ist. Wobei sich hier die Frage stellt, ob man das noch als JIT bezeichnen will.

Wieso soll das kein JIT sein? Die prekompilierten Framework Assemblies sind doch vollkommen unabhängig von der Tatsache, dass .NET Programme i.d.R. zur Laufzeit gejittet und kompiliert werden (außer wenn man mit ngen das explizit umgehen will) und nicht interpretiert werden. Schreibt denn ein Jitter interpretieren vor? Bzw. wieso soll das so überaus intelligent sein, wenn man laut deinem Bsp. 1000 mal den selben Code interpretiert, bis dann die VM mal auf den Trichter kommt, das ganze dann doch zu kompilieren und anschließend auf das Kompilat zuzugreifen?

edit:

Hellhorse, jetzt ist mir klar, wie du das meinst ;) Nun stellt sich allerdings für mich die Frage, ob der extra HotSpot Thread wirklich erst nach deutlich mehrfach wiederholten Ausführen des selben Code zum Schluss kommt, diesen zu analysieren und zu kompilieren. Denn das erscheint mir ja eher mehr als eine Ad hoc Lösung auf die zuvor früheren interpretierten Java VM's. Allerdings kenne ich mich mit der Java VM überhaupt nicht aus, so dass die Vermutung auch falsch sein kann. Aber deine HotSpots setzen ja dann trotzdem immer einen Interpreter voraus, nicht? Ich könnte mir jetzt vorstellen, dass das bei Multi Core Prozessoren vielleicht gar nicht mal so schlecht ist, aber ist das auch bei Single Core so?! Wahrscheinlich ist das Situationsabhängig. Nicht zuletzt bleibt die Frage, ob die Java VM den nativen Code, der von den Hotspots generiert wurde, auch speichern kann, so dass nach einem Neustart des Programms gleich der native Code verwendet wurde. Bei .NET 1.0/1.1 ist das IMO so, die natives Images gehen da nur erst wieder bei einem Reboot verloren (oder wenn man das Programm auf einen anderen Rechner kopiert). Daher auch gleich mal die Frage an Demirug, wie das beim 2.0er Framework gelöst ist.

Gruß,
grakaman

HellHorse
2006-01-19, 12:28:15
Wieso soll das kein JIT sein?
Wie du erkannt hast, ging es bloss um die Begrifflichkeit von wegen `just in time'.
Bzw. wieso soll das so überaus intelligent sein, wenn man laut deinem Bsp. 1000 mal den selben Code interpretiert, bis dann die VM mal auf den Trichter kommt, das ganze dann doch zu kompilieren und anschließend auf das Kompilat zuzugreifen?
Naja, überaus intelligent vielleicht nicht. Das Problem ist halt einfach, das JITen teuer ist. Wenn du es zur Laufzeit machen musst kann interpretieren schon Sinn machen, solange es weniger Zeit beansprucht als JITen + ausführen von nativen Code. Zudem sind ja gerade die `guten' Optimierungen besonders teuer.

Interpretieren selbst muss ja nicht zwangläufig unterirdisch langsam sein. OpenCroquet (http://www.opencroquet.org/) ist z.B. komplett interpretiert.
Nun stellt sich allerdings für mich die Frage, ob der extra HotSpot Thread wirklich erst nach deutlich mehrfach wiederholten Ausführen des selben Code zum Schluss kommt, diesen zu analysieren und zu kompilieren.
Afaik ja.
Denn das erscheint mir ja eher mehr als eine Ad hoc Lösung auf die zuvor früheren interpretierten Java VM's. Allerdings kenne ich mich mit der Java VM überhaupt nicht aus, so dass die Vermutung auch falsch sein kann. Aber deine HotSpots setzen ja dann trotzdem immer einen Interpreter voraus, nicht?
Die JVM kommt mit einem Interpreter. Der JIT lässt sich komplett abschalten.
Ich könnte mir jetzt vorstellen, dass das bei Multi Core Prozessoren vielleicht gar nicht mal so schlecht ist, aber ist das auch bei Single Core so?! Wahrscheinlich ist das Situationsabhängig.
Vermutlich. Ich meinte mal in einem Chagelog gelesen zu haben, dass es die Client VM nur macht, falls sie eine zweite CPU findet.
Nicht zuletzt bleibt die Frage, ob die Java VM den nativen Code, der von den Hotspots generiert wurde, auch speichern kann, so dass nach einem Neustart des Programms gleich der native Code verwendet wurde.
Der geht verloren, das ist schlecht keine Frage.

Ganon
2006-04-21, 12:52:06
Anscheinend geht es gut voran:

http://www.golem.de/0604/44829.html

Ganon
2006-09-03, 21:40:25
So. Mal den alten Thread rauskramen.

http://lists.cs.uiuc.edu/pipermail/llvmdev/2006-August/006492.html
oder
http://arstechnica.com/staff/fatbits.ars/2006/8/22/5075

LLVM wird im OpenGL-Stack von Leopard verwendet, wenn die Grafik-Hardware Funktionen nicht unterstützt.

Demogod
2006-09-21, 00:53:45
hätt ich mal apple aktien gekauft als ich wollte.. :D

ohne scheiss ich bin echt mal heftigst gespannt was apple entwickelt um ms einfach WEGZUBURNEN.

greetz

Gast
2009-01-12, 14:36:52
A cool use of LLVM at Apple: the OpenGL stack: http://lists.cs.uiuc.edu/pipermail/llvmdev/2006-August/006492.html

Wäre es möglich und würde es Sinn ergeben, eine CPU zu entwickeln, die so etwas wie LLVM IR direkt verarbeitet?

Gast
2009-09-01, 11:08:01
LLVM and Clang
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/9

Gast
2009-09-13, 14:38:39
Ganz interessant zu Clang: http://iphonedevelopertips.com/xcode/static-code-analysis-clang-and-x%0Acode-3-2.html

Gast
2009-09-16, 21:50:15
Ein GC kann schneller als ein typischer Heapmanager sein. in hypothetischen faellen.
auch die magie des GC der als extra thread auf einem ungenutzten core laeuft ist eine milchmaenchenrechnung (das kommt sicher bald als argument).