> Vu le type d'operation effectue, il est evident qu'un model multithreade est plus efficace pour ce type de soft.
Je doit conclure que tout les programmes qui ont l'algo :
1) lecture depuis le disque
2) decodage (traitement)
3 affichage (retour des informations)
son plus rapide s'ils sont "multi-threadés". Vivement un grep/sed/awk... multi-thread alors ?
> Faire sequentiellement de la lecture(qui revient a s'arreter et attendre que le systeme d'I/O complete la requete),
Oui et non.
Les lectures de disque sont lente mais ne consomme pas de cpu. De plus tu peux très bien faire des lectures non bloquante et c'est très très rapide.
Lorsque tu fais un read() non bloquant et qu'il n'y a pas de donné dans le cache, les données seront lues par le noyau plus tard alors que ton programme est "ailleur". A çà tu ajoutes un buffer, peut-être l'utilisation de select() et l'affaire est plié.
Actuellement mplayer utilise deux proces (et non deux threads !) :
- un pour la lecture
- un pour le décodade et affichage
Les deux proces sont utilisés uniquement si l'option -cache est spécifié. L'utilisation de deux proces est intéressante pour un fichier avi sur le réseau (http://....(...)) car le noyau ne peut pas "bufferiser" ce qui est sur le réseau.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par matiasf . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 4.
Je doit conclure que tout les programmes qui ont l'algo :
1) lecture depuis le disque
2) decodage (traitement)
3 affichage (retour des informations)
son plus rapide s'ils sont "multi-threadés". Vivement un grep/sed/awk... multi-thread alors ?
> Faire sequentiellement de la lecture(qui revient a s'arreter et attendre que le systeme d'I/O complete la requete),
Oui et non.
Les lectures de disque sont lente mais ne consomme pas de cpu. De plus tu peux très bien faire des lectures non bloquante et c'est très très rapide.
Lorsque tu fais un read() non bloquant et qu'il n'y a pas de donné dans le cache, les données seront lues par le noyau plus tard alors que ton programme est "ailleur". A çà tu ajoutes un buffer, peut-être l'utilisation de select() et l'affaire est plié.
Actuellement mplayer utilise deux proces (et non deux threads !) :
- un pour la lecture
- un pour le décodade et affichage
Les deux proces sont utilisés uniquement si l'option -cache est spécifié. L'utilisation de deux proces est intéressante pour un fichier avi sur le réseau (http://....(...)) car le noyau ne peut pas "bufferiser" ce qui est sur le réseau.