On m’a mis au courant pour GCC ;) c’est bien du Fortran, avec le compilateur Intel et OpenMP. Pour la taille, je n’ai pas fait de mesure systématique, ça allait de quelques milliers de points (avec boucle interne sur les voisins des points — en moyenne 100 —, déjà calculés), à quelques centaines de milliers (sans boucles interne), je crois me souvenir avoir fait des tests avec quelques dizaines de milliers (×ばつ100 toujours) et quelques millions. Il faut que la boucle soit assez conséquente (en terme d’instructions, pas seulement de données) pour avoir un gain, comme tu l’as expliqué.
Je suis d’accord pour dire que la vectorisation est facilement réalisable automatiquement pour les cas simples (c’est bien pour ça que je me suis contenté d’écrire 1:N dans le premier cas, comme le Fortran le permet, au lieu d’une version C qui masquerait ça). Mais pour moi ça nécessite toujours de penser les algos. dans ce sens, il suffit de quelques variables temporaires dans la boucle, qu’un élément j du vecteur attende le résultat sur l’élément i et la boucle n’est plus vectorisable de façon triviale, voir pas du tout dans le cas d’un arbre.
« C'est vrai, mais je ne vois pas le rapport avec les GPU. En fait c'est même pire, les GPU sont notoirement mauvais pour traiter d'opérations sur les graphes en parallèle. »
On est bien d’accord, c’est ce que je voulais signaler, on n’a pas affaire à la même façon de paralléliser, il y a des algos qui ne sont tous simplement pas vectorisables. Pour continuer sur le parcours d’un arbre, on peut le faire itérativement avec une pile fait-main, mais ça ne change rien au fait que tu ne peux pas le vectoriser car ma n-ième itération dépendra de ce que j’aurais fait à ma n-1-ième, et pour la petite parallélisation passe encore, mais ça scale pas comme on dit dans le coin. Un algo. donné pourra être performant en séquentiel, pourri en parallèle, et vice-versa, idem en vectorisation.
« qui est vrai hein, c'est juste que j'appelle pas ça de la parallélisation au sens où la plupart des gens l'entendent. :) »
Je crois qu’au final on est bien d’accord :), juste une question de vocabulaire : pour moi la vectorisation, c’est-à-dire le truc qu’on fait sur GPU, ou la façon de faire lorsqu’on n’avait pas accès à des clusters et aux multi-cœurs, est une forme de parallélisation.
Bref, mon commentaires était de souligner que tout ceci pourrait être un peu plus enseigné étant donné l’importance que commence à prendre la parallélisation, y compris pour des « non-informaticiens ». J’ai appris comment optimiser un algo. en séquentiel, par contre je suis assez vite perdu en parallèle, et c’est clairement un manque en ce qui me concerne. Bref, en prépa. j’ai appris à évaluer un algo. en fonction de sa complexité en nombre d’op. par sec., en parallèle ce raisonnement ne tient plus : si pour chaque CPU de plus aux M-1 présents tu ajoutes moins de N/M opérations supplémentaires, ça vaut toujours le coup.
[^] # Re: Par pitie
Posté par nicolas . En réponse au journal Du livre "Premiers cours de programmation en Scheme". Évalué à 2.
On m’a mis au courant pour GCC ;) c’est bien du Fortran, avec le compilateur Intel et OpenMP. Pour la taille, je n’ai pas fait de mesure systématique, ça allait de quelques milliers de points (avec boucle interne sur les voisins des points — en moyenne 100 —, déjà calculés), à quelques centaines de milliers (sans boucles interne), je crois me souvenir avoir fait des tests avec quelques dizaines de milliers (×ばつ100 toujours) et quelques millions. Il faut que la boucle soit assez conséquente (en terme d’instructions, pas seulement de données) pour avoir un gain, comme tu l’as expliqué.
Je suis d’accord pour dire que la vectorisation est facilement réalisable automatiquement pour les cas simples (c’est bien pour ça que je me suis contenté d’écrire 1:N dans le premier cas, comme le Fortran le permet, au lieu d’une version C qui masquerait ça). Mais pour moi ça nécessite toujours de penser les algos. dans ce sens, il suffit de quelques variables temporaires dans la boucle, qu’un élément j du vecteur attende le résultat sur l’élément i et la boucle n’est plus vectorisable de façon triviale, voir pas du tout dans le cas d’un arbre.
« C'est vrai, mais je ne vois pas le rapport avec les GPU. En fait c'est même pire, les GPU sont notoirement mauvais pour traiter d'opérations sur les graphes en parallèle. »
On est bien d’accord, c’est ce que je voulais signaler, on n’a pas affaire à la même façon de paralléliser, il y a des algos qui ne sont tous simplement pas vectorisables. Pour continuer sur le parcours d’un arbre, on peut le faire itérativement avec une pile fait-main, mais ça ne change rien au fait que tu ne peux pas le vectoriser car ma n-ième itération dépendra de ce que j’aurais fait à ma n-1-ième, et pour la petite parallélisation passe encore, mais ça scale pas comme on dit dans le coin. Un algo. donné pourra être performant en séquentiel, pourri en parallèle, et vice-versa, idem en vectorisation.
« qui est vrai hein, c'est juste que j'appelle pas ça de la parallélisation au sens où la plupart des gens l'entendent. :) »
Je crois qu’au final on est bien d’accord :), juste une question de vocabulaire : pour moi la vectorisation, c’est-à-dire le truc qu’on fait sur GPU, ou la façon de faire lorsqu’on n’avait pas accès à des clusters et aux multi-cœurs, est une forme de parallélisation.
Bref, mon commentaires était de souligner que tout ceci pourrait être un peu plus enseigné étant donné l’importance que commence à prendre la parallélisation, y compris pour des « non-informaticiens ». J’ai appris comment optimiser un algo. en séquentiel, par contre je suis assez vite perdu en parallèle, et c’est clairement un manque en ce qui me concerne. Bref, en prépa. j’ai appris à évaluer un algo. en fonction de sa complexité en nombre d’op. par sec., en parallèle ce raisonnement ne tient plus : si pour chaque CPU de plus aux M-1 présents tu ajoutes moins de N/M opérations supplémentaires, ça vaut toujours le coup.