Android 2.2 serait presque 6 fois plus rapide

Du coup ça fera qu'il sera aussi rapide qu'un iphone HD ou toujours pas ?

T'as déjà essayé ce produit ?

Il faut voir surtout qu'est-ce qui est en mesure de profiter de ces améliorations : le système ? les logiciels ? les jeux ??

Les communications ? une minute de conversation passerait à 10 s ?





Ok je sors

En fait c'est pas l'OS qui est plus rapide c'est le traitement de Java...ce qui ne veut nullement dire que Android 2.2 est 6 fois plus rapide que le 2.1...enfin c'est ce que je comprends...

C'est dit dans la news : les programmes codés en Java. Donc toutes sont concernés dès l'instant où elles sont en Java.




Déjà, l'iPhone HD est pas sorti, et de toute façon, c'est quoi cette question ??!
Les smartphones Android haut de gamme sont déjà plus puissant que l'iPhone 3GS.
Etant donné ce dernier est sortie il y a déjà presque un an, la course aux performances ne fait que commencer.

Aussi rapide que dans les pubs mensongères d'Apple, oui.

Ouai enfin le fait que les Android hauts de gamme soient plus puissant que l'iPhone 3GS ça ne veut pas dire qu'ils soient plus rapide.
Personnellement je prefère un téléphone moins puissant si l'interface et le traitement des tâches sont plus fluide.
La fluidité et la réactivité d'un iPhone est je pense exemplaire en comparaison avec un Android.

T'as pas plus imprécis comme réponse ?
Si je demande des exemples c'est parce que, justement, c'est trop vague. Par exemple, est-ce que toute l'interface d'Android est en Java ?
Tous les logiciels d'origine sont-ils également en Java ?

Si j'ai bien suivi (à vérifier), il y a une sorte d'interpréteur spécifique dans Android qui exécute le bytecode Java plus rapidement, car le jeu d'instructions est plus restreint. De là, tous les développements ne sont pas en "Java", et l'ihm ne l'est pas. *

Pour autant par contre, j'ai du mal à comprendre le débat "puissance", parce que tout dépend de ce qu'on entend par puissance! Ce qui me fait sourire, c'est la notion de rapidité: rapidité de quoi? Sur un bench hardware, l'iphone quelque soit sa version est battu par les dernières machines sorties. Sur un bench software, comment comparer ce qui n'est pas comparable? Le temps de réponse du tactile? La fluidité? Ce sont des mesures subjectives, donc, pour moi, uniquement liées à la réaction de l'utilisateur, et non aux performances réelles du produit.

Euh l'IHM est en Java. Le Home en tous cas. et le reste aussi.
Quasiment tout ce qui est haut niveau est en Java en fait, les couches un peu plus basses du système sont en C, comme tout bon Linux qui se respecte. Un gain de ce type concernera donc toutes les applications qu'on trouve sur le market ou presque (certaines applis peuvent accéder aux couches plus basses en ayant une partie codée en C, mais elles sont rares).
Quand à le comparer à l'iphone HD, ça dépend essentiellement du matériel. Le Nexus One est tout aussi fluide et rapide qu'un iphone 3GS pour l'interface, mais à ce niveau de fluidité je doute qu'on puisse observer une différence même si la prochaine version va "6 fois plus vite". Par contre peut être que ça sera toujours aussi fluide avec 20 services qui tournent en même temps, là ou l'iPhone n'a pour l'instant aucun multitâche excepté celui du lecteur musical.

C'est plus rapide à exécuté donc ça consomme moins !
Voilà un intérêt indéniable !

Merci pour ces précisions, j'ai donc mal compris la fiche technique sur l'aspect jvm embarquée.

Et nous nous rejoignons sur le côté performances: ça n'a de sens qu'en comparant la même chose

