Benchmark Nexus 4

[neo76 4]

Benchmark par GLBenchmark

Voici le tableau ou on peut voir la différence de performance entre le benchmark posté par Anandtech il y à quelques jours(published) et celui refais pas Anandtech aujourd'hui (obtained)

Voici le resultat du test Egypt HD écran eteint:

Pour le test complet c'est par la : GLBenchmark du Nexus 4

Pour plus d'info sur le Nexus, visitez le forum dédié au Nexus 4:

Nexus-4.fr

Edited November 7, 2012 by neo76

[bart49 63]

C'est bien tout c'est beau chiffres la comme chaque benchmark d'ailleurs ok mais concretement je suis sure que 80 % des mecs qui vont le lire ne savent pas du tout a quoi correspond chaque résultat moi inclus. Donc c'est bien l'histoire de jouer à qui à la plus grosse mais tant que ton téléphone est fluide en main à partir de la.

Edited November 7, 2012 by bart49

[neo76 4]

Je suis d'accord, tant que la fluidité est la ça suffit.

Mais après je sais que beaucoup de personnes aiment les benchmark, et la seulement 2 benchmark on eu lieu, donc ça permet de comparer un peu les résultat.

[Eleh 59]

100%. OSEF les benchmarks geek kikoo apple "j'ai la plus grosse". Le principal c'est surtout la fluidité et la réactivité C'est surtout pour ça que les Aplle-maniac critique Android. Mais aparement the verge a dit " It's easily the best Android phone on the market right now, and has some of the most powerful software that's ever been put on a mobile phone."

Donc wait and see...

[neo76 4]

Juste comme ça, c'est de l'information, si ça ne vous intéresse pas, vous lisez pas =)

[Divad 24]

Après on peut toujours discuter de la pertinence de l'info :).

En l'occurence les benchmark ont il été fait sur la même version de build, kernel, baseband, ...?

Vu que chaque site a l'air d'avoir une version différente, ça serait intéressant à préciser avant de tirer la moindre conclusion.

[Lenoil 83]

@neo76 : Comment que tu t'es fait jeté!!! Mdr!! ;)

Non, plus serieusement, je n'irais pas jusqu'a dire qu'on s'en fout, mais finalement, ils peuvent les traffiquer comme ils le veulent ces tests!!

[bart49 63]

Moi je veux bien des benchmarks c'est interessants mais il n'y a meme pas d'explications à coté...

Que veux dire tel chiffres ? plus le chiffre est grand mieux c'est ou pas ? etc il 'n y a qu'un pauvre légende avec le nom des téléhones.

[neo76 4]

@bart49

C'est juste un screen du benchmark, vas voir le benchmark complet et tu aura ta légende.

[Alex98 690]

Une simple lecture de l'article d'Anandtech aurait suffit à éviter ce topic.

Pourquoi une telle différence entre les scores max sur le site de GLBenchmark et les scores de l'article d'Anandtech ?

Et bien à cause d'une différence de méthodologie. Les résultats publiés par Anandtech sont obtenu lors d'un run complet de GLBenchmark (tous les tests à la suite) afin de simuler un usage réaliste du GPU au cours d'une partie d'un jeu gourmand. A l'inverse, les résultats obtenus via le site de GLBenchmark sont issue de runs individuels (test par test avec une pose entre chaque).

Quel différence cela fait-il ?

Et bien, comme c'est d'ailleurs marqué dans l'article d'Anandtech, le Nexus 4 lorsqu'il est solicité intensivement chauffe beaucoup ce qui, après quelques minutes, l'oblige à réduire sa fréquence GPU afin de ne pas griller son hardware.Ainsi ses performances s'effondrent jusqu'à atteindre un niveau inférieur aux Adreno 225.

A l'inverse en lui laissant le temps de refroidir, il obtient de bien meilleurs scores (comparables à ceux du Optimus G).

Pourquoi l'Optimus G n'a pas ce problème

Là encore, c'est indiquè dans l'article. Le LG Optimus G est incapable de faire un run complet de GLBenchmark. Il affiche un message d'erreur (plus de mémoire pour les textures) bien avant de finir la totalité.

