Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 2 sur 2 PremièrePremière 12
Affichage des résultats 31 à 45 sur 45
  1. #31
    Ca tombe bien que tu dises ça, j'ai un chapitre de calculs à faire relire
    Toi et Tramb vous me direz où insérer vos références et où faire livrer vos boutanches de pinard, vous constaterez que vous les avez bien méritées :codezbourrés:

  2. #32


    Intredasting.
    Lu sur http://fastcompression.blogspot.fr/

    Je cherche à rassembler un minimum de doc pour comprendre, vaguement, comment compresser et décompresser dans le cache un volume de données bien compressibles.

  3. #33
    Là tu vois que si tu veux faire ça en software, il te faut soit un taux de compression >12x, soit un algo plus performant.

    Si tes données sont vraiment bien compressibles, gagner un facteur 2 avec un algo 6x plus rapide, ça peut être faisable... Genre un delta-encoding puis compaction des zéros façon RLE. Mais il te faudra surement un jeu d'instruction d'homme pour compacter / expanser des vecteurs en une seule passe, genre AVX-512 ou GPU ≥ Kepler.

  4. #34
    Je pense que c'est clairement hors de ma portée pour le moment, et avant longtemps. D'autant que je dois me concentrer sur CUDA pour finir le manuscrit.
    Par contre, j'ai fini par trouver ce papier de 2015 pour ma biblio:

    http://ieeexplore.ieee.org/xpl/login...mber%3D7110612
    A Survey Of Architectural Approaches for Data Compression in Cache and Main Memory Systems
    Dernière modification par vectra ; 20/05/2016 à 16h35.

  5. #35
    Salut salut !

    Je remonte le topic parce que je vois qu'on mentionne SIMD, vectorisation et intrinsics dans le titre.
    C'est justement l'objet de ma recherche, mais concernant "NEON", la partie SIMD de certains processeurs ARM Cortex.

    Notamment et surtout le Cortex A-53 du Raspberry Pi 3B.
    On s'est équipé, avec un collègue, de chacun un exemplaire de ce Pi 3B pour essayer d'un faire une petite console de jeux.
    J'ai essayé quelques distributions GNU-Linux jusqu'ici, et y'a un truc qui me fait tiquer.

    • La Raspbian est en 32 bits, le cat /proc/cpuinfo me renvoit donc un CPU ARMv7, mais "neon" est présent dans les extensions
    • De même pour la Fedora 27 ARMv7
    • La OpenSUSE Tumbleweed tourne en AArch64, et ça c'est cool, donc cette fois le cpuinfo me renvoie bien un proco 64 bits, mais le "neon" n'est pas listé dans les extensions


    Et comme ça avait l'air sympa de pouvoir accélérer certains calculs sur du SIMD (on pourrait s'en servir pour nos fonctions de Maths/Forces/Collisions par exemple), j'aurais aimé apprendre à me servir des instructions Neon.
    Du coup, est-ce qu'il y a des canards pointus ici qui ont déjà fait ça sur Pi, et le cas échéant, en 32 ou en 64 bits du coup ?

    Je prévoyais plutôt d'utiliser les intrinsics en utilisant un compilo qui les gère (GCC, manifestement d'après la page Neon chez ARM, les supporterait) plutôt que de passer par du code assembly.
    Tout simplement parce que je suis encore très mauvais en ASM d'une manière générale !


    Merci pour vos conseils les canards

  6. #36
    A priori, AArch64 implique ARMv8 qui inclut Neon. C'est toujours présent, donc ce n'est même pas considéré comme une extension.

    Je suppose qu'il y a encore moins d'exemples de code Neon que SSE, mais ce n'est pas très différent, surtout si tu travailles au niveau intrinsics : rassures-toi, le code est presque aussi moche qu'en x86.

    Ah et avant de réécrire une fonction avec des intrinsics partout, n'oublie pas de vérifier que le compilateur n'arrive pas à vectoriser tout seul.

  7. #37
    Du coup, vu que tu as mis un " ", je suis perdu. Les compilos gèrent ça bien ou pas, en vrai ? On parle d'auto-vectorisation ?
    Je pense que ce sera du GCC vu qu'on parle d'un OS GNU-Linux sur Pi.

  8. #38
    En vrai, assez mal dès que les boucles sont non-triviales. Mais on n'est jamais à l'abri d'un accident. Surtout si ton code est simple, par exemple si tu fais des calculs sur des vecteurs de taille constante. De toute façon, tu n'échapperas pas à l'examen du code assembleur pour vérifier que ça génère ce que tu voulais.

  9. #39
    D'accord, merci pour les précisions.
    Le nombre de vecteurs pourra varier, mais ils auront des tailles constantes en effet.

  10. #40
    Ca me manque l'optimisation de code
    Ce craving...

  11. #41
    Vous avez vu que l'AVX512 est viré des Alder Lake à cause des E-cores (même pour ceux qui n'en ont pas) ?
    Suite à une suggestion, je vais utiliser cette signature pour des canards en manque de ranking pro. Ou des quotes idiots.

  12. #42
    En même temps l'AVX 512 ça marche pas.
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

  13. #43
    C'est plus compliqué.

    Officiellement, c'est pas présent dans les Alder Lake grand public, point barre.

    En pratique, si t'as un modèle hybride, tu peux réactiver avec une option BIOS et en désactivant les coeurs E. Ou juste dans le BIOS si t'as que des coeurs P (ça marche même sur un Celeron :D)

    Mais pour Intel, c'est pas là : le microcode récent empêche l'activation, et sur les prochains CPU, ça va être désactivé physiquement.

  14. #44
    @Lazy en pratique, ça surchauffait la carte Knight's Landing, c'est ça?

    Ca m'aurait plu de tâter de ces bestioles pour bénéficier d'une grosse bande passante à partir du CPU, mais on dirait qu'Apple a trouvé la solution à ce problème-là avec sa mémoire partagée CPU/GPU à 200 Go/s...

  15. #45
    Citation Envoyé par vectra Voir le message
    @Lazy en pratique, ça surchauffait la carte Knight's Landing, c'est ça?
    Ah maintenant il faut développer sérieusement ses avis péremptoires ?

    Sur le KNL en soi j'ai pas le souvenir de soucis particuliers, le boulot pour vectorisabiliser le code faisait sortir des gains dessus grâce à l'AVX512.

    La douille est arrivée avec le skylake, qui fait du gros throttling en chauffant et l'AVX 512 amplifie encore plus le phénomène.
    Exemple (axe vertical = fréquence en Ghz, les chiffres dans les rectangles = nb de coeurs utilisés) :


    Alors si tu as un joli calcul qui vectorise parfaitement, le gain de l'AVX512 reste largement supérieur à la perte de fréquence.
    Maintenant dans un vrai code de la vraie vie où la vectorisation est un compromis qui fait perdre un peu par endroit et gagner beaucoup à d'autres, sur skylake avec le throttling ça devient perdre beaucoup par endroit et gagner un peu à d'autres (le throttling affecte tout les coeurs, donc même ceux qui font du boulot en scalaire ou AVX2 dès qu'il y a du AVX 512 qui tourne à côté), et tu te retrouves avec moins de perf globales en utilisant l'AVX-512.

    Et la question qui fâche : si tu as un code parfaitement vectorisable... il serait probablement encore plus efficace sur un GPU que sur un CPU en AVX-512.

    Vu que maintenant Intel va proposer ses propres GPUs, je vois assez peu d'intérêt à conserver l'AVX-512 au sein des CPUs.

    Après c'est le point de vue HPC, sur les "petits" CPUs avec 8 coeurs max le throttling est faible (et ça s'est amélioré sur rocket et ice lake il me semble) donc je conçois bien qu'il puisse y avoir un intérêt pour le petit power user.
    Dernière modification par Lazyjoe ; 09/03/2022 à 15h06.
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

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
  •