Un simulateur gate level d'ARM1 en Javascript : http://visual6502.org/sim/varm/armgl.html
Sexy non ?
Un simulateur gate level d'ARM1 en Javascript : http://visual6502.org/sim/varm/armgl.html
Sexy non ?
Oui, maintenant ARM dit publiquement d'ou viennent les designs
http://www.anandtech.com/show/10347/...temis-unveiled
The A5, A7 and A53 belong to the Cambridge family while the Cortex A12, A17 and today's new A73 belong to the Sophia family, owning its name to the small city of Sophia-Antipolis which houses one of Europe's largest technology parks as well as ARM's French CPU design centre.
Est-ce que qu'on doit déduire du diagramme en page 2 que la lecture des opérandes ne prend pas un étage de pipe dédié? Vu qu'il y a un PRF et vu la fréquence j'aurais pensé le contraire (mais c'est pas comme si j'étais designer).
EDIT: Ou alors c'est le deuxième cycle des files devant les pipes d'exécution.
Je note aussi :
Alors, si je sais compter, pour avoir un L1 VIPT de 64KB il faut en effet qu'il soit 16-way associative, ce qui fait a priori beaucoup pour un L1 (surtout à deux loads/cycle). Ce qui explique, j'imagine le "the cache is implemented with 4-way associativity", mais j'ai un peu de mal à le comprendre.In hardware the cache is implemented with 4-way associativity but the software sees it as a PIPT 8-way 32kB or 16-way 64KB cache
Le seul truc ayant un peu de sens que j'arrive à imaginer, c'est qu'il y a 4 banks et l'entrelacement se fait sur la ligne. Du coup c'est "au pire" 4-way associative et "au mieux" 8/16-way (dans le sens ou 8/16 lignes en conflits dans un direct-mapped sont dans le cache en même temps). Après, entrelacer sur les lignes, je sais qu'Intel ne le fait pas (donc par extension c'est forcément une mauvaise idée ). Au moins ça permet de ne comparer que 4 tags et ne sortir que 4 lignes, tout en gardant une associativité élevée si ça se passe bien. Dans les autres possibilités il y a bien sûr : Le gars d'AnandTech n'a rien compris, et le classique : J'ai rien compris .
Envoyé par François
Question du coup :
Le A9, c'est du Austin ? Et le A8, c'est quoi ?
Merci !
Allez le petit funfact du jour : http://www.mono-project.com/news/201.../arm64-icache/
TL;DR ou presque : Comme chez ARM le cache d'instructions ne reste pas cohérent avec le cache de données (c'est peut-être plus subtil mais admettons pour le moment), les JITs (tel mono) flushent explicitement le cache d'instruction quand c'est nécéssaire. Problème, avec big.LITTLE, il est possible d'avoir des lignes de cache d'instruction de taille différentes entre les coeurs big et LITTLE (merci Samsung et ses lignes de 128 bytes). Donc si on ne calcule pas la taille de la ligne à chaque invocation de la fonction qui flushe le I-Cache, ça part en sucette. Et même si on la calcule à chaque invocation, on peut très bien se faire déplacer d'un big vers un LITTLE (ou l'inverse) pendant la fonction qui flushe.
Dernière modification par Thamior ; 12/09/2016 à 22h48.
Envoyé par François
Ils sont pas très bons intel sur ce slide .
C'est un comparo intel/amd, mais comme c'était pendant le armsummit, j'ai mis ça là. (Il y a peut être moyen de trouver de meilleures sources/slides/enregistrements avec des commentaires intéressants ailleurs. J'ai juste survolé le truc).
Normal, globalement plus tu as de la bande passante vers ta DRAM, plus tu es vulnérable à Rawhammer.
On en avait parlé dans les topics sécu et process aussi.
En tout cas, j'aurais appris que la dram ça scale mal vers l'infiniment petit. C'est connu depuis longtemps ? Même si ça parait logique que la capa doit garder une taille raisonnable.
Question subsidiaire : Est-ce que la sram pourra être un jour plus dense que la dram ou je suis complètement à côtéde la plaquedu wafer ? (En admettant qu'on puisse caser 6Transistors dans un espace plus réduit qu'une capa).
Ouais, avec ma licence architecture, je peux même concevoir mes propres calembours compatibles Thamior.
Et tu passes les suites de validation ? Ou tu le fais a la chinoise ?
Merci. Les slides de Hot Chips sont aussi dispo maintenant : http://www.hotchips.org/wp-content/u...-23_51-v11.pdf
L'implication de la largeur de vecteur dépendant de l'implèm, c'est que si je fais une réduction sur des flottants, mon binaire compilé va donner un résultat différent entre un core et un autre ? J'ai pas compris l'histoire des ordered horizontal reductions.
Dernière modification par Møgluglu ; 08/11/2016 à 21h35.
Faire iterativement la reduction revient a maintenir l'associativite et donc le resultat, non ? C'est sur que du coup ce n'est pas ce qu'il y a de plus efficace en terme de vitesse.
gcc arrive :
[RFC] GCC port for ARM's Scalable Vector Extension
Le svn du code.
Va plus manquer que le simulateur
Oui mais quel est l'intérêt de vectoriser sur une machine à back-end SIMD ?
i.e. si j'ai bien compris il y a une instruction qui prend un vecteur a et qui calcule :
en 3n ou 4n cycles de manière plus ou moins atomique. Et tu l'appelles en boucle sur des tranches successives d'un tableau.Code:a0 + a1 + a2 ... + a(n-1)
Avec un back-end vectoriel à la Cray, tu peux éventuellement arriver à pipeliner et entrelacer l'exécution de cette instruction avec d'autres instructions du même type (genre des multiplications si tu fais un produit scalaire). Mais ça n'a pas l'air le modèle d'exécution de SVE. Si c'est pour avoir une instruction bloquante autant rester en (super)scalaire, où on peut masquer les latences intermédiaires avec d'autres opérations.
Je comprends la meme chose que toi sur le cote iteratif (je ne veux pas verifier, sinon je ne peux plus repondre).
Pourquoi cela devrait-il etre atomique ? Tu envoies n-1 micro-ops et c'est regle, tu pourras faire plein d'autres trucs en meme temps :D Mais c'est vrai que ca risque de devenir le goulot d'etranglement sur un produit scalaire. Il est probable qu'il vaille mieux faire les reductions a la main en log(n) instructions si on accepte/quantifie le changement d'ordre d'evaluation.
Apres ptet qu'il existe des instructions de reduction qui ne preservent pas l'ordre, ou ptet qu'on n'a rien compris et qu'il n'y a que ces dernieres. Du coup, si on veut maintenir l'ordre il faudrait faire la reduction de maniere explicite.
Ca n'aide pas trop ce que je raconte hein