Crunchez vos adresses URL
|
Calculez la conso électrique de votre PC
|
Hébergez vos photos
Page 29 sur 29 PremièrePremière ... 19212223242526272829
Affichage des résultats 841 à 853 sur 853
  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).
    On ne parlera jamais assez des RISC liés à la vente d'ARM.

  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 à 20h32.

  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
    On ne parlera jamais assez des RISC liés à la vente d'ARM.

  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

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
  •