C'est pas tellement la pallelisation en temps que tel que je ne comprends pas.
C'est moi qui ai fait la parallelization in OPENMP.
Les taches sont totalement independentes.
Si le rapport n'est pas strictement egale aux nombres de CPU (sur chaqu'une des machines)
c'est parce qu'il y a des integrations qui trainent (adapatives), mais cela reste correct.
Il faudrait faire d'autres parallelisations dans les boucles.
Ce que je ne comprends pas ceux sont les rapports entre les CPUs
Par exemple, passant de 4 a 8 proc, je gagne peu (tenant compte d'une horloge
un peu plus basse).
Passant de 4 a 12, je gagne mois d'un facteur 2 (avec une meiileur horloge).
Il semble qu'un i5 fonctionne mieux qu'un i7.
Toutes ces machines ont plus de 5 ans.
#CPU: 1.735e+03 sec., Elapsed time: 5.472e+02 sec. (Teucidide: 4 proc i5-7400 CPU @ 3.00GHz)
#CPU: 2.986e+03 sec., Elapsed time: 4.688e+02 sec. (Sappho: 8 proc i7-6700HQ CPU @ 2.60GHz)
#CPU: 2.405e+03 sec., Elapsed time: 2.647e+02 sec. (Homere: 12 proc: i7-8700 CPU @ 3.20GHz)
>
> Bonjour !
>
> Patrick Dupré a écrit :
> > Si je veux aller au-dela [de 24 threads physiques], est-ce qu'il y a
> > des options multi-carte ou/et 2 processors par carte ?
>
> Au labo, on a une machine avec deux processeurs Xeon Platinum 8352Y :
>
> Thread(s) per core: 2
> Core(s) per socket: 32
> Socket(s): 2
>
> Ça fait 128 threads physiques... et un bruit d'avion à réaction quand ça
> tourne ! C'est fait pour vivre dans un rack de datacenter, loin des
> oreilles humaines.
>
> On l'a achetée en février 2022. Aujourd'hui, si tu as le budget, tu peux
> avoir jusqu'à 256 threads physiques dans un seul processeur (Intel Xeon
> 6980P ou AMD EPYC 9754).
>
> > De de 4 (i5) a 12 (i7) proc, il n'a y un gain que de 2!
>
> Ah, la parallélisation... c'est un problème difficile ! Certains
> algorithmes peuvent facilement se décomposer en de nombreuses tâches
> indépendantes. On dit qu'ils sont « trivialement parallélisables ». Le
> Monte-Carlo ou le ray tracing en sont de bons exemples. D'autres algos
> ne se parallélisent pas si bien : tu peux les découper en tâches
> séparées, mais celles-ci ne sont pas indépendantes, elles doivent se
> synchroniser, communiquer entre elles... Plus tu as de tâches, plus tu
> perds du temps en synchronisation, communication, invalidation des
> caches L1, etc. La vitesse en fonction du nombre de threads physiques
> alloués commence par augmenter, puis sature, puis diminue.
>
> Dans ton cas, si tu multiplies le nombre de proc par 3 et que tu gagnes
> un facteur 2 en temps de calcul... ce n'est pas si mal ! Mais ça
> t'indique que ça ne servira probablement à rien d'augmenter encore le
> nombre de proc. À moins de revoir ta stratégie de parallélisation, la
> localité mémoire, tout ça...
>
> À+,
>
> Edgar.
>
>
