Wie kann eigentlich Froyo so viel schneller sein als Eclair??

[protagonist]

Hmm...
Also ich würde das so erklären.
Bei Programmiersprachen wie C oder C++ wird der Programmcode,
wie oben schon erwähnt, direkt in für den Prozessor verständliche Anweisungen übersetzt (Binärcode).

Die meiste Software für Android wird aber wahrscheinlich in Java geschrieben sein (allerdings ist Java unter Android noch was anderes als Java von Sun/Oracle auf einem PC).
Der Javacode wird auch compiliert bevor man eine Anwendung hat, allerdings in so genannten Bytecode (eine Art Zwischecode), welcher dann wenn das Programm gestartet wird erst durch die so genannte "Virtuelle Maschine" in für den Prozessor verständlichen Binärcode übersetzt wird.

So. Jetzt kommt der große Trick an der Sache. Ein JIT-Compiler übersetzt quasi nur nach "Bedarf" den Programmcode für den Prozessor und das bringt erhebliche Geschwindigkeits-Gewinne.

 

[fexpop]

Der Javacode wird auch compiliert bevor man eine Anwendung hat, allerdings in so genannten Bytecode (eine Art Zwischecode), welcher dann wenn das Programm gestartet wird erst durch die so genannte "Virtuelle Maschine" in für den Prozessor verständlichen Binärcode übersetzt wird.

Hmm, so stimmt's eigentlich nicht. Virtuelle Maschinen ohne JIT-Compiler übersetzen eben nicht mehr in Maschinencode, sonder rufen nur noch entsprechende Routinen auf.

So. Jetzt kommt der große Trick an der Sache. Ein JIT-Compiler übersetzt quasi nur nach "Bedarf" den Programmcode für den Prozessor und das bringt erhebliche Geschwindigkeits-Gewinne.

Nein, der Trick ist, dass mit einem JIT-Compiler überhaupt Maschinencode erzeugt wird, und zwar "gerade rechtzeitig" vor der Ausführung. Das ergibt dann gerade bei großen Schleifen z. T. erhebliche Vorteile (was auch erklärt, weshalb Linpack so enorm profitiert).

Als Beispiel nimm mal so etwas:

int res = 0;
for (int i = 0; i < 100000; ++i) {
   res = i;
}

Ohne JIT-Compiler wird 100000-mal die Variable i um den Wert 1 erhöht und der jeweils aktuelle Wert der Variablen res zugewiesen.

Ein JIT-Compiler kann erkennen, dass einfach der Variablen res der Wert 99999 zugewiesen wird. Je umfangreicher die in der Schleife zu erledigenden Aufgaben sind, umso positiver macht sich ein JIT-Compiler in der Regel bemerkbar.

(Das Verhalten real existierender VMs und JIT-Compiler kann abweichen...)

Interessant ist der Vergleich mit Matlab, einem Numerik-Werkzeug:

Das Fehlen eines JIT-compilers wurde für Dalvik früher damit begründet, dass das Android API im wesentlichen native Bibliotheken a la JNI aufruft. Diese seien ja schon schnell.

Ähnlich hat Matlab im Wesentlichen hocheffiziente Routinen aus diversen Numerikbibliotheken aufgerufen (Lapack, BLAS etc.). Sofern man den eigenen Code ordentlich vektorisiert hatte, lief alles sehr schnell. Sobald man Schleifen benutzt hat, wurd's kritisch. Seit geraumer Zeit verfügt Matlab aber auch über einen JIT-Compiler, der dort eigentlich nur Schleifen beschleunigt.

Also, meine Vermutung: An vielen Stellen wird man den JIT-compiler von Android 2.2 gar nicht bemerken.

Grüße,

Felix

 

[Marauder]

Ich schließ mich der sehr schönen JIT-Erklärung von fexpop mal an.

Anwendungen, die bereits sehr optimiert sind bzw. direkt in C/C++ geschrieben (wie z.B. die Sense Oberfläche) werden vom JIT nicht profitieren.

Theoretisch sind sogar Szenarien vorstellbar, in denen der JIT kontraproduktiv ist und selber für das Kompilieren mehr Zeit oder Energie verbraucht als die kompilierte Anwendung dann einspart.
Das ist mit ein Grund, warum für die Dalvik-Engine so lange ein spezieller JIT entwickelt wurde (und nicht einfach ein Desktop-Java-JIT genommen wurde)... gerade das Thema Energieeffizient spielt halt bei einem Smartphone ne große Rolle.