Heuu... ça n'est pas du tout exact comme raisonnement:
Si ton processus met 1 seconde à faire le traitement mais avec un processeur ne consommant (admettons) 0.5w/s (mesure débile pour l'exemple), et que tu exécutes le code en 0.5s sur un processeur consommant... 1.5W/s, tu consommeras plus. De ce fait, la mesure de performance influe aussi sur la consommation! Donc relation puissance consommation mal maîtrisé

Le fait qu'un calcul prenne moins de temps ne signifie pas que le proc consomme plus durant ce laps de temps, bien au contraire !! je suis d'accord avec Vermoute : si le cpu est moins solicité il consomme moins c'est aussi simple que ça. Cela veux dire que sur un prog qui s'execute pendant 1s, le proc consommera disons 10mw avec android2.2 et 20mw avec android1.1 (pour l'exemple),
Si l'optimisation de code augmentait la consommation, ca se saurait ...

à proco égal, oui. mais c'est pas forcément le cas.

Le langage utilisé pour les applis Android c'est JAVA (via leur JDK) dans la grande majorité, il est possible d'utiliser le C (via leur NDK) pour des fonctions bas niveau (déconseillé par Google) ou des fonctions de traitement/calcul demandant un maximum de vitesse.

Côté développement, JAVA reste plus accessible que le C surtout au niveau syntaxe et structure.

Le moteur d'exécution JAVA d'Androïd 2.2 semnble avoir été amélioré et c'est une bonne chose car JAVA même optimisé via un JiT restera toujours plus lent par rapport à des vrais langages compilés (comme le C) donnant du binaire directement exécutable par le processeur sur lequel il tourne comme c'est le cas pour l'iPhone (d'ailleurs Apple n'autorise aucun autre langage que l'Objectve-C pour le plus grand malheur d'Adobe et son Flash/ActionScript).

Maintenant pour la comparaison avec l'iPhone, une appli sur un iPhone 600mhz en C sera je le pense toujours plus rapide que la même appli JAVA sur un Android à 1Ghz sauf à optimiser vraiment beaucoup leur JiT.

Je pense (mais là c'est une opinion personnelle) que c'est pour cela que l'interface des applis iPhone semble toujours plus "fluide" que sur Android car on reste "C" de bout en bout sans ralentissements JAVA.

Petite précision, l'accélération semble avoir été faite sur le traitement des calculs à virgule flottante qui n'est pas utilisé par la grande majorité des applications mais plutôt pour les logiciels de traitement image/son/3D/physique.

Donc en réalité si l'application n'est pas orientée sur ce type de traitement, l'utilisateur ne devrait pas voir de différence.

Dodutils évite d'extrapoler.

L'accélération a été fait sur la partie JAVA en générale. Et le bench qui confirme cette augmentation de perf, teste les perf sur le calcul en virgule flottante.

Les calculs en virgules flotantes sont utilisés dans quasi 100% des type d'applis.
Flash, web, vidéo, interface, jeux vidéo etc..
Même si en générale les applis sur téléphone essaie d'utiliser des entiers (virgule fix ) pour palier aux faibles perfs des calculs en virgule flottante (et sur beaucoup de portable ancienne génération, les virgules flottante ne sont même pas dispos )

Si l'API Java d'android propose des fonctions haut niveau pour utiliser l'accélération materiel dans la gestion de l'interface, il n'y aura quasi aucune dégradation de perf entre le java et le c.

Et on peut résumé la diff entre java et c:
Java bouffe plus de mémoire à l'execution, mais les programme sont plus petits (remplit moins votre carte mémoire)
Le C est un poil plus perf et prend moins de mémoire. Par contre l'appli prend plus de place sur la mémoire de masse du tel.

Le java est un langage conçu pour être utilisé dans des petits appareils, le C non.

La plupart des interfaces de tel 1Ghz Android sont déja hyper fluides.
Je vois pas l'interêt de faire mieux...

En tout cas, il vaut mieux attendre d'avoir l'os qui sort, avant d'extrapoler quoi que ce soit...

Encore une fois: l'optimisation en terme de vitesse d'exécution n'est pas la même que celle de consommation mémoire, et encore moins d'exploitation du processeur.

Comme l'a dit 1815 : Si sur un même processeur tu obtiens de meilleurs performances, oui techniquement tu auras un gain de consommation puisque tu solliciteras le processeur moins longtemps. En revanche, si tu fais le test sur deux processeurs différents... tu n'obtiendras jamais un résultat concluant.

Autre chose: l'optimisation de la consommation mémoire peut réduire les performances. On peut faire le choix du "Moins de mémoire consommée, mais durée de traitement plus longue". Tu peux tout à fait faire le pari (sur des architectures serveurs notamment) qu'un batch tournant la nuit n'aura pas forcément besoin d'une performance en vitesse, mais qu'en revanche il faudra savoir réduire la consommation brute de mémoire, ne serait-ce que pour laisser de la place aux autres processus.

Et sur un smartphone, c'est quelque chose d'essentiel. Tu privilégierais quoi? La vitesse d'un jeu qui squattera plus de Ram (donc ralentira potentiellement les autres applications résidentes), ou tu brideras cette consommation au détriment de l'application elle-même?

Pas du tout d'accord, ce serait même plutôt le contraire! Le C est compilé pour être au plus proche du processeur, alors que le Java utilise une machine virtuelle entre les deux, ce qui sous-entend une surconsommation relative de mémoire et de cycles processeurs. De plus, le véritable but d'une Jvm, c'est (théoriquement) de pouvoir exécuter un même programme sur n'importe quel OS, du moment qu'une Jvm est présente. Un .jar, c'est du bytecode que tu es supposé pouvoir faire tourner aussi bien sous Windows, Linux, ou n'importe quoi d'autre tant que tu as la "bonne" jvm (Version, librairies...)

De fait: le C est autrement plus performant puisque plus proche de la machine, par contre il pose le problème de devoir être spécifiquement compilé pour chaque couple OS/équipement.

Hercule007 : je n'extrapole rien du tout, étant programmeur moi-même les "float" et les "double" je n'en utilise pas des masses (hormis pour les applis qui traitent beaucoup d'image ce que font certains types de jeux par exemple).

Quand à la similarité des performances entre C et JAVA ... et bien il suffit de regarder cette augmentation des performances, si JAVA avait été aussi rapide que du C, ils n'auraient jamais pu gagner autant dessus mais leur précédent JiT avait apparement beaucoup de marge pour l'optimisation.

Quand aux applis Androïd très groumande en perfs, celles-ci utilisent le NDK pour les parties critiques et pas le JDK, le noyau du moteur Flash Androïd n'est certainement pas en JAVA.

Les prog JAVA sont plus petit ? je ne suis pas vraiment d'accord, pour le C tout dépend du nombre de LIBs que tu link, et pour JAVA c'est pareil, tout dépend des packages supplémentaires que tu inclus dans le JAR.

Pour réduire la taille d'un binaire on peut utiliser un compresseur tel que UPX qui est très efficace.

Pour ce qui est de "JAVA est conçu pour être utilisé dans de petits appareils" sur les systèmes embarqués ce n'est pas JAVA est couremment utilisé mais le C. D'ailleurs qu'est-ce que tu entends par "petits appareils" ça n'est pas très précis, petit en quoi ? ram ? cpu ?

Le C restera toujours plus rapide que le meilleur des JAVA JiT.

Côté performances, un Androïd 1Ghz vaut un iPhone à "seulement" 600Mhz, mais un Androïd 600Mhz ne vaut pas un iPhone à 600Mhz si les programmes sont en JAVA d'un côté et C de l'autre.

Par contre côté facilité/rapidité de dévéloppement, JAVA gagne sans problème.

Leur précédent JiT, il n'existait pas. Dalvik s'en est sorti sans JiT, c'était juste très lent.
À condition d'avoir de la mémoire à la pelle et un proco qui puisse décompresser rapidement. Sachant que dans l'embarque, on évite de faire des gros binaires à la base.
C'est quoi l'overhead java/C, aller, 50% ? 80% ? encore plus ? si c'est juste ça, il suffit juste de trouver un meilleur algorithme pour le programme java.

Techniquement, le simple fait qu'il y ait une machine virtuelle entre le système et le binaire ralentira l'exécution par rapport au binaire exécuté en natif. C'est inévitable, même si les performances du java peuvent (en principe) être améliorées. Aujourd'hui, ce sont les machines qui compensent la lenteur relative des jvm, ceci par l'accroissement de la puissance.

Le JiT a été introduit en 2.1 mais n'était vraissemblablement pas finalisé.



Tout à fait d'accord sauf pour la nécessité de décrompresser rapidement car généralement tu ne lances pas un binaire 50 fois par secondes donc qu'il perde un poil au alncement n'est pas vraiment un problème, j'avais juste donné cet exemple pour la forme car dans la réalité JAVA n'est pas franchement plus petit que le C. Et un simple "Hello World!" demande énormément de ressources (en terme général) par rapport au C rien qu'à cause du la taille nécessaire au stockage du moteur virtuel et des ressources nécessaires à son lancement.


Si c'est "juste" ça, c'est énorme, j'ai commencé le dèv en assembleur il y a longtemps où chaque cylcle CPU était important (ce qui est toujours important sur de l'embarqué selon les applis). Quand à trouver un meilleur algorithme, c'est tout simplement impossible comme l'indique aussi @magellan justement parceque l'on on est en JAVA et qu'il y a forcément "surcouche". Maintenant avec les JiT on a amélioré les perfs mais on reste toujours bien en dessous de ce qu'il est possible de faire en C.

Maintenant tout dépend de la réelle nécessité à être "rapide", par exemple qu'une appli se lance en 2 secondes au lieu d'une n'est pas important si cette application n'est lancée que quelques fois par jour. Maintenant si dans cette appli on doit cliquer sur quelques boutons plusieurs de fois d'affiler et que le temps de réaction est d'une seconde au lieu de 0.5, la ça devient gênant, tout est question de besoin/ressenti. Cliquer un bouton une fois par jour pour afficher des résultat qui mettront 30 secondes au lieu 10 secondes là encore ce n'est pas un vrai problème.

Ça dépend de ce que tu appelle "un poil". Si "un poil" c'est une minute, je suis pas sur que les gens acceptent d'attendre. Et kkrieger (le FPS en 96kio) se lançait en plus d'une minute. (même si ce n'est pas stricto-sensu de la compression).
Ce n'est pas parce que c'est du code natif que c'est le saint graal et qu'il n'est pas possible de faire mieux. N'importe quel tri rapide en java explosera tout les tris bulles écris en C (oui il y a des gens qui font du tri bulles en C pour leur n-ième implémentation de liste chainée). Et il n'y a pas que les algorithmes, il y a aussi les structures de données, et la dessus, les langages de plus haut niveau sont généralement mieux fourni en structures efficaces, alors que pour le C, la plupart du temps on se contente de tableaux et de listes chaînées. J'en ai vu des programmes Java/Python/Ruby exploser des programmes C mal foutu.

Mais par contre, quand on prend du C++ ou du C bien foutu, avec les bonnes structures de données et les bons algorithmes, et qui pense en plus au cache/vectorisation/parallélisme, alors on fera pas plus rapide en Java. Mais quand on regarde ce qui existe, on en est loin...
Ça dépend surtout de l'utilisateur et de l'utilisation. Si sur un téléphone il faut une seconde pour prendre en compte un appui sur une touche du combiné, je suis pas sur que l'utilisateur achète.

Il faut aussi voir que il y a des idiots qui overclockent, recompile agressivement et dépensent une fortune dans leur matériel pour espérer gagner 10 secondes sur les 30.
Ils feraient mieux d'apprendre à profiler.

Je parlais de décompression avec UPX par exemple. UPX est plutôt efficace.




En effet, quelque soit le langage, tu peux produire du code clean ou dégeux, et du JAVA clean ne vaut pas du C clean.

D'un autre côté la facilité/efficacité le JAVA est supérieur au C, on code plus vite, plus facilement et plus lisible en JAVA qu'en C, ce qui fait que côté rentabilité/rendement et selon la/les plateforme(s) de destination il peut être préférable d'utiliser JAVA (au d'autres langages "haut viveau").

T'a déjà comparé ?

Ta question est aussi imprécise que sa remarque. Il n'y a (quasiment) qu'1 iPhone là où trouve une multitude de téléphones sous Android.

Et dans le choix offert, il y a à boire et à manger en terme de performances et/ou fluidité Même dans le haut de gamme.
Sans compter le coté subjectif. Bref : bon courage

T'en es sûr? (c'est une question pas une critique)
iSuppli s’est penché sur les chiffres de ventes des constructeurs mobile au premier trimestre de cette année et confirme qu’Apple a bel et bien écoulé plus de téléphones que Motorola (8,75 millions d’iPhone contre 8,5 millions), ce qui fait au passage d’Apple le plus gros constructeur américain de mobiles (lire « [lire « .us : Apple, 1er constructeur mobile »).



Plus intéressant, avec 3% de part de marché, Apple s’est classée sixième constructeur mondial et devance Motorola de deux places. RIM est cinquième avec 3,6% et 10,47 millions de BlackBerry vendus.
Cupertino a connu une croissance vertigineuse des ventes d’iPhone de 130,7% comparativement à la même période de 2009 3,79 millions de mobiles pommés écoulés).

Cette étude met surtout en lumière la part très relative des smartphones sur le marché de la téléphonie : les trois premières places sont occupés par Nokia (37,4%), Samsung (22,3%) et LG (9,4%), qui écoulent bien plus de mobiles standard que de smartphones ; c’est également un encouragement certain pour les constructeurs de téléphones intelligents puisqu’il reste encore bien des parts de marché à conquérir…