De même que tu ne peux souvent pas paralléliser sur le tard parce qu'il aurait fallu utiliser des structures de données différentes, des algorithmes différents, ajouter des vérifications à mesure que tu écrivais ton code
Commencer par du parallèle, pour un débutant, cela va être sûrement un mauvais découpage, des bugs affreux et incompréhensible, des accès simultanés, des dead lock, … donc c'est préjudiciable d'autant plus que très souvent, il peut s'en passer.
Ensuite, comment vas-tu savoir que ta version parallèle sera plus performante que ta version séquentielle ? On ne peut pas vraiment décider de cela au petit bonheur la chance. Paralléliser peut faire sauter des optimisations, les synchronisations peuvent avoir un coût, etc.
De plus, même si la version parallèle est plus performante que la séquentielle, en a-t-on vraiment besoin ?
Elle est plus performante sur ton 8cœurs, mais l'est-il aussi sur un 2cœurs, … ?
Paralléliser, oui mais comment ? Pipeline ? TBB ? OpenMP ? Des threads en dur ?
Paralléliser, oui mais quoi ? Une boucle ? Un algorithme ? Exécuter deux algorithmes en parallèle ?
Et surtout, combien de threads ? Un nombre fixé ? Évoluant en fonction du poste de l'utilisateur ?
Cela me semble très difficile de choisir sans avoir une très bonne expérience, avoir des benchmark d'autres jeux, …
Après, ce n'est pas parce qu'on fait deux threads, qu'on fait déjà de l'optimisation. Mais faire deux threads parce que ce sera "plus performant" qu'une version séquentielle est, à mon avis, une erreur (moyennant quelques cas très triviaux).
Si cela a vraiment du sens d'avoir deux threads ou que ce soit "plus simple"* de faire deux threads qu'une version séquentielle, pourquoi pas, mais il faut vraiment que ce soit cohérent et réfléchit.
Mais quand on voudra optimiser l'un des threads, on commencera par l'optimiser sur un cœur, … avant de songer à le découper en plusieurs theads.
* il faut aussi que l'estimation de la difficulté ne soit pas trop éloignée de la réalité.
Bon, pour le cas de traitement d'images lourd, on sait pertinemment que le CPU n'est pas adapté et qu'on va le dans une version parallèle sur GPU. Après, on ne va pas non-plus chercher l'optimisation maximale, c'est presque impossible à atteindre, d'autant plus sur des architectures différentes, donc on s'arrête dès qu'on a des résultats satisfaisant.
Et enfin, il n'est pas nécessaire d'attendre d'avoir un prototype complètement fonctionnel pour faire des tests et réécrire des modules.
On peut aussi récupérer les benchmark que des personnes ont fait à notre place, on peut essayer de simuler le fonctionnement pour tenter de comparer différentes solutions mais aussi de s'y familiariser. Après avec l'expérience, on peut avoir quelques à priori, mais rien de 100% sûr.
Alors oui, il peut commencer avec 10 threads, mais il n'aura aucune garantie que ce soit la solution optimale ou la solution la plus simple.
Si paralléliser introduit trop de synchronisations, on peut aussi se poser la question de la cohérence du découpage.
Mais bon, c'est loin d'être trivial et je ne pense pas qu'on puisse demander à un débutant d'avoir l'expérience nécessaire pour déterminer s'il a besoin d'un thread ou deux. Donc autant qu'il aille au plus simple quitte à devoir réécrire une partie de son code au lieu de se planter directement dans un mur.
Bon en comparaison, le choix UDP/TCP est infiniment plus simple
.
Partager