Tu n'as jamais du faire de softs multithreads pour dire un truc pareil.
Un exemple tres simple pour mplayer, ce qu'il faut faire :
1) lire les donnees
2) les decoder
3) les afficher
Le point 1) implique des acces disque, chose EXTREMEMENT lente par rapport aux acces memoires et autres operations.
Bref, si tu fais un soft monothread, ton soft passe son temps a lire, stopper, decoder, afficher, lire, stopper, decoder, afficher,...
Si tu as 2 threads, tu as un thread qui s'occupe de lire les donnees du disque, pendant que l'autre s'occupe de decoder/afficher.
Resultat des courses:
- Ton soft multithread est plus rapide qu'un soft monothread, car mplayer ne se tourne pas les pouces pendant que les donnees sont lues depuis le disque.
De meme, ce soft multithread pourra faire du boulot EN AVANCE, ce qui evite d'avoir besoin de ressources CPU plus tard, ce qui evite des saccades et autres dans le cas ou elles ne seraient pas disponibles,...
La regle c'est : Fais le boulot quand tu as le temps plutot qu'attendre le derniere moment et te retrouver dans un cul de sac.
Le multithread au total ca prend effectivement quelques cycles de plus, mais en temps, ca en prend moins, car ca gaspille moins de cycles, c'est ca le miracle.
Les machines en general gaspillent un nombre de cycles enorme a ne rien faire, et les lenteurs viennent du fait que plusieurs softs demandent des ressources au meme moment, faire du travail a l'avance, ca evite ces problemes, faire du multithread pour des softs qui font pas mal de calculs sur des donnees lues depuis le disque, c'est gagner enormement en perfs.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par pasBill pasGates . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 5.
Un exemple tres simple pour mplayer, ce qu'il faut faire :
1) lire les donnees
2) les decoder
3) les afficher
Le point 1) implique des acces disque, chose EXTREMEMENT lente par rapport aux acces memoires et autres operations.
Bref, si tu fais un soft monothread, ton soft passe son temps a lire, stopper, decoder, afficher, lire, stopper, decoder, afficher,...
Si tu as 2 threads, tu as un thread qui s'occupe de lire les donnees du disque, pendant que l'autre s'occupe de decoder/afficher.
Resultat des courses:
- Ton soft multithread est plus rapide qu'un soft monothread, car mplayer ne se tourne pas les pouces pendant que les donnees sont lues depuis le disque.
De meme, ce soft multithread pourra faire du boulot EN AVANCE, ce qui evite d'avoir besoin de ressources CPU plus tard, ce qui evite des saccades et autres dans le cas ou elles ne seraient pas disponibles,...
La regle c'est : Fais le boulot quand tu as le temps plutot qu'attendre le derniere moment et te retrouver dans un cul de sac.
Le multithread au total ca prend effectivement quelques cycles de plus, mais en temps, ca en prend moins, car ca gaspille moins de cycles, c'est ca le miracle.
Les machines en general gaspillent un nombre de cycles enorme a ne rien faire, et les lenteurs viennent du fait que plusieurs softs demandent des ressources au meme moment, faire du travail a l'avance, ca evite ces problemes, faire du multithread pour des softs qui font pas mal de calculs sur des donnees lues depuis le disque, c'est gagner enormement en perfs.