Da aber der 08/15-App Entwickler eher weniger hochoptimierte Anwendungen schreibt, sondern eher auf Features achten wird dürfte der JIT bei den Apps recht erfolgreich optimieren.

 

[protagonist]

Hmm, so stimmt's eigentlich nicht. Virtuelle Maschinen ohne JIT-Compiler übersetzen eben nicht mehr in Maschinencode, sonder rufen nur noch entsprechende Routinen auf.

Moment, hinterher (aus der VM) kommt immer Maschinencode (Binärcode) heraus sonst läufts ja nicht auf dem Prozessor.
Der Programmierte Javacode wird immer erst in Bytecode übersetzt bevor das Programm überhaupt auf dem Handy landet.

Der Unterschied zwischen JIT und "nicht JIT" besteht doch nur darin ,was von dem Bytecode (Zwischencode) wann und wie in Binärcode für die CPU übersetzt wird.
Der JIT optimiert also dynamisch "zur Laufzeit" des Programmes den Bytecode.
Also kann er auch so, das von Dir beschriebene Problem besser lösen.

Das Fehlen eines JIT-compilers wurde für Dalvik früher damit begründet, dass das Android API im wesentlichen native Bibliotheken a la JNI aufruft. Diese seien ja schon schnell.

Ist ja auch ein schlagkräftiges Argument. Wenn im Hintergrund halt quasi eh schon teilweise Maschinencode genutzt wird, gehts kaum noch schneller.

Anwendungen, die bereits sehr optimiert sind bzw. direkt in C/C++ geschrieben (wie z.B. die Sense Oberfläche) werden vom JIT nicht profitieren.

Logisch. Alles was mit dem NDK programmiert ist profitiert null davon.

Also, meine Vermutung: An vielen Stellen wird man den JIT-compiler von Android 2.2 gar nicht bemerken.

Der JIT ist irgendwie auch sowas wie der Heilige Gral der Java-Leute. Insofern hast Du mit Sicherheit Recht wenn du sagst, dieses Feature sollte man nicht überbewerten.
Außerdem ist das Desire ja eh schon ein recht fixes Gerät.
Da lautet die Frage doch schon eher: "Merke ich überhaupt ob das Programm jetzt zwei mal schneller läuft?"

 

[androidin]

Also durch entsprechende Compiler-Optimierungen kann ich mir schon gut vorstellen, mal 5-10% rauszuholen, aber 200-400%, Hmmm. Naja, wir werden sehen. Wenn wirklich der Code optimiert wird und dadurch schneller wird,so bedeutet dies einen geringeren Akkuverbrauch, denn die Frequenz des Prozessors bleibt ja gleich. Da bin ich mal gespannt.

 

[fexpop]

Moment, hinterher (aus der VM) kommt immer Maschinencode (Binärcode) heraus sonst läufts ja nicht auf dem Prozessor.

Ohne JIT-Compiler läuft die VM quasi wie ein Interpreter: Es wird also aus dem Bytecode nicht noch einmal Maschinencode erzeugt, sondern es werden dem Bytecode entsprechend direkt Funktionen der VM aufgerufen.


Grüße,

Felix

 

[protagonist]

Ja damit hast du natürlich Recht.
Der Ablauf ist also Quellcode -> Java-Compiler -> Bytecode -> Class-Loader/Bytecode-Verifier -> JVM oder JIT -> System

Wie sieht das denn dann aus?
Müsste das mit JIT nicht immens viel schneller sein?

Hab neulich mal nen Podcast gehört wo ein Android-Entwickler meinte, dass wenn man in einer Schleife eine Variable anlegt, der Garbage-Collector bei jedem Schleifendurchlauf die Software für 100ms stoppt.

Die durch den JIT optimierte Schleife sieht dann ja wie Du oben beschrieben hast ganz anders aus und müsste ja auch an der GC "vorbeilaufen"?!

 

[fexpop]

Wie sieht das denn dann aus?
Müsste das mit JIT nicht immens viel schneller sein?

Manches profitiert mehr, manches weniger...

Die durch den JIT optimierte Schleife sieht dann ja wie Du oben beschrieben hast ganz anders aus und müsste ja auch an der GC "vorbeilaufen"?!

Ich hab's ja oben stark vereinfacht, am Garbage-Collector wird da nichts vorbeilaufen.

Aber ganz ehrlich: So tief geht mein Verständnis leider auch nicht

Schöne Grüße,

Felix

 

[protagonist]

Aber ganz ehrlich: So tief geht mein Verständnis leider auch nicht

Ooooch.... und ich dachte ich hätte jetzt jemanden den ich mit sowas löchern könnte