De fait, et de façon contraire à sa méthodologie, Anandtech s'est vu obligé de publié des résultats test par test ce qui n'est, du coup, pas représentatif d'un usage en jeu.

Edit : Précision amusante, des membres XDA avait déjà étaient surpris de voir qu'Anandtech, eux même, avait uploadé de bien meilleurs scores que ceux de leur article. En fait il correspondaient à des runs test par test

Edited November 7, 2012 by Alex98

[sebennett 186]

@Alex98 : merci pour la traduction !

D'après toi ces scores sont cohérent avec le HW ?

Des sources d'inquiétude ? chauffe, performances...

[Divad 24]

Merci pour les infos, là y a matière à réfléchir :).

[Alex98 690]

@Alex98 : merci pour la traduction !

D'après toi ces scores sont cohérent avec le HW ?

Des sources d'inquiétude ? chauffe, performances...

Les Top Scores (obtenus en test par test) sont concordant avec ceux obtenu par le LG Optimus G donc cohérents avec le HW.

Les scores obtenu en un run complet de GLBenchmark sont très bas en revanche MAIS ils sont cohérent avec l'hypothése d'une surchauffe du GPU qui devrait brider sa fréquence.

Par contre c'est effectivement inquiétant. Un GPU qui chauffe c'est normal de nos jours. Par contre, un GPU qui chauffe en quelques minutes au point de devoir appliquer des mesures de sauvegarde c'est inquiétant autant pour son intégrité à long terme que pour ses performances.

En jeu cela signifie que si le jeu utilise pleinement le potentiel de l'Adreno 320, ce dernier ne pourra maintenir ses performances que durant quelques minutes avant de s'effondrer au niveau d'un Adreno 225 bien moins puissant.

Malheureusement on ne peut pas savoir si le problème provient du GPU en lui-même, de son intégration au sein du Nexus 4 ou bien de mauvais drivers.

Le LG Optimus G est incapable de compléter un run intégrale de GLBenchmark et les jeux actuels sont prévus pour des GPU bien moins puissants (genre Tegra 3) donc ne permettent pas de stresser l'Adreno 320 de l'Optimus G pour voir si il a les mêmes problèmes que le Nexus 4. Certains utilisateurs ont toutefois rapporté que l'Optimus G chauffe aussi (mais comme je l'ai dit, les GPU modernes chauffent donc ce critère seul ne prouve rien).

A cela s'ajoute le fait que le Nexus 4 n'est pas encore finalisé du point de vu soft et qu'on ne peut donc que difficilement tirer des conclusions.

[sebennett 186]

D'autres téléphone HDG ont des problèmes pour faire tourner un run complet ?

[AirOne70 307]

Conclusion: Vivement le 15.

(On commencera à avoir des avis concrets)

[Alex98 690]

D'autres téléphone HDG ont des problèmes pour faire tourner un run complet ?

Pas à ma connaissance mais si Qualcomm grave bien ses S4 Pro en 28nm Poly/SiON alors ça ne m'étonne pas forcément.

[Kiiv 17]

C'est à dire ? C'est nul de graver ses processeurs en 28nm Poly/SiON ?

En tout cas merci pour les précision qui complète nécessairement le post initial :)

[sebennett 186]

Pour ce genre de question ici je connais personne de plus informé et pédagogique... ;)

Selon mes recherches il s'agit surtout de semi conducteur....Poly/SiON ou HKMG

http://nanotechwire.com/news.asp?nid=7749

Mais je veux bien quelques précisions quand même...

[Alex98 690]

28nm c'est très bien mais le Poly/SiON est un ancien process de gravure (enfin "ancien" il est encore très utilisé) qui est maintenant remplacé par le High K Metal Gate.

Le Poly/SiON est en fait très peu adapté aux architectures mobiles ayant des voltages élevé car il a des fuites d'énergie relativement élevé (ce qui entraine une surconsommation et donc de la chauffe). ARM recommande d'ailleurs l'usage du HKMG pour toutes les architectures utilisant les jeux d'instruction des A15.

Qualcomm a fait le choix du Poly/SiON pour les S4 pour deux raisons (exprimés publiquement) :

