Merci pour les infos
Et pour NEON, le souci c'est aussi que pas mal d'Android sont encore en ARMv6...
Merci pour les infos
Et pour NEON, le souci c'est aussi que pas mal d'Android sont encore en ARMv6...
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).
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.
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.
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 viteJ'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).
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 ?
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 ?
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).
OK, merci
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
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?
Envoyé par François
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
Surtout un argument marketing actuellement : un smartphone 64 bits, c'est forcément mieux que le 32 bits sous Android
Mon blog (absolument pas à jour) : Teχlog
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
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.
Ah ouais, merci MULX.
Sinon la doc ARMv8 est dispo: http://infocenter.arm.com/help/topic...87a/index.html
Il faut s'enregistrer.
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
Y'a bon le 64-bit: http://anandtech.com/show/7335/the-iphone-5s-review/4
Ouaip. Même sans ça, les performances d'Oscar sont vraiment impressionnantes.
Mon blog (absolument pas à jour) : Teχlog
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 »
Pour Intel je savais, mais pour Motorola non, tu peux en dire plus ?
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.
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.
Donc ça change tout.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.