Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 26 sur 30 PremièrePremière ... 1618192021222324252627282930 DernièreDernière
Affichage des résultats 751 à 780 sur 883
  1. #751
    Citation Envoyé par dandu Voir le message
    Ben si Intel triche en compilant AnTuTu, les benchs sur un smartphone en Intel (genre Motorola) sont faussés. Motorola triche pas directement, mais dans les faits, ça change rien.
    Ha OK, je comprends mieux. On va dire que je suis biaise, mais je trouve les truanderies de benchmarks par compilo a la Intel/AnTuTu bien plus dommageables que ce que font les fabricants de telephone ; quand en plus on voit le forcing d'Intel pour imposer icc a la communaute Android...

    Mais dans tous les cas ces tricheries d'ou qu'elles viennent me degoutent.

    Personnellement j'en suis arrive au point que je ne crois plus rien, ni personne. Si je ne peux pas compiler le code moi-meme et le faire tourner, je doute

  2. #752
    Citation Envoyé par dandu Voir le message
    Anandtech qui considère que Motorola triche pas dans les benchs, c'est priceless quand même : http://www.anandtech.com/show/7384/s...oid-benchmarks

    Ou alors c'est de la jolie rhétorique, genre « c'est pas Motorola/Intel qui triche, c'est les utilitaires qui sont cheatés à la base »
    C'est marrant, cet article est sorti rapidement après que AnandTech se soit fait flammer dans les commentaires au sujet des cheats Samsung qui n'étaient pas évoqués dans la review du dernier Note.

    Sinon je ne comprends pas pourquoi cheat* est beaucoup moins utilisé (1x dans le titre - c'est déjà ça - , 1x dans le tableau, 3x dans le texte) que optimiz* qui est utilisé 36x dans l'article. Ce n'est pas en galvaudant le mot optimisation que les choses vont avancées mais en appelant un chat un chat, le choix des termes est plus qu'étrange.

  3. #753
    Dans la majorité des articles sur le sujet que j'ai lu, les lecteurs semblent trouver ça normal, en plus. Genre « il tourne au maximum prévu par le constructeur, c'est normal ».

    Et franchement, je pense (après c'est un avis) que Intel et NVIDIA triche aussi d'une façon ou d'une autre dans les benchs, mais qu'ils le font de façon plus discrète.

    Et affirmer qu'Apple triche pas, c'est pas non plus très judicieux : on n'a pas de base de comparaison fiable et pas de moyen simple de vérifier qu'iOS détecte pas des exécutables de benchs. Voir que le compilateur Apple modifie pas certains trucs comme le compilateur Intel.

  4. #754
    Citation Envoyé par dandu Voir le message
    Voir que le compilateur Apple modifie pas certains trucs comme le compilateur Intel.
    Ca on pourra vérifier quand on aura un back-end v8 dans LLVM, enfin ceux qui ont les sources de Geekbench.

  5. #755
    Comme c'est mort ici, j'annonce la prochaine sortie d'un ARM 64-bit Cortex-A53 en 14nm. Merci Intel

    http://www.altera.com/devices/fpga/s...tx10-index.jsp

  6. #756
    Pas mal...

    Quand Altera aura porté son SDK OpenCL sur ARM, ça pourrait faire des jouets intéressants. On pourrait avoir une compétition FPGA vs. GPU à power comparable...

  7. #757
    Mais niveau prix, ça risque de faire mal...

  8. #758
    Oui, Stratix c'est le haut de gamme.

    Mais dans le même temps leur haut de gamme actuel va se démocratiser, avec la gamme Arria en 20nm TSMC :
    dual Cortex-A9 1.5 GHz, support DDR4 2666, et entre 160K et 660K logic elements (assez pour faire des trucs intéressants et suffisamment peu pour espérer un tarif raisonnable).

    Sinon, j'adore le diagramme qui explique pourquoi après le Stratix, Stratix II, Stratix III, Stratix IV et Stratix V, il y a le Stratix 10 :

    Generation 10: Delivering the Unimaginable Breakthrough Advantage... Ou quelque chose comme ça (sur fond de soleil levant devant une boule à facettes).

  9. #759
    Re-test de l'Apple A7 chez Anand :
    http://www.anandtech.com/show/7460/a...d-air-review/2

    Citation Envoyé par Anand
    As far as I can tell, peak issue width of Cyclone is 6 instructions. That’s at least 2x the width of Swift and Krait, and at best more than 3x the width depending on instruction mix. Limitations on co-issuing FP and integer math have also been lifted as you can run up to four integer adds and two FP adds in parallel. You can also perform up to two loads or stores per clock.


    4 ALU ? 2 FMA ? 2 Load-store/cycle ?

    OK, ça tourne à 1.4 GHz et pas à 4 comme Haswell, mais si c'est confirmé c'est un sacré tour de force, là ? Surtout au vu de la conso. Et pour une deuxième itération d'un design partant quasiment de zéro.

  10. #760
    Alors...

    Les 2 LD/ST par cycle, c'est tres probable (vu la densite de ld/st c'est critique sur un design performant).
    Les 2 FMA c'est possible (vu que pour NEON ils sont la).
    Les 4 ALU y'a surement un truc : il parle de 4 adds, donc probablement 2 ALU + 2 AGU. Pour etre sur, il faudrait voir si le bestiau tient 4 OR/AND par cycle.

    Et pour finir 6 issue ca ne veut rien dire. Ca m'etonnerait qu'ils aient mis 6 decodeurs (ca ferait en fait 18 decodeurs : 6 x [ARM, Thumb, Aarch64]). Donc soit Anand a fume, soit il y a un loop buffer avec des uop, et la la BP peut etre de 6.

    Tout ca n'est qu'un point de vue

  11. #761
    Citation Envoyé par newbie06 Voir le message
    Les 2 LD/ST par cycle, c'est tres probable (vu la densite de ld/st c'est critique sur un design performant).
    Les 2 FMA c'est possible (vu que pour NEON ils sont la).
    Les 4 ALU y'a surement un truc : il parle de 4 adds, donc probablement 2 ALU + 2 AGU. Pour etre sur, il faudrait voir si le bestiau tient 4 OR/AND par cycle.
    Certes. Mais plusieurs LD/ST par cycle ça reste complexe à mettre en place...

    Pour les 2 FMA OK, c'est ce qui fait l'intérêt du FMA. Mais ça reste couillu de l'avoir implémenté dans un CPU a priori pas destiné à du calcul intensif (pas un Itanium / Power7 / Haswell...)

    En ARM les AGU envoient directement le résultat aux unités load/store ? Donc pas besoin d'écrire le résultat dans le banc de registre ni d'avoir un réseau de bypass ? Dans ce cas c'est un peu exagéré de parler de 4 adds...

    Et pour finir 6 issue ca ne veut rien dire. Ca m'etonnerait qu'ils aient mis 6 decodeurs (ca ferait en fait 18 decodeurs : 6 x [ARM, Thumb, Aarch64]). Donc soit Anand a fume, soit il y a un loop buffer avec des uop, et la la BP peut etre de 6.
    Oui, là d'accord. D'ailleurs Anand parle de "peak" issue, pas sustained.
    (Mais en principe, ça serait possible d'avoir un décodeur optimisé Aarch64 avec un débit limité dans les autres modes ? Façon x86 avec des décodeurs rapides et des décodeurs lents...)

  12. #762
    Citation Envoyé par Møgluglu Voir le message
    Certes. Mais plusieurs LD/ST par cycle ça reste complexe à mettre en place...
    Ca se fait : par exemple sur le Cortex-A12 ref

    Pour les 2 FMA OK, c'est ce qui fait l'intérêt du FMA. Mais ça reste couillu de l'avoir implémenté dans un CPU a priori pas destiné à du calcul intensif (pas un Itanium / Power7 / Haswell...)
    Ils ont quand meme quelques app gourmandes (traitement photo and co). D'un autre cote, pourquoi ne pas faire du GPGPU ? De toute facon, toute cette discussion reste un amoncellement d'hypotheses...

    En ARM les AGU envoient directement le résultat aux unités load/store ? Donc pas besoin d'écrire le résultat dans le banc de registre ni d'avoir un réseau de bypass ? Dans ce cas c'est un peu exagéré de parler de 4 adds...
    Tu fais ce que tu veux, en n'oubliant pas que de toute facon tes AGU ont besoin d'ecrire dans la banque de registre a cause du writeback d'adresse (post-increment). Donc l'add vient quasiment gratuitement.

    Oui, là d'accord. D'ailleurs Anand parle de "peak" issue, pas sustained.
    (Mais en principe, ça serait possible d'avoir un décodeur optimisé Aarch64 avec un débit limité dans les autres modes ? Façon x86 avec des décodeurs rapides et des décodeurs lents...)
    Oui c'est tout a fait possible, meme en mode 32-bit. Mais meme comme ca j'y crois pas

  13. #763
    Citation Envoyé par newbie06 Voir le message
    Ca se fait : par exemple sur le Cortex-A12 ref
    Ah oui, j'avais pas suivi ça. Bravo.

    Citation Envoyé par newbie06 Voir le message
    Tu fais ce que tu veux, en n'oubliant pas que de toute facon tes AGU ont besoin d'ecrire dans la banque de registre a cause du writeback d'adresse (post-increment). Donc l'add vient quasiment gratuitement.
    Ce(tte saloperie de) post-incrément existe toujours en Aarch64 ?
    Du coup, ils ont bien besoin de 4 ports d'écriture dans le RF et un bypass complet, donc à peu près la même complexité qu'avec 4 ALU ?

  14. #764
    Yep, on a garde le post-increment. Mais un peu plus simple : avec un immediat seulement. Le shift offset est devenu implicite (depend de la taille des operandes).

    Donc globalement simplifie, mais comme le support 32-bit est toujours la...

    Tu sais que tu as acces au manuel 64-bit maintenant ?

  15. #765
    Citation Envoyé par newbie06 Voir le message
    Tu sais que tu as acces au manuel 64-bit maintenant ?
    Le PDF de 40 Mo et 5200 pages qui contient le code de l'émulateur découpé en petits bouts ?
    Maintenant je l'ai, mais au vu du nombre d'instructions LD*, je persiste à penser que ça aurait quand-même été plus rapide de demander ici que de chercher moi-même la réponse dedans.

    Ce qui aurait été top dans la doc, ça aurait été d'avoir pour chaque instruction une phrase de quelque mots expliquant ce qu'elle fait.

    Sinon :
    Comment on fait une multiplication 64-bit signée ?
    C'est quoi la différence entre FMUL et FMULX ? Et entre FRINTI et FRINTX ?
    (Entre TBL et TBX, je suppose que c'est la même qu'entre VTBL et VTBX en Aarch32 ?)
    Il n'y a pas d'instruction pour l'opération minNumMag/maxNumMag d'IEEE-754 2008 (en gros |x|<|y|?x:y) ?
    Pourquoi NV veut dire "always" ? (NV say NV ?)

  16. #766
    Citation Envoyé par Møgluglu Voir le message
    Comment on fait une multiplication 64-bit signée ?
    On fait MUL qui est un alias de MADD (mul + add) avec le registre zero. Si tu veux une operation 64x64 -> 128 tu joues avec UMULH/SMULH qui renvoient la partie haute.

    C'est quoi la différence entre FMUL et FMULX ?
    Ca donne des resultats differents pour zero * infinity. Aucune idee de l'interet

    Et entre FRINTI et FRINTX ?
    S'il y a une partie fractionnaire non nulle FRINTX va mettre le flag inexact.

    (Entre TBL et TBX, je suppose que c'est la même qu'entre VTBL et VTBX en Aarch32 ?)
    Oui.

    Il n'y a pas d'instruction pour l'opération minNumMag/maxNumMag d'IEEE-754 2008 (en gros |x|<|y|?x:y) ?
    FMINM/FMAXNM

    Pourquoi NV veut dire "always" ? (NV say NV ?)
    Oula, une longue histoire Au debut l'encodage de NV etait undef, puis il y a eu une grosse campagne de nettoyage des undefs. Le nom NV est historique il est donc reste en l'etat. Tu remarqueras que meme dans ARMv7 NV est always en tant que predicat d'instruction

  17. #767
    Citation Envoyé par newbie06 Voir le message
    On fait MUL qui est un alias de MADD (mul + add) avec le registre zero. Si tu veux une operation 64x64 -> 128 tu joues avec UMULH/SMULH qui renvoient la partie haute.
    Mais MUL/MADD il fait une multiplication unsigned, d'après le pseudocode...

    Ca donne des resultats differents pour zero * infinity. Aucune idee de l'interet
    0 * infini = 2 ? C'est probablement pour évaluer certaines fonctions genre sqrt sans se prendre la tête avec les cas tordus.

    S'il y a une partie fractionnaire non nulle FRINTX va mettre le flag inexact.
    FRINTI aussi, si j'en crois le pseudocode ? Ou j'ai rien compris.

    FMINM/FMAXNM
    Non mais ça c'est juste minNum/maxNum, rien à voir.

    Oula, une longue histoire Au debut l'encodage de NV etait undef, puis il y a eu une grosse campagne de nettoyage des undefs. Le nom NV est historique il est donc reste en l'etat. Tu remarqueras que meme dans ARMv7 NV est always en tant que predicat d'instruction
    OK.
    Dommage, s'il avait été mappé sur never, ça aurait permis de récupérer l'acronyme (et avoir plein de NOP...)

  18. #768
    Citation Envoyé par Møgluglu Voir le message
    Mais MUL/MADD il fait une multiplication unsigned, d'après le pseudocode...
    Tu t'en fiches pour la partie basse non ?

    0 * infini = 2 ? C'est probablement pour évaluer certaines fonctions genre sqrt sans se prendre la tête avec les cas tordus.
    Ha c'est donc ca, merci

    FRINTI aussi, si j'en crois le pseudocode ? Ou j'ai rien compris.
    T'as mal compris Le rmode vaut 111 pour FRINTI, donc exact n'est pas mis a true.

    Non mais ça c'est juste minNum/maxNum, rien à voir.
    Du coup on n'est pas full ieee 2008?

  19. #769
    Citation Envoyé par newbie06 Voir le message
    Tu t'en fiches pour la partie basse non ?
    Ah oui je suis con, c'est pareil en complément à 2.

    T'as mal compris Le rmode vaut 111 pour FRINTI, donc exact n'est pas mis a true.
    OK. C'est pas de bol d'avoir du code legacy qui s'attend à ce qu'un arrondi ne touche pas le flag inexact... (ou alors je ne vois pas l'intérêt)

    Du coup on n'est pas full ieee 2008?
    Du moment que vous fournissez un support software pour les langages qui permettent d'exprimer cette opération (C et C++ n'en font pas partie), si. Tu peux très bien être full-IEEE-compliant sur un CPU sans FPU avec la bibliothèque qui va bien.
    (et inversement, ce qui est bien plus courant)

    Des opérations comme ça, il y en a pas mal : nextUp/nextDown, scaleB, logB, copy, negate... (qu'on retrouve dans C99 sous d'autres noms)
    Pour minNumMag, sachant que la norme le définit comme : "minNumMag(x, y) is the canonicalized number x if | x| < | y|, y if | y| < | x|, otherwise minNum(x, y)." c'est pas la mort à faire en soft.
    Mais c'est bien pratique pour les bibliothèques arithmétiques et c'est trivial à faire en matériel. Après c'est un détail, il n'y a guère que l'IA-64 qui l'a (famin/famax), et ça n'a du atterrir dans la norme qu'à grands coups de lobying.

    Par contre FCVTXN est une bonne idée. Ça permet de faire plusieurs arrondis successifs en garantissant la propriété d'arrondi correct à la fin. C'est difficile à émuler en soft.
    Pour autant que je sache ARM est le premier à le faire (enfin dans les 50 dernières années, Von Neumann ne compte pas...) IBM a aussi ce mode d'arrondi depuis le Power 6, mais il est seulement utilisable sur le flottant décimal.
    Maintenant, on aimerait bien avoir ce mode d'arrondi sur toutes les opérations et en particulier l'addition ou FMA, pas juste sur l'arrondi vers entier...

  20. #770
    Je trouve ça sexy : PNNL First Customer of BrownDwarf Y-Class Supercomputer. ARM + DSP
    Mais je suis un pervers, je trouvais le Cell intéressant

    Ceci dit l'efficacité énergétique semble être pas mal.

  21. #771
    Y'a de la double précision sur les TMS320C66x ?

  22. #772
    Citation Envoyé par Møgluglu Voir le message
    Y'a de la double précision sur les TMS320C66x ?
    Y'a toujours eu de la DP sur les C6x FP. Avec le C66, les SP passent en SIMD.

    Jeu d'instruction : http://www.ti.com/lit/ug/sprugh7/sprugh7.pdf

  23. #773
    Citation Envoyé par newbie06 Voir le message
    Y'a toujours eu de la DP sur les C6x FP. Avec le C66, les SP passent en SIMD.

    Jeu d'instruction : http://www.ti.com/lit/ug/sprugh7/sprugh7.pdf
    Merci. Finalement le Cell c'était vachement simple à programmer.

    Mais j'ai quand-même l'impression que leurs 500 Gflops/node et 7 Gflops/W sont en SP.
    4 ARM A15 cores and 24 C66x DSP cores are organized into 48 nodes per chassis running Linux on the ARM cores. Each chassis delivers 23.1TFLOPS (SP) of ARM+DSP processing power.
    Donc si on divise par deux, c'est un peu moins impressionnant, surtout pour des perfs crête sur un archi disons... non-conventionnelle.

    Pour l'efficacité énergétique, il serait temps de faire quelque-chose, parce que Nvidia truste sérieusement le podium...
    http://green500.org/lists/little201311

  24. #774
    Hum ça fait ~20 GFLOPS/DSP. Donc je dirais aussi SP.

  25. #775
    http://chromasoft.blogspot.com/2013/...neon-code.html

    Y'a des docs a part le reference manual ?
    fefe - Dillon Y'Bon

  26. #776
    Citation Envoyé par fefe Voir le message
    http://chromasoft.blogspot.com/2013/...neon-code.html

    Y'a des docs a part le reference manual ?
    Pas a ma connaissance.

  27. #777
    Et il n'y a pas d'intrinsics, même spécifiques à gcc ?

  28. #778
    Citation Envoyé par Møgluglu Voir le message
    Et il n'y a pas d'intrinsics, même spécifiques à gcc ?
    Si, il y en a. Quant a leur compatibilite llvm vs gcc, je ne sais pas, mais je pense que ce sont les memes.

  29. #779
    Calxeda, qui concevait des SoC à base d'ARM pour micro-serveurs, vient de fermer ses portes

    http://www.wired.com/wiredenterprise/2013/12/calxeda/

  30. #780

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
  •