- TSMC avait une capacité de production trop limité pour le 28nm HKMG

- Le 28nm Poly/SiON coûte beaucoup moins cher que le 28/32nm HKMG.

Normalement, Qualcomm devait paser au HKMG pour les S4 Pro mais il semble que, pour des raisons inconnue, ils soient restés sur du Poly/SiON. Du moins c'est ce que suggére le peu d'info que l'on ait

[Divad 24]

http://geekfault.org...ies-au-lithium/

Un billet sur les batteries au lithium. Ça parle de celles pour PC (donc avec un profil d'utilisation différent) mais il n’empêche que la théorie est bien résumée avec quelques conseils.

On retiendra notamment:

Première utilisation: Commencez par décharger votre nouvelle batterie et mettez-la à charger dès qu’elle est vide. Faites deux ou trois cycles complets (décharge jusqu’à 0%, recharge jusqu’à 100%) pour étalonner la puce de contrôle et de mesure.

Ne laissez jamais votre batterie déchargée! Une batterie vide s’abîme rapidement.

Si vous devez stocker votre batterie, chargez-la à environ 40%, un bon compromis face au risque d’auto-décharge.

Edited November 7, 2012 by Divad

[mitsoumithaux 32]

Perso je ferais pas de décharge complète au départ. J'ai toujours entendu dire que les li-ion n'aime pas trop ça...

Après on entend tout et n'importe quoi sur les site... Dur de pécher le faux du vrai...

[matt56k 47]

Merci quand même du sujet Neo76 .

Pour certains , je crois que vous avez trop lu cette phrase : "Les Benchmarks ne veulent rien dire" , vous avez tendance à l'utiliser à tord et à travers et à lâcher cette phrase dès que vous en avez l'occasion .

Vous pensez sérieusement qu'en obtenant du 10Mflops à Linpack (par exemple) vous obtiendrez la même chose qu'avec un téléphone en faisant 400 ? Certes , cela ne veut pas Tout dire . Mais l'indication que les benchmarks nous donne sur le potentiel du téléphone à son importance , pour moi .

Edited November 7, 2012 by matt56k

[Alex98 690]

@ matt56k

Tu as raison sauf sur un point : ton exemple.

Linpack est codé en Java et test les performances de l'interpreteur plus que la puissance de calcule brut du CPU.

On pourrait en tirer des conclusions sur les perfs de calcules que si l'interpretation du Java était identique sur tous les appareils mais ce n'est malheureusement pas le cas (JIT ou pas JIT, optimisation de la machine Dalvik, version de Jazelle, ... influence ENORMEMENT le résultat).

Il est utile par contre pour avoir une idée des perfs de l'interpréteur sur un appareil. Pour avoir une idée des perfs de calcules d'un SoC il vaut mieux un bench en code natif (directement adressé au CPU, pas d'interpréteur software).

[matt56k 47]

Salut Alex !

Tu a l'air de bien t'y connaitre et je ne savais pas ce que tu viens de dire :) . Mais cela étant dit , cela me ferai plaisir que l'on n'hurle pas sur une personne sous prétexte qu'elle ait parlé d'un simple Benchmark ... Pourvu que ça ne se généralise pas .

Bye !

[Criketj 679]

http://geekfault.org...ies-au-lithium/

Un billet sur les batteries au lithium. Ça parle de celles pour PC (donc avec un profil d'utilisation différent) mais il n’empêche que la théorie est bien résumée avec quelques conseils.

On retiendra notamment:

Première utilisation: Commencez par décharger votre nouvelle batterie et mettez-la à charger dès qu’elle est vide. Faites deux ou trois cycles complets (décharge jusqu’à 0%, recharge jusqu’à 100%) pour étalonner la puce de contrôle et de mesure.

Ne laissez jamais votre batterie déchargée! Une batterie vide s’abîme rapidement.

Si vous devez stocker votre batterie, chargez-la à environ 40%, un bon compromis face au risque d’auto-décharge.

Désolé mais "bullshit".

D'ailleurs pour preuve simple, sur toutes les notices de ce genre d'appareil intégrant une batterie li-ion ou poly-ion, il est écrit noir sur blanc de charger la batterie dés le début.