Android bald 3x so schnell Dank "Dalvik Turbo"?
Um was es bei dieser Sache geht, versuche ich mit einigen Zitaten aus folgendem Wikipedia Artikel klarzumachen:
Die Laufzeitumgebung von Android basiert auf der Dalvik Virtual Machine, einer von Google-Mitarbeiter Dan Bornstein entwickelten virtuellen Maschine.
Die Dalvik VM ähnelt funktional der normalen Java VM, beide führen sogenannten Byte-Code aus.
Anwendungen für die Androidplattform werden ausnahmslos in Java geschrieben, jedoch greifen diese in geschwindigkeitskritischen Bereichen auf zahlreiche in C oder C++ geschriebene, native Bibliotheken zu.
Das dürfte eigentlich schon klar machen, dass die Dalvik VM ein sehr wichtiger Bestandteil von Android ist, und auch für die Geschwindigkeit der ausgeführten Anwendungen zuständig ist.
Die Firma Myriad wird auf dem Mobile World Congress in Barcelona den sogenannten "Dalvik Turbo" vorstellen, der die Dalvik VM ersetzen soll. Anwendungen sollen dann bis zu dreimal schneller laufen. Das wäre ein ganz schöner Performance Schub für Android.
Oder um es mal salopp auszudrücken wäre das ja wohl der "Oberhammer".
In der offiziellen (englischen) Pressemitteilung gibt es weitere Infos.
Quelle: Myriad
TRAINSTATION
Die Dalvik VM dürfte recht langsam sein, von daher ist hier wirklich was zu holen...
Mit dem NDK kann man keine rein nativen Apps schreiben, Java wird immer benötigt, um zB GUIs zu steuern oder auf bestimmte Events zu reagieren, von daher kann sich eine schnellere VM nur positiv auswirken.
Natürlich wird Android nicht plötzlich 3x schneller, aber ich denke schon dass Android und seine Anwendungen dadurch ein bisschen flüssiger wirken könnten, vor allem wenn mehrere Anwendungen gleichzeitig laufen.
Ach.Ich als gelehrnter Fachinformaticker für Anwendungsentwicklung sage: das passt schon.
:-)
Und um den Begriff JIT mal etwas besser für Nicht-Techies zu erklären, bzw. woher das überhaupt kommt.
Normalerweise wird Programmcode in Maschinensprache (Assembler) entwickelt. Naja, eigentlich in höheren Programmiersprachen (C++ zum Beispiel), die aber dann eben Maschinensprache ausspucken. Die Maschinensprache wird von dem Prozessor interpretiert und ausgeführt.
Das Problem: Maschinensprache ist wie der Name schon sagt von Maschine zu Maschine unterschiedlich. Also das Programm, dass auf einer Maschine läuft, läuft nicht unbedingt auch auf der nächsten. Die Maschinen sprechen unterschiedliche Dialekte. C++ Programme zum Beispiel müssen zwar nicht für jede Maschine unbedingt neu programmiert, aber zumindest neu in Maschinencode übersetzt werden.
Java löst dieses "Problem" dadurch, dass es ein einheitliche Sprache anbieten. Früher wurden Programme in dieser einheitlichen Sprache dann von der Java Runtime (also der Laufzeitumgebung, die auf jedem Rechner zuerst installiert werden muss) interpretiert und dann ausgeführt. Java tut quasi das, was die Maschine sonst direkt tun würde... Es tut das, was ihm das Programm sagt. Das was Java tut, ist wiederum in Maschinencode implementiert und wird von Rechner ausgeführt. Das ist einfach ausgedrückt doppelgemoppelt und logischerweise langsamer. Dies muss aber in Kauf genommen werden, da nur so das ursprüngliche Programm auf allen Maschinen unverändert laufen kann - es ist ja in der Java-Sprache, sogenanntem Bytecode, geschrieben und nicht in Maschinensprache.
JIT, Just-In-Time, heißt, dass Java beim allerersten Start der Applikation den Bytecode in Maschinencode umwandelt und dann direkt vom Rechner ausgeführt werden kann. Der Umweg über das Interpretieren durch Java entfällt. Ein JIT-Compiler ist (einfach ausgedrückt) also eine Art Simultanübersetzer.
Alle Techies, Entwickler und Java-Fans werden mich erschlagen. Sorry :)
Huiuiui is das schon 'ne lange Diskussion :)
Ich gehe davon aus, dass JIT demnächst in Android Standard wird. Evtl. nicht mehr für 1.5/1.6, aber auf der diesjährigen Google I/O gibt es sogar eine Session dazu:
http://code.google.com/intl/de-DE/events/io/2010/sessions/jit-compiler-androids-dalvik-vm.html
@Cyprian ... wenn Du denn kein Berner bist ... ?
Nebeneffekt von 2x schneller ist 2x weniger CPU-Zeit und somit halber CPU-Stromverbrauch für die Dalvik-VM... somit hält der Akku vielleicht so 10%-20% länger ;-)
ja ja, die wir Schweizer ;) machen alles ein bisschen schneller ;)
@ Markus seit wann arbeitest den du bei uns =P könnte echt gleich hier aus dem Büro kommen
Markus - LOL - Deine ´üblichen firmeninternen Kommunikationsprozesse´ ;-))
@Bodo: Du verstehst es schon sehr gut und bringst es auf den Punkt! ;-)
;-)
Hier mal ein Beispiel üblicher firmeninterner Kommunikationsprozesse:
Entwickler zum Abteilungsleiter: Wir haben eine durchschnittliche Steigerung auf plus minus 150% erreicht, wobei es in 85% der Fälle nur einen zusätzlichen Speicheraufwand von 40% gab. In 7% der Fälle lag der Performancegewinn sogar bei 200% - dies entspricht 3 mal so schnell. In 70% der Fälle erreichten wir 60%. Die restlichen 23% funktionierten nicht, oder verlangsamten sich um 20%.
Abteilungsleiter zum Marketing: Die durchschnittliche Steigerung liegt bei soliden 150%. In vielen Fällen erreichen wir sogar eine stabile dreifache Geschwindigkeit. Es sind noch ein paar Fehler drin, aber die bügeln wir bis zum nächsten Milestone aus.
Marketing an Presse: Unser Produkt macht alles bis zu 3 mal so schnell!
Ich verstehe überhaupt nichts von dem, was hier geschrieben wird, weil ich nichts mit der Programmiererei am Hut habe, wage mich aber dennoch mit einer Frage hier rein:
mich bremst doch sogar mit meinem langsamen G1- Prozessor gar nichts wirklich aus, was die Apps angeht. Ausbremsen ´tut mich doch´ das langsame UMTS und zu Hause WLAN. Da kann doch Dan Bornstein so viel an seiner virtuellen Maschine verbessern, wie er will, oder ?
also ich kann, nur sagen, dass ich das auch für unrealistisch halte... die vm kann etwas schneller werden, ja in manchen speziellen Funktionen sogar 3mal schneller -aber die Leistung merkt man in "echten " Apparat nur wenig , oder nur teilweise...
@Michael: Ja, das sehe ich exakt genau so. Wenn es tatsächlich um Performance geht, werden diese Teile nativ angesprochen.
@Dominik: Die DalvikVM ist eine (native) Anwendung in Android. Wird diese Anwendung beschleunigt, dann beschleunigen sich (fast) alle Anwendungen, die unter der DalvikVM laufen. Das ist schön, beschleunigt aber nicht das "gesamte System". Viele Hintergrundprozesse laufen nicht in der DalvikVM, sondern direkt nativ auf dem Gerät. So auch Grafikroutinen, die per nativer Bibliothek von der DalvikVM angesprochen werden.
@Dominik: Dass Interpreter mit einem JIT teilweise schnellere Ausführungsgeschwindigkeiten erreichen, als statisch compilierter Maschinencode, stimmt. Es kommt dabei jedoch auf den Programmierstil an. Otto-Normal-Code kann der JIT meisst gut optimieren, da er an sich unoptimiert geschrieben ist. Optimierung heisst jedoch nicht Performance. JITs haben immer eine schlechtere Performanceobergrenze als compilierter, hardwarenaher Code. Für die meissten Anwendungen reicht aber seit gut einem Jahrzehnt die Geschwindigkeit aus, die mit interpretiertem Code erziehlt wird. Daher ist die ganze Performancegeschichte doch eher eine Sache, die nur wenige Entwickler interessieren dürfte, und ebenso nur wenige Anwender spüren werden.
Hab grad auf engadget: "At the moment it doesn't even include a JIT compiler! (Although apparently they are *finally* working on it.) The garbage collector is also the most basic design possible (mark & sweep)."
Also kann man aus der VM wirklich noch einiges herausholen....
Sicher gibt es auch einiges an Code in C und C++ in Android, das sind aber hauptsächlich Bibliotheken auf die man wieder über Java-API zugreift, plus Kernel+Treiber, die Ebene darüber ist wohl das meiste in Java geschrieben, also die Applikationen die wir sehen. Man darf nicht vergessen, das NDK hat es ja auch nicht von anfang an gegeben.
-
Mod
09.02.2010 Link zum KommentarAlso "Anwendungen für die Androidplattform werden ausnahmslos in Java geschrieben, jedoch greifen diese in geschwindigkeitskritischen Bereichen auf zahlreiche in C oder C++ geschriebene, native Bibliotheken zu.".
Der Satz ist schon mal ein Widerspruch in sich. Mag sein das es Apps gibt die rein in Java geschrieben sind, aber wie schon geschrieben, wenns wirklich Geschwindigkeit bracht, wird C und C++ genutzt.
Also nehmen wir mal einfach an, geschwindigkeitsunkritische Teile wie die Oberfläche in Java, darunter wo es "rock" C++. Also würde eine Beschleunigung des Java-Teils in so einem Fall nicht soviel bringen. Ausser das sich eben die eh schon unkrituschen Teile schneller werden.
Die 3fache Geschwindigkeit wird wohl in internen Labortests erreicht worden sein, mal sehen wie das in der Praxis aussieht.
Aber wenn man Android optimieren will, dann bei der VM, von Geschwindigkeitssteigerungen hier kann ja das gesamte restliche System profitieren.
@Markus: Dalvik Turbo soll Dalvik im Android SDK ersetzen, der Hersteller ist auch in der Open Handset Alliance, das wird also eine offizielle Lösung.
zum Thema Compiler vs Interpreter: Es gibt auch Meinungen, dass ein Interpreter sehr wohl schneller sein kann als ein Compiler, da der Interpreter auch Optimierungen zur Laufzeit vornehmen kann. Gebe dir aber recht generell sind native Programme wesentlich schneller.
@Fabian: In der Pressemitteilung ist die Rede von "bis zu 3 mal so schnell", worauf man auf das "bis zu" achten sollte. Sicherlich ist dies unter gewissen Umständen möglich - da will ich denen keine Lügen unterstellen - aber inwiefern sich diese punktuelle Performancesteigerung im Gesamtergebnis niederschlägt, steht aus. Denn genau das ist die eigentlich wichtige Information und genau die geben sie nicht in ihrer Pressemitteilung.
Ich denke eine Steigerung auf (wohlgemerkt "AUF" und nicht "UM") 1,5 ist im Bereich des Machbaren. Mehr nur punktuell und damit für den Anwender nicht fühlbar.