C’est bien mon point, la façon de penser les algo. change entre vectorisation et parallélisation style multi-cœur. Pour caricaturer je dirai que dans le premier cas tu parallélises les boucles internes, dans le second la boucle externe.
Je n’ai pas assez d’expérience dans le domaine pour te sortir la théorie et parle plutôt de ressenti, mais par exemple, lorsque j’ai eu à travailler sur un intégrateur avec des particules (pos et vel), j’avais :
tant que t < t_final:
forces= calcul_des_forces(1:N) // à l’intérieur : vectorisation
pos(1:N) += vel(1:N)*dt // vectorisé
vel(1:N) += forces(1:N)*dt // vectorisé
t= t+dt
soit disant parallélisable en :
tant que t < t_final:
pour i de 1 à N : en parallèle :
force= calcul_la_force_particule(i)
pos(i) += vel(i)*dt
vel(i) += force(i)*dt
t= t+dt
Je ne pouvais pas paralléliser chacune des boucles vectorisées, car la parallélisation a un sur-coût trop important.
Ce n’est pas la même chose. Ici c’est trivial, mais sur un algo. un poil complexe, je ne vois pas comment : par exemple le parcours d’un arbre, je vois bien comment le paralléliser en donnant un sous-arbre à chaque process, par contre je ne sais pas comment le vectoriser. Ainsi il y a des algos qui se prêtent bien à un truc et pas à l’autre.
La différence vient du fait que dans le cas de la vectorisation on fait du single instruction multiple data, donc il faut penser son algo. comme une suite d’opérations simples s’appliquant sur des vecteurs. Tandis que dans le « multiple instruction single data » typique du CPU (j’entends par là qu’un cœur n’est pas bon pour traiter un grand nombre de données à la suite), je vais penser mon algo. comme une énorme et unique boucle à paralléliser dans laquelle je ferais beaucoup d’opérations mais sur un nombre limité de données.
« C'est vrai pour les informaticiens, beaucoup moins pour les physiciens/mathématiciens/biologistes/etc. »
Le problème est que les multi-cœurs sont devenues bien trop courantes pour qu’un physicien/mathématicien/bioligiste/etc. qui a un peu de calcul à faire puisse faire l’impasse dessus.
[^] # Re: Par pitie
Posté par nicolas . En réponse au journal Du livre "Premiers cours de programmation en Scheme". Évalué à 2.
C’est bien mon point, la façon de penser les algo. change entre vectorisation et parallélisation style multi-cœur. Pour caricaturer je dirai que dans le premier cas tu parallélises les boucles internes, dans le second la boucle externe.
Je n’ai pas assez d’expérience dans le domaine pour te sortir la théorie et parle plutôt de ressenti, mais par exemple, lorsque j’ai eu à travailler sur un intégrateur avec des particules (pos et vel), j’avais :
soit disant parallélisable en : Je ne pouvais pas paralléliser chacune des boucles vectorisées, car la parallélisation a un sur-coût trop important.
Ce n’est pas la même chose. Ici c’est trivial, mais sur un algo. un poil complexe, je ne vois pas comment : par exemple le parcours d’un arbre, je vois bien comment le paralléliser en donnant un sous-arbre à chaque process, par contre je ne sais pas comment le vectoriser. Ainsi il y a des algos qui se prêtent bien à un truc et pas à l’autre.
La différence vient du fait que dans le cas de la vectorisation on fait du single instruction multiple data, donc il faut penser son algo. comme une suite d’opérations simples s’appliquant sur des vecteurs. Tandis que dans le « multiple instruction single data » typique du CPU (j’entends par là qu’un cœur n’est pas bon pour traiter un grand nombre de données à la suite), je vais penser mon algo. comme une énorme et unique boucle à paralléliser dans laquelle je ferais beaucoup d’opérations mais sur un nombre limité de données.
« C'est vrai pour les informaticiens, beaucoup moins pour les physiciens/mathématiciens/biologistes/etc. »
Le problème est que les multi-cœurs sont devenues bien trop courantes pour qu’un physicien/mathématicien/bioligiste/etc. qui a un peu de calcul à faire puisse faire l’impasse dessus.