Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 29 sur 30 PremièrePremière ... 1921222324252627282930 DernièreDernière
Affichage des résultats 841 à 870 sur 883
  1. #841
    Ça doit être atomique au moins au niveau architectural, i.e. non interruptible. Ça demande que si ta n-1ième µop lève une exception, tu dois remettre l'état architectural comme ta première µop l'a trouvé en arrivant. Pour une réduction qui n'a qu'un résultat ça se fait, mais la logique de contrôle se met à ressembler beaucoup à un séquenceur de microcode.

    Ou alors tu as seulement des instructions du style c=c+a_i pour i donné et c'est à toi d'écrire la boucle autour. Ce qui te fait toujours gagner par rapport à avoir du code qui extrait un par un les scalaires du vecteur.

    Le whitepaper à l'air de suggérer un truc comme ça :
    Regarding the data manipulation instructions, most of the operations cover both floating point (FP) and integer domains, with some notable FP functionality brought by the ordered horizontal reductions, which provide cross-lane operations that preserve the strict C/C++ rules on non-associativity of floating-point operations.
    En cherchant bien on doit pouvoir retrouver une référence à l'instruction exacte dans le code de llvm ou gcc, mais j'ai la flemme. (Mais toi tu peux, le code est public )

  2. #842
    Petite question au cas ou j'aurais loupé ça sur le net. Est-ce que ARM a annoncé publiquement la largeur du Fetch et la tête du prédicteur de branchement pour leurs CPU récents (genre A73)? D'après l'article AnandTech, la largeur serait 2, mais niveau prédicteur pas d'infos (à part le petit BTAC pour cacher les bulles sur les branchements pris mais c'est pas ça qui m'intéresse).
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  3. #843
    Il me semble qu'ARM ne donne plus aucune info "bas niveau" concernant la micro-arch, donc rien sur la bpred

  4. #844
    Et t'as pas le droit de lire les brevets, j'imagine.

    Dommage, moi j'ai trouvé l'info.

    Edit: tiens, y'a les mecs de Cambridge qui citent mes papiers...
    Dernière modification par Møgluglu ; 19/03/2017 à 21h32.

  5. #845
    Citation Envoyé par Møgluglu Voir le message
    Et t'as pas le droit de lire les brevets, j'imagine.

    Dommage, moi j'ai trouvé l'info.

    Edit: tiens, y'a les mecs de Cambridge qui citent mes papiers...
    Techniquement c'est pour un papier donc un des auteurs qui n'est pas moi pourrait lire le brevet et le citer...
    Sinon tant pis, je citerai un exemple de quand les concepteurs de CPUs étaient encore d'accord pour parler de leurs CPUs, genre le MIPS R10000
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  6. #846
    Dans ce cas, retiens juste le numéro 2016/0306632.

  7. #847
    Citation Envoyé par Møgluglu Voir le message
    Dans ce cas, retiens juste le numéro 2016/0306632.
    Fais gaffe un gaffe un peu plus et tu seras le premier résultat



    (J'ai cliqué sur le deuxième lien par inadvertance )


  8. #848
    Citation Envoyé par gregounech Voir le message
    Fais gaffe un gaffe un peu plus et tu seras le premier résultat

    (...)

    (J'ai cliqué sur le deuxième lien par inadvertance )
    Je vais te balancer !

  9. #849
    Citation Envoyé par newbie06 Voir le message
    Je vais te balancer !
    Oops .

    Tiens, pour revenir sur le sujet, ARM annonce le successeur de big.little : http://www.anandtech.com/show/11213/...es-per-cluster


  10. #850

  11. #851
    Merci !

    Pour le traitement des exception je vois l'idée, mais j'ai encore un peu de mal avec les détails. En particulier cette règle a l'air bien pénible :
    "For predicated SVE vector stores, memory locations that are associated with active elements that do not detect a fault are set to an UNKNOWN value."

    Mettons que je veuille vectoriser un code de ce genre :
    Code:
    for(int i = 0; a[i] != 0; i += 1024)
      a[i] = a[i] + 1;
    J'ai 3 cas exceptionnels à gérer :
    1. Quand le load lève une exception. Ça peut être une page fault normale sur le chemin (à traiter normalement), ou un accès spéculatif à une page après la fin de la boucle (à ignorer).
    2. Quand la condition d'arrêt est vraie. Il faut traiter toutes les itérations précédentes et annuler les itérations suivantes.
    3. Quand le store lève une exception. Il faut traiter l'exception et recommencer le store avec les mêmes données, vu qu'on a laissé la mémoire dans un état dégueulasse sur toutes les autres voies.

    Je ne peux pas simplement répéter la boucle en traitant les exceptions une à une dans l'ordre, sinon je peux me retrouver à re-lire des a[i] dont la valeur est devenue UNKNOWN et genre les incrémenter deux fois de suite, ou bien me prendre des exceptions en boucle et ne jamais faire de forward progress.

    Donc : si je récupère une exception en 1 et qu'elle n'est pas sur la première voie, je la mets de côté, j'évalue la condition d'arrêt sur les voies précédent celle de l'exception, je désactive et je supprime les exceptions mises de côté sur toutes les voies d'après celle où la condition d'arrêt est vérifiée, puis je lance le store sur les voies restantes. Si le store lève une exception, je la traite et je recommence le store sur les voies restantes (forcément une par une pour avoir du forward progress !) jusqu'à épuiser toutes les exceptions. Après je traite les exceptions restantes du load d'avant la condition d'arrêt.

    Mouais, ça a l'air faisable mais faut voir la gueule du code généré... et celle du générateur de code.

    Sinon, l'instruction FTMAD. Comment combiner les problèmes du hardware et du software avec des coeffs et un schéma d'évaluation codés en dur, mais même pas documentés niveau archi. Sérieusement, Fujitsu...

  12. #852
    J'ai aussi ma réponse pour l'instruction de réduction flottante FADDA.

    De ce que je comprends le modèle d'exception autorise le hardware à laisser le registre destination (ou la mémoire) dans un état plus ou moins dégueulasse en cas d'exception, et c'est au software de nettoyer derrière. Comme ça on contourne le problème des exceptions précises sur les architectures vectorielles. C'est moche, mais pourquoi pas...

  13. #853

  14. #854
    Malgré le fait que Hot Chips se finisse aujourd'hui, je vois qu'il n'y a personne pour linker les articles intéréssants !

    Au hasard les slides d'Intel et d'AMD sont inintéréssantes (à leur décharge ils n'ont déjà pas dit ce qu'ils avaient prévu de ne pas dire quand ils ont sorti Kaby Lake et Zen) mais chez IBM et Qualcomm il se passe des choses (allez un exemple en toute objectivité).
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  15. #855
    J'attendais que le lien / password pour télécharger les slides fuite. Sans surprise, la moitié des exposés parlent d'archis pour le deep learning. Rien d'intéressant sur les GPU Volta / Vega / Knights Mill ?

    Joie, de la compression mémoire sur un CPU généraliste. Entre la virtualization, TrustZone, et la compression mémoire, c'est la traduction d'adresse qui doit être un sacré bazar.

    Ça promet de belles attaques side-channel aussi.

  16. #856
    Je ne sais pas, j'y étais pas. Je ne sais pas trop comment fonctionne la compression mais j'imagine que c'est transparent à la traduction d'adresse (après tout les papiers sur la compression de cache ne parlent pas de traduction que je sache).
    Et clairement, ça devrait donner du grain à moudre à ceux qui font des side-channels (qui doivent être tristes depuis qu'Intel à un L3 non-inclusif).
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  17. #857
    Avec du conditionnel : l'accélérateur Matrix-2000 qui pourrait équiper le supercalculateur numéro 2 mondial pourrait être à base d'ARM + jeu d'instruction vectoriel "self-defined".
    https://www.nextplatform.com/2017/09...supercomputer/


  18. #858
    Un peu de drama sur comment Qualcomm "n'a pas quitté le marché du serveur ARM".
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  19. #859
    Citation Envoyé par Thamior Voir le message
    Un peu de drama sur comment Qualcomm "n'a pas quitté le marché du serveur ARM".
    Vive le capitalisme débridé !

    Avec ma casquette de complotiste, je dirais qu'Intel a payé Broadcom. Nan je déconne

  20. #860
    L'hécatombe continue chez QC Datacenter, mais Amazon reprend le flambeau ARM pour serveur (plus exactement pour leurs serveurs). Il semblerait qu'ils s'attaquent à faire un SoC in-house en premier plutôt que de commencer par le core comme QC.
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  21. #861
    Le SoC d'Amazon utilise un Cortex-A72, ce qui me paraît vraiment léger.

    Quel gâchis cette histoire de QC. Ca donne l'impression qu'ils ont cru qu'en un an ou deux sur le marché ça allait donner quelque chose de rentable ; un article de Bloomberg à ce sujet. Avec un marché du smartphone qui fléchit de manière significative, je ne sais pas si leur avenir est rose. C'est quand même beau de tout laisser aux mains des financiers et des actionnaires.

  22. #862
    Citation Envoyé par newbie06 Voir le message
    Le SoC d'Amazon utilise un Cortex-A72, ce qui me paraît vraiment léger.

    Quel gâchis cette histoire de QC. Ca donne l'impression qu'ils ont cru qu'en un an ou deux sur le marché ça allait donner quelque chose de rentable ; un article de Bloomberg à ce sujet. Avec un marché du smartphone qui fléchit de manière significative, je ne sais pas si leur avenir est rose. C'est quand même beau de tout laisser aux mains des financiers et des actionnaires.
    De mémoire c'est parce que seul l'A72 avait certaines choses requises pour le datacenter et pourquoi l'A73 n'était pas marketé vers ce marché du tout. Après ils auraient pu prendre l'A75, mais je serai pas étonné si une prochaine version basée avec de l'A76 dedans sortait d'ici ~18mois.

    Edit : Quote de l'article d'anandtech lors de l'annonce du A75 :

    "ARM targeted the A73 specifically at mobile by focusing on power efficiency and removing some features useful for other applications to simplify the design, including no ECC on the L1 cache and no option for a 256-bit AMBA 5 CHI port. With A75, there’s now a clear upgrade path from A72. For the server and infrastructure markets, A75 supports ECC/parity for all levels of cache and AMBA 5 CHI for connecting to larger CCI, CCN, or CMN fabrics, and for automotive and other safety critical applications there’s architectural RAS support, protection against data poisoning, and improved error management.".

    Un nouveau venant mettra toujours plus de temps pour leur premier SoC qu'une équipe établie qui peut itérer sur la version précendente, donc ce serait pas étonnant qu'ils n'avaient pas le temps d'intégrer un CPU plus récent.


  23. #863
    It's alive! Et 2x plus rapide qu'avant (4800 vs 2400, ça ne peut vouloir dire que ça).
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  24. #864
    En fait c'est tres exactement Centriq 2400 renomme : meme nombre de coeurs, meme techno, meme nombre de transistors. Ils sont trop forts

  25. #865
    SVE2 (aka SVE pour les entiers) et TME (transactional memory) annoncés : https://community.arm.com/developer/...e-architecture

  26. #866
    Citation Envoyé par Thamior Voir le message
    It's alive! Et 2x plus rapide qu'avant (4800 vs 2400, ça ne peut vouloir dire que ça).
    Ben en fait il a mourru lui aussi : https://www.cnx-software.com/2019/04...re-huaxintong/

  27. #867
    Oui, mais Qualcomm se diversifie, ils vont faire dans le datacenter https://finance.yahoo.com/news/qualc...134101407.html (avril 2019). On avait déjà l'insulte, on a l'injure

    Peut-être que quelqu'un pourra choper une licence du design d'après Centriq 2400, vu que clairement HXT n'a plus le monopole dessus.
    Dernière modification par Thamior ; 24/04/2019 à 01h52.
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  28. #868
    J'ai lu par-ci par-là que le cache d'instructions d'Ares sera cohérent. Vu que chez ARM la cohérence du cache d'instructions est la responsabilité du software, c'est presque surprenant. Après j'imagine que ça doit aider pas mal les JIT, c'est juste dommage qu'il faille encore s'embêter à mettre les invalidations et barrières dans le code.
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

  29. #869
    ARM vs Intel, fight !

    https://www.cnx-software.com/2019/05...ess-5g-laptop/

    Bon ça vient du constructeur, donc à prendre avec les précautions qui s'imposent

  30. #870
    Samsung arrêterait les CPU mobiles ARM custom (du moins ceux produit à Austin : M1, M2, M3, M4). Pas encore d'annonce officielle (que je sache), mais la news me paraît plausible. Suivant comment ça se passe pour Huawei, les téléphones sur le sol US seront donc limités aux designs ARM/Apple/Qualcomm en sachant que Qualcomm fait du semi-custom (quelques paramètres à tourner dans le design ARM mais rien de fondamental, si j'ai bien compris), et que le A13 a l'air plutôt en avance sur le reste. J'oublie peut-être Mediatek?
    Citation Envoyé par François
    L'ordinateur cantique, c'est l'avenir.

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
  •