thread - Divers - Programmation
Marsh Posté le 01-11-2005 à 11:15:18
un thread est tres rapide
donc on va dire qu'un thread est a privilégier a un fork
Marsh Posté le 01-11-2005 à 11:17:21
KangOl a écrit : un thread est tres rapide |
Ca overclocke automatiquement le processeur ?
KangOl a écrit : donc on va dire qu'un thread est a privilégier a un fork |
Ca dépend des cas
Marsh Posté le 01-11-2005 à 11:19:30
crapodesiles a écrit : est ce que les traitements paralleles (thread) permettent de reduire le temps d'execution ? |
En général non
Marsh Posté le 01-11-2005 à 11:25:21
Avec un mono processeur non hyperthreading, tu ne gagneras que grace au déroulement d'un thread pendant que l'autre attends une réponse ou un signal. Le reste du temps, t'en perdras vu que le processeur doit recharger un certain nombres d'infos pour reprendre l'exécution de l'autre thread. Si le processeur est mal conçu, il devra également vider tous ces pipes. (comme quand il c'est planté dans ses prédictions) Si l'os est mal conçu, le passage d'un thread à un autre prendra également du temps.
Bref, avec un mono-processeur, si le processeur et l'OS sont bien conçu et si le programme a tendance à perdre "un peu" de temps en attente, tu y gagneras. Si le programme n'attend jamais, t'en perdras quasiment toujours sur un mono processeur non hyperthreading. Si le programme attend énormément (genre éditeur de texte), ce que tu gagneras sera tellement négligable par rapport aux besoins que c'est pas la peine de se faire chier.
Par contre, avec un multiprocesseur ou un processeur hyperthreading, a par si tous les thread passent leur temps à attendre des réponses ou des signaux, alors là oui, t'y gagneras quasiment tout le temps.
Marsh Posté le 01-11-2005 à 17:54:24
crapodesiles > Ben ca dépend de ce que tu fais faire à ton programme.
Marsh Posté le 01-11-2005 à 18:34:37
du traitement sur des images (traitement sur les pixels, permutations couleurs, traitement geometrique, affichage de bas en haut ou de droite à gauche, superpositions d'images ...)
mais comme l'a si bien explique omega2 sans multiprocesseur, ni processeur multithreading je vois pas l'intéret
Marsh Posté le 01-11-2005 à 18:49:05
ce que tu peut deja faire pour optimiser tes algos c d'utliliser le MMX, ca se prete vraiment bien au traitement des images
Marsh Posté le 01-11-2005 à 19:01:06
merde, fable se termine en 10 heures de jeu
Marsh Posté le 01-11-2005 à 19:13:56
ReplyMarsh Posté le 01-11-2005 à 19:39:50
pardon, je me suis cru dans bla²
Marsh Posté le 01-11-2005 à 20:11:22
red faction a écrit : ce que tu peut deja faire pour optimiser tes algos c d'utliliser le MMX, ca se prete vraiment bien au traitement des images |
Ou AltiVec ou NeonX, y a pas que ntel dans la vie.
En general, le parallelisme n'est efficace et ne produit du gain que si l'application de abse EXPOSE une certaines
quantités de parallélisme latent (données ou controles).
Pour du traitement d'image bas niveaux, il y a effectivement un gros potentiel de data-parallelism.
Marsh Posté le 01-11-2005 à 11:10:50
est ce que les traitements paralleles (thread) permettent de reduire le temps d'execution ?
je sais que ca depend du programme, mais en général ?