Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 25 sur 30 PremièrePremière ... 151718192021222324252627282930 DernièreDernière
Affichage des résultats 721 à 750 sur 883
  1. #721
    Merci pour les infos

    Et pour NEON, le souci c'est aussi que pas mal d'Android sont encore en ARMv6...

  2. #722
    Citation Envoyé par dandu Voir le message
    Et pour NEON, le souci c'est aussi que pas mal d'Android sont encore en ARMv6...
    Hu ? S'pas possible ?!? Genre ARM11

  3. #723
    Merci !
    Bonne nouvelle, je vais arrêter de dire du mal d'ARM jusqu'à la prochaine phrase. Par contre c'est la galère pour trouver de la doc en accès libre qui soit à peu près à jour.

    J'ai trouvé ça : http://board.flatassembler.net/download.php?id=5698
    C'est illisible mais ça a l'air bien, il y a même l'instruction FCVTXN qui semble faire de l'arrondi impair (round to odd / Von Neumann rounding).

  4. #724
    Ca arrive encore parfois, même en 2013. Ca reste rare, ceci dit, depuis l'arrivée des Cortex A8 d'entrée de gamme. Mais y a encore beaucoup de modèles sur le marché, donc c'est souvent encore supporté, contrairement à Apple qui a arrêté l'ARM11 y a un moment et qui a coupé la compatibilité.

    Il reste dans les trucs vendus le Galaxy Y, le Ace, plus récemment le Nokia 808, etc.

  5. #725
    Citation Envoyé par Møgluglu Voir le message
    Bonne nouvelle, je vais arrêter de dire du mal d'ARM jusqu'à la prochaine phrase. Par contre c'est la galère pour trouver de la doc en accès libre qui soit à peu près à jour.
    Pour ARMv8, ça ne devrait plus trop tarder. Ca sera sous la forme de la doc v7, et ça comprendra à la fois Aarch64 et Aarch32, c'est juste énorme Mais il est probable qu'il faudra un compte sur le site ARM comme pour la doc v7.

    J'ai trouvé ça : http://board.flatassembler.net/download.php?id=5698
    C'est illisible mais ça a l'air bien, il y a même l'instruction FCVTXN qui semble faire de l'arrondi impair (round to odd / Von Neumann rounding).
    Ouai ben dis-toi que ça reste plus lisible que la spreadsheet avec laquelle on bossait et qui changeait une ou deux fois par semaine. Ca a l'air de rien, mais quand tu écris l'assembleur, le désassembleur et le simulateur, ça gave vite

  6. #726
    3DMark vient (enfin) de sortir pour iOS et je suis impressionné par un truc : le Physic Test, qui utilise le CPU.

    Avec un iPad 3 (A5X, dual core Cortex A 9), j'ai péniblement 9 fps. Avec l'iPhone 5 et son dual core Apple, j'ai 25 fps, soit à peu près la même chose que les Snapdragon 800 en quad core avec des fréquences bien plus élevées (qui sont entre 25 et 30 fps) et pas très loin des Exynos Quad (~30 fps). Le seul qui tape beaucoup plus haut c'est le Shield en Tegra 4 (environ 40 fps).

    Qu'est-ce qui peut expliquer un score si bon avec seulement deux cores et une fréquence pas très élevée ? Ils sont vraiment plus rapides ?

  7. #727
    Il faudrait regarder le code genere. Si les mecs qui font 3dmark n'ont pas l'habitude d'Android et ont laisse les options par defaut du NDK, ca pue. C'est librement telechargeable ?

  8. #728
    J'ai jeté un rapide coup d'oeil au binaire de 3dmark pour Android et ce n'est pas du Thumb donc a priori ils n'ont pas utilisé les options pourries par défaut qui viennent avec Thumb. En revanche, aucune utilisation des instructions SIMD.

    Une hypothèse serait que sur iOS les instructions SIMD sont utilisées et que les data path soient tous 128-bit sur Swift, ce qui n'est pas le cas sur Cortex-A9. Une autre serait que Swift peut lancer deux instructions flottantes par cycle (une seule sur A9).

  9. #729

  10. #730
    Je viens de mouiller mon slip deux fois :
    - Intel fait du 100% synthétisable avec Quark
    - et Apple confirme que l'A7 est du 64-bit

  11. #731
    Bon je vais peut-être faire des contre-sens mais si on regarde uniquement les smartphones, j'ai du mal à voir en quoi passer à 64-bit a une utilité. Bon c'est vrai que vu la quantité de RAM le fait d'avoir des pointeurs plus gros doit être relativement sans effet...

    Des idées sur l'impact auquel on peut s'attendre sur la consommation ou la perf exactement?
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  12. #732
    Citation Envoyé par Thamior Voir le message
    Bon je vais peut-être faire des contre-sens mais si on regarde uniquement les smartphones, j'ai du mal à voir en quoi passer à 64-bit a une utilité. Bon c'est vrai que vu la quantité de RAM le fait d'avoir des pointeurs plus gros doit être relativement sans effet mais en soi, ça a quel impact sur la consommation ou la perf?
    Tout d'abord Apple ne regarde pas uniquement les smartphones, leurs SoC sont aussi utilisés dans leurs tablettes. Même s'ils n'ont pas besoin d'un espace d'adressage de 64-bit, un jour pas si lointain il faudra qu'ils puissent adresser sur plus de 32-bit donc autant préparer la transition dès que possible.

    Après il y a quelques avantages architecturaux sur le 64-bit ARM comme enfin des instructions SIMD IEEE

  13. #733
    Surtout un argument marketing actuellement : un smartphone 64 bits, c'est forcément mieux que le 32 bits sous Android

  14. #734
    Citation Envoyé par dandu Voir le message
    Surtout un argument marketing actuellement : un smartphone 64 bits, c'est forcément mieux que le 32 bits sous Android
    Ca fait aussi le jeu d'Intel... Les Atom sont 64 bits. Au pire à un micro fuse près. Ya plus qu'à sur Android.
    Mes propos n'engagent personne, même pas moi.

  15. #735
    Citation Envoyé par Neo_13 Voir le message
    Ca fait aussi le jeu d'Intel... Les Atom sont 64 bits. Au pire à un micro fuse près. Ya plus qu'à sur Android.
    Oui ca va obliger Intel a ne pas fuser. Et Android tourne deja en 64-bit

  16. #736
    Citation Envoyé par dandu Voir le message
    Surtout un argument marketing actuellement : un smartphone 64 bits, c'est forcément mieux que le 32 bits sous Android
    C'est à peu près là ou j'en étais rendu
    Je vois bien le vendeur chez Insérez le nom d'une boutique ici essayer de vendre son iPhone parce qu'il est 64 bits..."Mais si ma bonne dame, il fait du SIMD IEEE en plus".
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  17. #737
    Citation Envoyé par Thamior Voir le message
    C'est à peu près là ou j'en étais rendu
    Je vois bien le vendeur chez Insérez le nom d'une boutique ici essayer de vendre son iPhone parce qu'il est 64 bits..."Mais si ma bonne dame, il fait du SIMD IEEE en plus".
    Et puis le 64 bits ca rend tes informations perso plus sures, ca protege des hackers, ca donne un meilleur gout au cafe et ca rend les couleurs plus vives a l'ecran !
    fefe - Dillon Y'Bon

  18. #738
    Citation Envoyé par fefe Voir le message
    Et puis le 64 bits ca rend tes informations perso plus sures, ca protege des hackers, ca donne un meilleur gout au cafe et ca rend les couleurs plus vives a l'ecran !
    Et ca accelere Internet !

  19. #739
    Citation Envoyé par fefe Voir le message
    Et puis le 64 bits ca rend tes informations perso plus sures, ca protege des hackers, ca donne un meilleur gout au cafe et ca rend les couleurs plus vives a l'ecran !
    Les algos de cryptographie ne sont-ils pas justement parmi les rares exemples à tirer un gain de performances du 64 bits ? Bon, c'est vrai que comparé au hardware dédié de plus en plus courant…
    Mon blog (absolument pas à jour) : Teχlog

  20. #740
    Ca rend la crypto plus rapide si tu as un multiplieur entier 64 bits en hardware, ce qui n'a pas grand chose a voir avec supporter 64 bits d'addressage (les 2 peuvent venir ensemble, ou pas, tu n'as pas besoin du multiplieur pour gerer l'adressage sur 64 bits, juste besoin de l'adder). Qui plus est ca ne rend pas la crypto plus sure, ca la rend plus rapide ! Et tu peux utiliser la vitesse pour changer vers un algorithme plus sur, mais aujourd'hui c'est essentiellement jamais le cas...
    fefe - Dillon Y'Bon

  21. #741
    Et Haswell en bignum c'est une tuerie, ca me console de la temperature delirante

    Sinon la doc ARMv8 est dispo: http://infocenter.arm.com/help/topic...87a/index.html
    Il faut s'enregistrer.

    PS: en crypto rares sont les algos a utliser des mul. Exemple : RSA.

  22. #742
    Citation Envoyé par newbie06 Voir le message
    Et Haswell en bignum c'est une tuerie, ca me console de la temperature delirante
    Ah ouais, merci MULX.


    Il faut s'enregistrer.

  23. #743
    Citation Envoyé par newbie06 Voir le message
    PS: en crypto rares sont les algos a utliser des mul. Exemple : RSA.
    La tu me surprends... Surtout en disant ca 2 lignes apres une histoire de perf en big number...
    fefe - Dillon Y'Bon

  24. #744
    Citation Envoyé par fefe Voir le message
    La tu me surprends... Surtout en disant ca 2 lignes apres une histoire de perf en big number...
    AES/Rijndael par exemple n'utilise pas de multiplication.

    Pour les perf en big number, c'est juste parce que je me suis remis à faire un peu de théorie de nombres calculatoire, et les perf en multi-précision était un des gros arguments d'achat pour Haswell, j'ai quasi fait x2 entre mon i7 920 et mon 4770K

  25. #745

  26. #746
    Ouaip. Même sans ça, les performances d'Oscar sont vraiment impressionnantes.
    Mon blog (absolument pas à jour) : Teχlog

  27. #747
    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 »

  28. #748
    Pour Intel je savais, mais pour Motorola non, tu peux en dire plus ?

  29. #749
    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.

  30. #750
    Ah mais Anand n'a pas dit que Motorola ne trichait pas, il affirme juste qu'il ne trichent pas avec cette "optimisation"-là, du moins sur les modèles récents.

    With the exception of Apple and Motorola, literally every single OEM we’ve worked with ships (or has shipped) at least one device that runs this silly CPU optimization. It's possible that older Motorola devices might've done the same thing, but none of the newer devices we have on hand exhibited the behavior.
    Donc ça change tout.

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
  •