Crunchez vos adresses URL
|
Calculez la conso électrique de votre PC
|
Hébergez vos photos
Page 24 sur 29 PremièrePremière ... 141617181920212223242526272829 DernièreDernière
Affichage des résultats 691 à 720 sur 869
  1. #691
    Cortex-A12 chez AT : http://www.anandtech.com/show/7126/t...the-cortex-a12

    Ca donne moins d'infos que je voudrais, mais il va falloir s'en contenter pour le moment.

    ---------- Post added at 20h37 ---------- Previous post was at 20h36 ----------

    Citation Envoyé par fefe Voir le message
    L'essentiel du code qui tourne sur les x86 actuels est compile avec -g et sans -O . En 30 ans ca n'a jamais change, j'ai jamais reussi a gagner cette bataille .
    Ha tiens, j'avais rate un truc : ca fait longtemps que -g ne change plus rien au code genere en tout cas sur gcc. Y'a des compilos pour lesquels ca change quelque chose ?

  2. #692
    Citation Envoyé par newbie06 Voir le message
    Cortex-A12 chez AT : http://www.anandtech.com/show/7126/t...the-cortex-a12

    Ca donne moins d'infos que je voudrais, mais il va falloir s'en contenter pour le moment.
    C'est intéressant, les changements par rapport au Cortex A9 sont plus importants que ce à quoi je m'attendais. J'ai tout de même deux questions :

    — Pourquoi pas de support d'ARMv8 ? Est-ce un choix technique ou une simple question de timing ?
    — ARM insiste sur l'importance croissante des flottants, en citant notamment les interfaces graphiques. Là, je vois bien, mais les diapos évoquent aussi des new data types, et là je ne vois pas trop à quoi ils font référence.
    Mon blog (absolument pas à jour) : Teχlog

  3. #693
    En Javascript, toutes les variables numériques sont des flottants double précision tant qu'on n'a pas prouvé qu'ils sont entiers, non ? (oui, c'est horrible)

  4. #694
    Citation Envoyé par Alexko Voir le message
    — Pourquoi pas de support d'ARMv8 ? Est-ce un choix technique ou une simple question de timing ?
    Un peu des deux : ajouter le 64-bit n'est pas tres complique fonctionnellement, mais si tu veux le faire bien, le cout en temps de dev grimpe tres vite ; par ailleurs, le cout en consommation et en surface n'est pas negligeable. Par ailleurs, d'ici a ce que les premiers appareils utilisant le Cortex-A12 arrivent sur le marche, le 64-bit ne sera probablement pas encore une necessite, donc autant gagner du temps et de la surface

    — ARM insiste sur l'importance croissante des flottants, en citant notamment les interfaces graphiques. Là, je vois bien, mais les diapos évoquent aussi des new data types, et là je ne vois pas trop à quoi ils font référence.
    Aucune idee...

    ---------- Post added at 17h15 ---------- Previous post was at 17h14 ----------

    Citation Envoyé par Møgluglu Voir le message
    En Javascript, toutes les variables numériques sont des flottants double précision tant qu'on n'a pas prouvé qu'ils sont entiers, non ? (oui, c'est horrible)
    Ca n'en fait pas des "new data types", si ? De toute facon, il me semble que les double disparaissent assez vite sur des engins assez performants comme Google v8.

  5. #695
    C'est ce que je retiens de cette slide (outre le fait que chez ARM on ne sait pas conjuguer )

  6. #696
    Hum pourquoi donc Alexko a-t-il parle d'interface graphique alors ?

    C'est casted qui te gene ? Perso j'aime bien l'absence de 'z', so British

  7. #697
    C'est sur une autre slide où ils parlent de Neon et FP.

    Au tank pour moi, les brits ont raison, on dit bien casted.

  8. #698
    Citation Envoyé par Møgluglu Voir le message
    En Javascript, toutes les variables numériques sont des flottants double précision tant qu'on n'a pas prouvé qu'ils sont entiers, non ? (oui, c'est horrible)
    Ah ouais quand même.

    Citation Envoyé par newbie06 Voir le message
    Un peu des deux : ajouter le 64-bit n'est pas tres complique fonctionnellement, mais si tu veux le faire bien, le cout en temps de dev grimpe tres vite ; par ailleurs, le cout en consommation et en surface n'est pas negligeable. Par ailleurs, d'ici a ce que les premiers appareils utilisant le Cortex-A12 arrivent sur le marche, le 64-bit ne sera probablement pas encore une necessite, donc autant gagner du temps et de la surface
    OK, merci.

    Citation Envoyé par newbie06 Voir le message
    Hum pourquoi donc Alexko a-t-il parle d'interface graphique alors ?
    Ils en parlent ici :

    Mon blog (absolument pas à jour) : Teχlog

  9. #699
    Hum ptet que certains CODEC utilisent massivement les floats maintenant ? Ou bien les structures pour la 3D ou les engins physiques ? Sinon je ne vois pas bien...

  10. #700
    NEON, c'est du SIMD entier aussi, non ? NEON pour les codecs pas gérés en matériel et l'UI, et VFP pour le code Javascript dégeulasse.
    (puis d'abord, NEON c'est pas du vrai flottant, c'est même pas compatible IEEE-754 )

    NEON et VFP, c'est les mêmes ports (et unités ?) d'exécution de toute façon ?

  11. #701
    Citation Envoyé par Møgluglu Voir le message
    NEON et VFP, c'est les mêmes ports (et unités ?) d'exécution de toute façon ?
    Sur A9 pas tout à fait, sur A12 oui.

  12. #702
    Anandtech qui montre que Samsung triche avec le Galaxy S 4 en détectant les benchs : http://www.anandtech.com/show/7187/l...ons-galaxy-s-4

    Le GPU monte 10 % plus haut en fréquence et le CPU est forcé sur la partie A15...

  13. #703
    Moui il fallait bien s'attendre a ce genre de manips lamentable.

    Un peu etonne quand meme qu'Anand reprenne un truc qu'on a vu sur B3D il y a quelques semaines deja, alors qu'ils n'ont pas parle du truandage d'AnTuTu par le compilateur d'Intel. En fait non, je ne suis pas si etonne

  14. #704
    Citation Envoyé par newbie06 Voir le message
    Un peu etonne quand meme qu'Anand reprenne un truc qu'on a vu sur B3D il y a quelques semaines deja, alors qu'ils n'ont pas parle du truandage d'AnTuTu par le compilateur d'Intel. En fait non, je ne suis pas si etonne
    Ha ben, on dirait que Tom's Hardware FR a fait pareil : on tape sur Samsung et pas sur AnTuTu/Intel ?

  15. #705
    On a parlé d'AnTuTu et Intel, non ? En tout cas, mon collègue est venu lire ici quand j'étais en vacances, j'en ai discuté avec lui. (c'est moi qui ai parlé de Samsung hier)

  16. #706
    Citation Envoyé par dandu Voir le message
    On a parlé d'AnTuTu et Intel, non ? En tout cas, mon collègue est venu lire ici quand j'étais en vacances, j'en ai discuté avec lui. (c'est moi qui ai parlé de Samsung hier)
    Je n'ai trouvé aucun article sur AnTuTu/Intel sur Tomshardware.fr. Mon Google-fu s'émousserait-il ?

  17. #707
    T'as raison : y a un truc prévu dans l'admin du site, mais rien de publié. Je vais essayer de m'en occuper du coup.

    ---------- Post added at 14h49 ---------- Previous post was at 12h53 ----------

    Marrant : le souci avec AnTuTu, c'était avec le S 4 de Samsung, qui détecte justement AnTuTu :D
    Ca rend l'analyse encore plus drole

  18. #708
    Citation Envoyé par dandu Voir le message
    [/COLOR]Marrant : le souci avec AnTuTu, c'était avec le S 4 de Samsung, qui détecte justement AnTuTu :D
    Ca rend l'analyse encore plus drole
    Il y a tout le reste :
    - utilisation d'icc sur Android
    - benchmark spécifiquement truandé par icc
    - date de releases respectives d'icc et d'AnTuTu
    - nouvelle version d'AnTuTu qui voit le score total (i.e. IO/GPU/CPU) plonger de 20% après modifications
    - version ARM optimisée pour la taille.

    Mais c'est vrai qu'il y a là une certaine ironie

    Je me demande de combien baisse le score d'AnTuTu si on enlève le hack de Samsung.

  19. #709
    Un nouvel article sur Cortex-A12 chez Linley.

    PS - Dandu, merci pour ton boulot

  20. #710
    Pour « benchmark spécifiquement truandé par icc », je suppose que les parties du code pas exécutée qui boostent le score, c'est pas un bug, donc ? On a une preuve de ça ?

    ---------- Post added at 12h19 ---------- Previous post was at 12h18 ----------

    Il est payant, l'article sur le A12

  21. #711
    Citation Envoyé par dandu Voir le message
    Pour « benchmark spécifiquement truandé par icc », je suppose que les parties du code pas exécutée qui boostent le score, c'est pas un bug, donc ? On a une preuve de ça ?
    C'est bien plus complique que ca. Le code optimise est bien execute mais se reduit quasiment a un memset.

    Je t'invite a lire deux posts (tres techniques) sur le forum Anandtech:
    - presentation generale
    - un post qui montre comment en variant a peine le code incrimine on fait disparaitre l'optim.

    Un truc vraiment amusant est que des qu'on compile en 64-bit l'optim disparait completement quoi qu'on fasse, alors que de toute evidence elle boosterait enormement le bench. Ha oui c'est sur Android x86, c'est du 32-bit

    Donc non, on ne prouvera jamais que le compilo triche, mais a mon humble avis il y a fort peu de doute que ce soit le cas.

    Il est payant, l'article sur le A12
    Ha mince, on doit avoir un abonnement au boulot

  22. #712
    je comprends un peu l'assembleur et je vois bien le problème, j'en ai fait il y a quelques années (bon, du x86 16 bits, mais je comprends le souci)

  23. #713
    Y a des rumeurs sur un ARMv8 64 bits dans le prochain iPhone (Apple A7), vous en pensez quoi ? Possible ? Est-ce qu'Apple peut proposer si tôt un CPU 64 bits ? (là : http://www.macrumors.com/2013/08/25/...tion-tracking/)

    Et est-ce que le 64 bits lui-même peut apporter un gros gain (comme sur x86 en son temps) ?

  24. #714
    Citation Envoyé par dandu Voir le message
    Y a des rumeurs sur un ARMv8 64 bits dans le prochain iPhone (Apple A7), vous en pensez quoi ? Possible ? Est-ce qu'Apple peut proposer si tôt un CPU 64 bits ? (là : http://www.macrumors.com/2013/08/25/...tion-tracking/)
    Difficile de savoir quoi que ce soit avec Apple, j'ai même été surpris que l'A6 utilise leur propre coeur au lieu d'un A9 survitaminé

    Et est-ce que le 64 bits lui-même peut apporter un gros gain (comme sur x86 en son temps) ?
    Y'a vraiment eu un gros gain avec x86_64 ? Hors besoin explicite de 64-bit, il m'a toujours semblé que les CPU Intel ne gagnaient pas beaucoup à passer en 64-bit (c'est peut-être différent chez AMD).

    Pour v8, le but était principalement (en-dehors bien entendu des 64-bit d'adresse et données) de passer à 32 registres (utile même si ça aura encore moins d'impact que le passage de 8 à 16 chez Intel) et de simplifier ce qui était pénible pour les micro-architectures (par exemple les problèmes de renaming sur des ld/st multiple -> on fait juste du ld/st pair).

    Bref rien de fondamentalement plus rapide. De toute façon arrivé à un certain niveau de performance, le jeu d'instructions en lui-même impacte au final assez peu les performances brutes, il peut juste être pénible et plus coûteux à implémenter dans certaines parties.

  25. #715
    Je pense que ça dépend surtout du compilo et ses options.
    x86-64 a beaucoup amélioré la perf en pratique, pas grâce aux instructions 64 bits mais parce que les compilos ont pu enfin utiliser SSE2 par défaut.

    Sur ARM, cet effet devrait être nettement moins marqué... à part si Google en profite pour changer les flags de compil par défaut du NDK. (pour Apple, on connaît les flags utilisés ?)

    Au fait il n'y a pas de mode Thumb en ARM64 ? Donc en pratique on passerait plutôt de Thumb32 à ARM64 ?

  26. #716
    Citation Envoyé par Møgluglu Voir le message
    Je pense que ça dépend surtout du compilo et ses options.
    x86-64 a beaucoup amélioré la perf en pratique, pas grâce aux instructions 64 bits mais parce que les compilos ont pu enfin utiliser SSE2 par défaut.

    Sur ARM, cet effet devrait être nettement moins marqué... à part si Google en profite pour changer les flags de compil par défaut du NDK. (pour Apple, on connaît les flags utilisés ?)

    Au fait il n'y a pas de mode Thumb en ARM64 ? Donc en pratique on passerait plutôt de Thumb32 à ARM64 ?
    Si je ne m'abuse, NEON est optionnel sur ARMv7, mais obligatoire sur ARMv8. Du coup, l'effet SSE2 ne pourrait-il pas se reproduire ?
    Mon blog (absolument pas à jour) : Teχlog

  27. #717
    Seulement pour le calcul entier alors. L'arithmétique virgule flottante vient d'être standardisée il n'y a même pas 30 ans, et NEON n'est pas encore compatible, contrairement au 80x87.

  28. #718
    Citation Envoyé par Møgluglu Voir le message
    Seulement pour le calcul entier alors. L'arithmétique virgule flottante vient d'être standardisée il n'y a même pas 30 ans, et NEON n'est pas encore compatible, contrairement au 80x87.
    Le SIMD ARMv8 est compatible IEEE754-2008, nanmého

    ---------- Post added at 14h42 ---------- Previous post was at 14h42 ----------

    Citation Envoyé par Alexko Voir le message
    Si je ne m'abuse, NEON est optionnel sur ARMv7, mais obligatoire sur ARMv8. Du coup, l'effet SSE2 ne pourrait-il pas se reproduire ?
    Seul T2 n'a pas de NEON (dans les SoC grand public). C'est plutôt le fait que NEON devienne IEEE qui fait que la vectorisation devrait être plus généralisée.

    ---------- Post added at 14h44 ---------- Previous post was at 14h42 ----------

    Citation Envoyé par Møgluglu Voir le message
    Je pense que ça dépend surtout du compilo et ses options.
    x86-64 a beaucoup amélioré la perf en pratique, pas grâce aux instructions 64 bits mais parce que les compilos ont pu enfin utiliser SSE2 par défaut.
    Je pensais au calcul entier plutôt. Enfin le truc important pour presque tout le monde

    Sur ARM, cet effet devrait être nettement moins marqué... à part si Google en profite pour changer les flags de compil par défaut du NDK. (pour Apple, on connaît les flags utilisés ?)
    Je pense que le SDK d'Apple est plus tuné, mais ça utilise clang.

    Au fait il n'y a pas de mode Thumb en ARM64 ? Donc en pratique on passerait plutôt de Thumb32 à ARM64 ?
    Nan.

  29. #719
    Citation Envoyé par newbie06 Voir le message
    Le SIMD ARMv8 est compatible IEEE754-2008, nanmého
    Victory !

    Enfin tu voulais dire IEEE754-1985 ? Le FMA est obligatoire pour avoir le tampon 2008.
    D'après le Powerpoint, ARMv8 a "certaines features d'IEEE754-2008", qui sont... min, max, et la conversion vers entier avec arrondi financier.


    Nan.
    Nan pour la première ou pour la deuxième question ?

  30. #720
    Citation Envoyé par Møgluglu Voir le message
    Victory !

    Enfin tu voulais dire IEEE754-1985 ? Le FMA est obligatoire pour avoir le tampon 2008.
    D'après le Powerpoint, ARMv8 a "certaines features d'IEEE754-2008", qui sont... min, max, et la conversion vers entier avec arrondi financier.
    FMA est bien là. Le tie to away aussi. Je pense qu'il y a tout

    Nan pour la première ou pour la deuxième question ?
    Nan pas de T64. A priori ARM et T32 sont assez proches.

Page 24 sur 29 PremièrePremière ... 141617181920212223242526272829 DernièreDernière

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •