Android 2.2 alias Froyo serait 4,5 fois plus rapide grâce à JIT

Pour ceux qui ne bénéficient pas du JIT Compiler, j'ai trouvé un autre bench qui évalue le Java du tel. C'est un CaffeinMark pour Android. C'est fait par une boite qui propose une techno pour améliorer les perf d'Android, et ils ont une base de données consultable là : http://www.flexycore.com/benchmark-database-access.html Et qui permet de comparer son tel aux autres, de même type ou non, et de voir le gain apporté par leur techno par rapport à une version standard. C'est assez impressionnant ! Sur mon Desire, le score du bench est passé de 1000 environ à plus de 8000!

@kurapix, faut lire tous le test en autre " In these (x86 Ubuntu™ : Intel® Q6600® quad-core) examples we measured elapsed time once the Java program had started: in the first case, we simply started and measured the program 66 times; in the second case, we started the program once and repeated measurements again and again and again 66 times without restarting the JVM; and then discarded the first measurement leaving 65 data points. The usual startup measurements and the "Java 6 steady state" approximations (and JVM time) are shown alongside for comparison. "1.6.0_16" started 65 times repeated 65 times mean σ mean σ usual startup approx. JVM time meteor contest 0.23s 0.01 0.12s 0.00 0.31s 0.13s (14 sec) spectral norm 4.08s 0.23 3.96s 0.02 4.11s 3.96s (4 min) pidigits 5.03s 0.14 4.65s 0.10 5.00s 4.55s (5 min) fasta 7.50s 0.21 6.91s 0.12 7.51s - - mandelbrot 11.91s 0.81 11.46s 0.06 10.95s 11.40s (13 min) binary trees 20.69s 0.69 15.35s 0.43 19.18s 15.40s (17 min) fannkuch 18.74s 0.66 18.56s 0.48 18.43s 18.59s (20 min) nbody 24.94s 0.02 25.07s 1.22 25.03s 24.69s (27 min) Loading Java bytecode, profiling and dynamic compilation do take time but not enough time to make much of a difference in these examples. The obvious differences show where there is a mismatch between program structure and JVM optimization - even though methods have been fully compiled, the JVM continues using the on-stack-replacement. The opportunity to use the fully optimized compiled methods seems only to arise the next time the code block is invoked - whether that's in 10 seconds or 10 days. To highlight that mismatch, "Java 6 steady state" approximations are shown in the measurement tables alongside the usual startup measurements." il y a un gain, mais pas vraiment impressionné étant donné que c'est pas une application réel... mais des mini bench partant de ce constat là: j'avais exécuter quelques bench aussi http://laboiteaprog.com/article-94-5-linux_benchmark_64_bits_c++_vs_java faudrait avoir maintenant avec les récentes amélioration de la jvm ce que ça va donné

[...] fameux compilateur JIT blabla Dalvik qui à buzzé un peu partout la semaine dernière, j’ai aucune idée de comment ca fonctionne mais ce qui nous [...]

@collinm ça sert pas à grand chose ... enfin pas de ce que je vois sur les benchmarks de http://shootout.alioth.debian.org/. @kevin Plus rapide en calcul mathématique ... or un computer c'est fait pour compute (calculer) ;) . Et puis ça peut toujours être utile d'avoir de la perf en rhab'. Et si le HTC Desire est plus réactif qu'un HTC Hero :) .

en même temps, un htc Legend qui fait moins de 3 à ce test n'est pas 2x moins rapide qu'un Desire... la différence est assez minime je pense (en tout cas pour une utilisation basique, on voit peut la différence)... donc de là à dire que cette amélioration rendra le téléphone 4 fois plus rapide, je ne pense pas. Plus rapide en calcul algébrique, peut-être^^

Enfin un forum avec des gens qui savent de quoi ils parlent :) C'est tellement rare que ça vaut le coup de le dire. Ça change et ça fait vraiment du bien :)

@kurapix, justement il y a bien plusieurs raison pourquoi JNI existe..... et tu la cites l'utilisation de code existant... l'intérêt de l'optimisation adaptative c'est justement de faire les optimisations en fonction du cpu, sur la façon que le programme est utilisé

Et j'oubliais : le NDK existe bien pour une raison aussi ;) . Je cite Google : "Android applications run in the Dalvik virtual machine. The NDK allows you to implement parts of your applications using native-code languages such as C and C++. This can provide benefits to certain classes of applications, in the form of reuse of existing code and in some cases increased speed. [...] The NDK can, however, can be an effective way to reuse a large corpus of existing C/C++ code."

