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

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.

protagonist schrieb:

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.

Zum Vergrößern anklicken....

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

protagonist schrieb:

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.

Zum Vergrößern anklicken....

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:

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

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.

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

Zum Vergrößern anklicken....

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.

Zum Vergrößern anklicken....

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.

Zum Vergrößern anklicken....

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.

Zum Vergrößern anklicken....

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

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.

protagonist schrieb:

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

Zum Vergrößern anklicken....

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

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"?!

protagonist schrieb:

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

Zum Vergrößern anklicken....

Manches profitiert mehr, manches weniger...

protagonist schrieb:

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"?!

Zum Vergrößern anklicken....

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

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

Zum Vergrößern anklicken....

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