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.
Il ne faut pas confondre trois choses :
L'algorithme général qui permet de régler ton problème, et
la façon dont tu implémentes la solution (et les structures de données afférentes)., et enfin
les (micro-)optimisations que tu peux faire sur un code.
Les deux premiers points sont les deux plus importants, car ils t'apportent une solution correcte. Le troisième point, si les deux premiers ont été correctement effectués (meilleur algo possible pour le problème à résoudre, meilleur choix de structure de données pour réaliser l'implémentation de l'algo, etc.), alors on peut enfin se pencher sur la (micro-)optimisation du code.
Et oui, si tu veux juste traverser un arbre (pour faire un parcours en profondeur par exemple), mais que tu n'as pas de gros calcul à effectuer sur les nœuds, alors la vectorisation est inutile (ou infaisable). Mais tu parles déjà d'un type de programmation bien plus avancé que ce que la plupart des gens connaissent. Pour la plupart des physiciens ou numériciens que j'ai pu croiser, si le compilateur leur dit « j'ai vectorisé tes boucles », ils sont tout contents, mais sinon, de toute manière, ils ont ce gros machin MPI à écrire, et ça leur bouffe déjà la plupart de leur temps de cerveau disponible. :)
Ce qu'il nous faut en fait, c'est le même genre de bibliothèques de bases que ce qui est proposé en Java par exemple (dans util.concurrent si je me souviens bien — en tout cas un truc dans le genre) ou en C++ avec Boost (même si pour le moment c'est un peu léger) : des machins qui sont « parallel-proof » (dans une certaine limite). Et il nous faut d'autres gens qui programment d'autres structures de données qui permettent des accès concurrents efficaces (pas de gros verrou en entrée de la structure de donnée par ex). Sauf que la programmation efficace de ce genre de bibliothèque n'est pas à la portée du premier venu. Par exemple, une implémentation concurrente et efficace d'une liste chaînée passe par l'utilisation d'opérations de type compare-and-swap, pour « verrouiller » atomiquement (et efficacement) un maillon de la chaîne que tu traverses. Les algos pour le faire sont loin d'être triviaux. Par exemple, je t'encourage à aller regarder du côté des implémentations lock-free des Skip-list : le papier original explique très bien comment faire, mais malgré tout c'est pas évident à réaliser sans bug.
Bref, il nous faut des gens qui nous fournissent des implémentations génériques et efficaces (en C, C++, etc.) de structures de données qui gèrent la concurrence. Sur une machine « normale » (entre 2 et 8 cœurs ou threads), ces algos sont suffisants pour garantir un passage à l'échelle. Sur une grosse machine parallèle, là oui, il va falloir travailler un peu plus. Mais c'est ce qui fait que je vais avoir du boulot pour les dix prochaines années au moins ... :)
[^] # Re: Par pitie
Posté par lasher . En réponse au journal Du livre "Premiers cours de programmation en Scheme". Évalué à 2.
Il ne faut pas confondre trois choses :
Les deux premiers points sont les deux plus importants, car ils t'apportent une solution correcte. Le troisième point, si les deux premiers ont été correctement effectués (meilleur algo possible pour le problème à résoudre, meilleur choix de structure de données pour réaliser l'implémentation de l'algo, etc.), alors on peut enfin se pencher sur la (micro-)optimisation du code.
Et oui, si tu veux juste traverser un arbre (pour faire un parcours en profondeur par exemple), mais que tu n'as pas de gros calcul à effectuer sur les nœuds, alors la vectorisation est inutile (ou infaisable). Mais tu parles déjà d'un type de programmation bien plus avancé que ce que la plupart des gens connaissent. Pour la plupart des physiciens ou numériciens que j'ai pu croiser, si le compilateur leur dit « j'ai vectorisé tes boucles », ils sont tout contents, mais sinon, de toute manière, ils ont ce gros machin MPI à écrire, et ça leur bouffe déjà la plupart de leur temps de cerveau disponible. :)
Ce qu'il nous faut en fait, c'est le même genre de bibliothèques de bases que ce qui est proposé en Java par exemple (dans util.concurrent si je me souviens bien — en tout cas un truc dans le genre) ou en C++ avec Boost (même si pour le moment c'est un peu léger) : des machins qui sont « parallel-proof » (dans une certaine limite). Et il nous faut d'autres gens qui programment d'autres structures de données qui permettent des accès concurrents efficaces (pas de gros verrou en entrée de la structure de donnée par ex). Sauf que la programmation efficace de ce genre de bibliothèque n'est pas à la portée du premier venu. Par exemple, une implémentation concurrente et efficace d'une liste chaînée passe par l'utilisation d'opérations de type compare-and-swap, pour « verrouiller » atomiquement (et efficacement) un maillon de la chaîne que tu traverses. Les algos pour le faire sont loin d'être triviaux. Par exemple, je t'encourage à aller regarder du côté des implémentations lock-free des Skip-list : le papier original explique très bien comment faire, mais malgré tout c'est pas évident à réaliser sans bug.
Bref, il nous faut des gens qui nous fournissent des implémentations génériques et efficaces (en C, C++, etc.) de structures de données qui gèrent la concurrence. Sur une machine « normale » (entre 2 et 8 cœurs ou threads), ces algos sont suffisants pour garantir un passage à l'échelle. Sur une grosse machine parallèle, là oui, il va falloir travailler un peu plus. Mais c'est ce qui fait que je vais avoir du boulot pour les dix prochaines années au moins ... :)