@Aissen content de voir une autre personne de mon avis sur ce site concernant Java :) . Pour OpenMoko, de ce que j'ai vu, ils bossent plus sur la pile graphique que GSM. Au final on se retrouve avec une superbe GUI mais une pile GSM qui pêche, ce qui peut poser problême si on veut téléphoner avec son téléphone .... Maemo ne m'a pas convaincu non plus avec le N900, pas asser ergonomique et trop peu d'applications portées. @collinm Une application native bien pensée éclatera toujours une application tournant sur une VM peu importe les optimisations apportées en VM. Je ne vois pas l'intérêt de l'optimisation adaptative sachant que 70-90% des opérations effectuées par le processeur ce sont des "mov" et de l'indirection de pointeurs. Concernant les branchements, il y a la prédiction et le pipelining. Par ailleurs, l'escape analysis doit vite atteindre ses limites vu qu'on n'est pas capable de programmer automatiquement le multithreading. En effet, une tâche sérielle n'est pas paraléllisable tandis qu'une tâche paraléllisable est sérialisable. Et enfin, si le JNI existe c'est bien qu'il y a une raison derrière ;) .

@Aissen, ffmpeg ne fait absolument pas d'optimisation adatative, c'est juste un programme multi plateforme... absolument rien d'extraordinaire pour ce qui est de l'escape analysis ce n'est qu'une technique utilisé par les compilateur pour déterminer la porté d'un pointeur gcc supporte ça il y a des GC en C++, tu sais?

@collinm: Un programmeur peut faire tout ça, et même de manière portable. Regarde ce qui ce fait du côté de ffmpeg par exemple. Alors, oui une vm c’est bien pour écrire le code une fois et supporter plusieurs processeurs avec le même binaire, mais le code d’un programmeur consciencieux (et optimisé par la suite), sera toujours aussi rapide… Ensuite ce que tu cites est limité au Java, puisque dans ce langage on ne peut allouer d’objets sur la pile de base… Ça n’a rien à voir avec le C ou C++ où tu gères toi même la mémoire et tu peux allouer tes données comme tu veux: pile, tas, place de choix dans les registres, etc.

@faww j'espère que oui... sinon surement possilbité d'installer une autre rom

yaura t il une mise a jour pour le htc desire ???

@Aissen certe une application native peut être compilé en fonction du cpu alors soi tu fais un exécutable pour chaque cpu ou bien tu as de multiple version du même code pour différent cpu ce qui demeure très loin d'être de l'optimisation adaptative il me semble aussi que la jvm utilise une méthode appelé escape analysis qui est ultra limité en c++ ça permet en autre d'allouer les données sur la pile au lieu du tas

@collinm: Tout ce que tu dis peut-être fait par un programme compilé en natif (sans bytecode intermédiaire). @kurapix: jette un œil du côté de Maemo/Meego, voire OpenMoko si tu veux plus libre. @griphine: exact, c’était une confirmation, le doute planait pour certains sur la véracité du Top 10 Linpack.

et le test est recent, c'etait pour confirmer le precedent.

mieux vaut tard que jamais. :)

[...] Pour rappel, on sait qu’il y aura Flash de Adobe. Et on pense que les performances seront vraiment meilleures, et que le bureau est revu. La rumeur de la journée nous vient de [...]

Ça date pas d’hier, la news sur Linpack en Mars dernier: http://www.greenecomputing.com/2010/03/15/nexus-one-with-froyo-takes-the-lead-at-40-099-mflops/ (passé inaperçu, je l’avoue. Cyanogen l’a repris sur Twitter en Mars, je l’avais vu en Avril…) Quand Dalvik est sortie, son concepteur disait qu’elle faisait pas de JIT parcque c’était pas intéressant sur des processeurs ARM qui ont un tout petit cache au niveau du processeur. Ça veut dire que ça va bien marcher sur des téléphones de dernières génération comme le Droid/N1/X10. Je sais pas ce que ça va donner sur les anciennes génération (Legend/Magic/Spica).

Ok merci pour les précisions sur le JIT collinm. Par ailleurs non, y'a pas plus libre qu'Android sur le marché mobile ... Parfois on est obligé de se plier aux contraintes de la plateforme ...

@kurapix, personne te force a prendre android..... il y a d'autre téléphone si la liberté est primordiale... justement non une application qui utilise le JIT peut être plus rapide qu'une application native compilé des bench qui le démontre il en pleut sur le net par exemple un jit peut optimiser le code pour le processeur en cours d'utilisation prend des données sur la façon que le programme fonctionne et optimiser certaines partie en fonction de cela (mise en place de méthode inline...) chose impossible dans un programme compilé

