Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 28 sur 30 PremièrePremière ... 182021222324252627282930 DernièreDernière
Affichage des résultats 811 à 840 sur 883
  1. #811
    Un simulateur gate level d'ARM1 en Javascript : http://visual6502.org/sim/varm/armgl.html
    Sexy non ?

  2. #812
    wicked !
    fefe - Dillon Y'Bon

  3. #813

  4. #814
    Spirituellement, c'est plus le fils de l'A12/A17

  5. #815
    Citation Envoyé par newbie06 Voir le message
    Spirituellement, c'est plus le fils de l'A12/A17
    J'ai vu ça en commençant à lire l'article (mais il est quand même marketé comme le successeur au A72?).


  6. #816
    Cocorico?
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  7. #817
    Citation Envoyé par Thamior Voir le message
    Cocorico?
    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.

  8. #818
    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 :

    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
    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.

    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 .
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  9. #819
    Question du coup :

    Le A9, c'est du Austin ? Et le A8, c'est quoi ?

  10. #820
    Citation Envoyé par Dandu Voir le message
    Question du coup :

    Le A9, c'est du Austin ? Et le A8, c'est quoi ?
    A9 c'est Sophia et A8 Austin.

    @Thamior: pas le droit de repondre

  11. #821

  12. #822
    Citation Envoyé par newbie06 Voir le message
    @Thamior: pas le droit de repondre
    Je sais bien, c'est une question rhétorique pour toi et ouverte pour les autres
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  13. #823

  14. #824
    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 à 23h48.
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  15. #825
    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).

  16. #826
    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.

  17. #827
    Citation Envoyé par Møgluglu Voir le message
    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.

    Eyh mais c'est mister memory. C'est le ARM technology summit? C'est intéressant?
    Je me disais aussi que parler de Rowhammer c'était un peu old maintenant (même si c'est toujours d'actualité).
    Dernière modification par Thamior ; 15/09/2016 à 21h20.
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  18. #828
    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 plaque du wafer ? (En admettant qu'on puisse caser 6Transistors dans un espace plus réduit qu'une capa).

  19. #829

  20. #830
    Sympa, ils ont utilisé du microcode pour éviter de prendre des RISC. :thamior:

  21. #831
    Citation Envoyé par Møgluglu Voir le message
    Sympa, ils ont utilisé du microcode pour éviter de prendre des RISC. :thamior:

  22. #832
    T'as une licence pour utiliser ma signature comme ça?
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  23. #833
    Ouais, avec ma licence architecture, je peux même concevoir mes propres calembours compatibles Thamior.

  24. #834
    Et tu passes les suites de validation ? Ou tu le fais a la chinoise ?

  25. #835
    En tout cas on attend encore le tapeout du premier
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  26. #836

  27. #837
    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 à 22h35.

  28. #838
    Citation Envoyé par Møgluglu Voir le message
    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.
    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

  29. #839
    Citation Envoyé par newbie06 Voir le message
    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.
    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 :
    Code:
    a0
       + a1
            + a2
                   ...
                        + a(n-1)
    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.

    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.

  30. #840
    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

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
  •