Jump to content

Benchmark Nexus 4


neo76
 Share

Recommended Posts

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)

2c9H7.png

Voici le resultat du test Egypt HD écran eteint:

KxbX6.png

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 by neo76
Link to comment
Share on other sites

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 by bart49
  • Like 1
Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Alex98
  • Like 1
Link to comment
Share on other sites

@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.

  • Like 2
Link to comment
Share on other sites

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

  • Like 2
Link to comment
Share on other sites

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 by Divad
Link to comment
Share on other sites

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 by matt56k
Link to comment
Share on other sites

@ 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).

Link to comment
Share on other sites

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 !

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...