Qu'ils nous laissent la liberté du choix du langage comme je disais collinm. Le Java n'apporte pas grand chose pour ma part, ce n'est qu'un avis personnel (mais je ne suis pas le seul à l'avoir ^^). Le problème de conception de côté, une appli' native compilée comme il faut battra toujours une application Java en terme de performance, optimisations JIT ou non.

@aurel, oui si tu veux avoir un résultat le plus réaliste possible...

@kurapix, c'est bien beau qu'il y est plus de programme en c, c++ que java, mais là on est pas sur un domaine différent la mobilité..... si tu recherches vraiment ce que tu veux c'est un nokia n900 qu'il faut... c'est bien beau d'avoir accès à un tas d'application en c, c++, encore faut t'il que leur interface soit adapté c'est depuis la version 1.4 qu'il y a un jit quake 2 existe en java avec la vm de sun par exemple si tu fais du 2d il y a moyen que la vm utilise directement opengl c'est un problème de conception.... tu peux très bien faire des applications lentes en C++, openoffice, firefox en sont de bon exemple... le jit permet de faire des optimisations en temps réel qu'un le c, c++ ne permet pas... il y a encore place à amélioration, par exemple les programmes sont compilé à chaque exécution... il pourrait avoir une option qu'une fois il y a énormément de couplage dans les librairies, ce qui fait en sorte qu'un banal hello world... doit chargé des centaines de classes... java 1.7 va résoudre le problème de plus, Dalvik n'a totalement rien a voir avec une jvm conventionnel donc ils peuvent faire tout un tas d'amélioration que les autres jvm n'ont pas encore fait

@niox Peu importe qu'on développe en natif ou en managé, on n'échappe pas aux tests sur les différentes plateformes. L'architecture processeur est la même sur 95% des terminaux Android à ce que je sâche actuellement (ARM en majorité puis x86). Les autres fractures se situent au niveau des différences dans les APIs, le Droid et les Archos sont de bons exemples. Qu'ils nous laissent le choix du langage! Ce n'est pas facile mais ça permettrait des économies substantielles pour certains et une facilité de portage accrue pour les applications déjà existantes. Par ailleurs, dans tous les cas, on aura des problèmes lorsque les jeux 3D pointeront leur nez (y'a déjà des soucis avec ceux sur le market). En effet, les terminaux Android ont une très grande hétérogéinité au niveau du hardware en terme de performances. Les jeux vont soient être jouables sur tous les terminaux ou uniquement sur les plus puissants (3D oblige). Le problème va s'accentuer avec l'installation des GPU mobiles. @badeu Et pour finir, oui même si Flash est en natif ça va quand même servir! Le CPU étant moins monopolisé par le Java, Flash pourra mieux l'utiliser (ou le bouffer tout cru ... :( ). @sha Euh oui je me suis mal exprimé (car framerate élevé = performance élevé). Plutôt performance et graphisme évolué et poussé. Donc oui y'a des applis Java 3D très bien fouttues et fluides mais jamais vu une qui égalait une appli' en natif'. Et ceux malgré que j'ai lu que le JIT pouvait apporter de meilleure perf' que le natif' (mais ça m'étonnerais un peu beaucoup quand même ...).

@kurapix effectivement le problème de distribution d'applis natives pourrait être solutionné par un système comme APT mais penses aux developpeurs. Qui a les ressources pour tester ses applis sur plusieurs archi différentes? Ca serait certe utile une kitchen qui fait les builds "compatibles" avec toutes les architectures disponibles mais il faudrait quand même tout tester. A l'heure actuelle les seuls problèmes de fracture hormis la puissance est surtout la taille de l'écran et pas la différence d'archi j'ai l'impression.

J'ai 1.1 sous mon Galaxy 1.5, ça me parait un peu faible par rapport aux stats, faut fermer toutes les applis pour faire le test ?

Re : Et pour une utilisation finale ça va changer quoi pour moi ? Moins de resources bouffé donc moins de batterie utilisée ? Meilleurs perf dans les jeux, appli, sur internet ?

C'est bien ça, ça annonce du bon. Comme beaucoup j'attends ça avec bcp d'impatience sur mon Nexus qui devrait être le premier phone à passé sur Froyo ! @kurapix J'ai pas tout compris mais ça à l'air claire ;)

pour info le JIT fourni dans les versions preview d'Eclair est super vieux et buggé, celui ci devrait être bien plus stable et rapide. De plus, cette histoire de 450% porte sur un cas de test ultra précis (sans doute des opérations maths), d'après la team Android, le premier truc qui sera visible sera le démarrage des applis, bien plus rapides à se lancer Et j'ajoute qu'il existe des applis Java 3D très très fluides (Speed Forge 3D est écrit en Java)

Du coup comme expliqué par tout le monde, le JIT c'est de la compilation au runtime pour avoir des meilleures perfs que ce que permet le dalvik engine en interprété actuellement. Donc l'incidence se fera sentir au niveau des applications basées dessus, soit quasi tout l'écosystème d'Android. "Bref, Android 2.2 promettrait un gain de performance remarquable qui a sûrement été l’objectif premier de Google avec l’arrivée de la technologie Flash très gourmande. " Du coup, le lien de causalité entre le JIT et Flash n'a absolument pas de sens étant donné que Flash est en natif.

Hâte de voir ça sur le HTC DESIRE :) !!

Par ailleurs, jamais vu de Jeux vidéo en 3D en Java qui tiennent la route en terme de framerate ET de performance ... La preuve, Google avantagie le NDK pour les applications gourmandes tels que les jeux vidéos 3D ... plusieurs arguments en défaveurs du Java en conséquence.

siko oui le JIT c'est de la compilation à la volée lors du runtime. Il n'y a par contre aucun intérêt à utiliser Java si ce n'est pour faire du soft propriétaire. La portabilitié du Java est seulement théorique, il induit des latences à plusieurs niveau qu'on ai une JVM JIT ou non (latence au démarrage ou latence en exécution). Etc, ... Une kitchen qui te ponds des exécutables natifs ou les distribuent ça gère largement mieux. Debian supporte 17+ architectures et fonctionne très bien ... Google ont largement les moyens de faire un système style APT. Pour le sandboxing y'a également de quoi faire en natif' : Hyperviseur type XEN, les Jail à la FreeBSD ou encore OpenVZ qui induisent de très très petites ressources gachées. De plus, tu peux avoir des bindings vers n'importe quels langages à partir du C ou C++ (binding Java vers autres chose n'a aucun intérêt). Donc un choix du langage. De plus, tu as une plus grandes base de code en C, C++ et autre qu'en Java .... Ca évite d'avoir à re-écrire de grosses parties de code (une kitchen est quand même mieux que la NDK). Osef qu'ils veulent utiliser Dalvik et le Java, mais qu'ils nous laissent au moins le choix du langage! Bon après Google avait des contraintes de temps pour sortir Android (vu qu'il fallait concurrencer au plus vite l'iPhone). J'ai bien hâte de voir débarquer Froyo sur mon HTC Desire pour sûr ... à moins que je me décide à le rooter avant ;) . kurapix

Mon Acer Liquid fait entre 5,1 et 5,3 avec Android 2.1 bêta.

sur mon petit spica en 2.1,je fais 3.109 et dans le top android, le HTC Legend fais 2.742 sous eclair 2.1 !!! en regardant de plus pret, la rom la plus rapide en 2.1 pour le spica est le XXJCF.

Oula petite precision j'ai pas mis exactement ce que je voulais dire au dessus 4h30 ca aide pas. Jit convertit le code java en code natif, le code natif c'est du code compris directement par la couche hardware (assembleur ?) au lieu d'etre interpréter comme le fait actuellement android. Si je me goure pas c'est ce que fait dalvik pour android. Jit veut dire just in time, encore une fois d'après ce que j'ai compris et qui est donc a prendre avec des pincettes, cela veut dire que les apk ne changent pas de forme et c'est jit qui convertit en temps réel les instructions quand il y a besoin.

Pas certains de ce que j'avance donc a prendre avec des pincettes, mais jit compilerait du java en code natif. (Java n'est de base pas compiler mais interpreter). Après j'espère qu'il ont ameliorer la chose car jit cause de gros problème sur certaine appli, force close ou ralentissement sur d'autres. (Ca reste une minorité d'appli, je dirait 10%). Sur mon dream jit mais me fait passer mon linkpad a 3.3, et avec un petit overclock a 4. Sur une rom 2.1.

Pour le Java c'est déjà ça. Sinon juste comme ça : 37.6/6.7 ~ 5.6. Il ont optimisés quoi car c'est tout bonnement énorme en terme de différence de perf'. La prochaine étape : un système style APT pour avoir des applications tournant en natif et pour gérer les plateformes hardware? :)

Plus rapide mais que pour le java apparement.

Griphine, tu as Gtalk ? Il faut que je te parle de quelque chose. ;)

Merci à vous pour la source, c'est bien sympathique ! :)