Il a souligné l'apport important de l'open source à l'avancement du projet, à faire lire à tout ceux qui hésitent à mettre leurs logiciels sous licence libre.
(la dernière version est la 0.90rc2) On y apprend notamment l'extrême popularité de ce logiciel (1er sur les stats freshmeat devant le kernel) et comment SourceForge a gêné le développement.
Mais le point le plus important est certainement les informations concernant l'apport de l'open source au logiciel puisque après 1 an et demi pratiquement 30 développeurs travaillent sur MPlayer régulièrement et plus de 100 personnes ont envoyés des patchs ou des bug fixes !
De nombreuses parties de MPlayer ont été développées en commun ou reprises d'autres projects comme Avifile, Xine, FFMpeg, OMS, mpeg2dec...
D'un autre coté, malheureusement seulement 0.1% des utilisateurs ont écrit des bugreports utilisables.
Je recommande de faire lire ce document à tout ceux qui développent des logiciels de type freeware ou shareware pour qu'ils prennent conscience de l'apport de l'OpenSource sur le plan du développement d'un logiciel (et il y a bien sur beaucoup d'autres avantages tous aussi importants)
Aller plus loin
- le rapport présentant MPlayer et son développement (2 clics)
- le site de MPlayer (3 clics)
- MplayerXP fork de MPlayer avec support des threads (3 clics)
- xine un lecteur de videos (2 clics)
- Avifile, bibliothèque et lecteur de vidéos (2 clics)
# MplayerXP fork de MPlayer avec support des threads
Posté par matiasf . Évalué à 5.
Sinon le multi-threading n'est pas très intéressant.
Si mplayer est lancé avec l'option -cache [nombre] il y a deux proces mplayer. Un pour loader la video et un autre pour l'afficher.
exemple :
$ mplayer -vo x11 -cache 65536 toto.avi
...
dans une autre console :
$ ps ax | grep mplayer
2359 pts/1 R 0:00 mplayer -vo x11 -cache 65536 toto.avi
2361 pts/1 S 0:00 mplayer -vo x11 -cache 65536 toto.avi
$ kill -SIGSTOP 2361
La video continue tant que le buffer n'est pas vide.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par tanguy_k (site web personnel) . Évalué à 10.
sinon c'est quoi l'interet de killer le processus a la video ? je vois vraiment pas !
L'auteur de MplayerXP veut du multithread pour pouvoir "repartir" la charge : a des moment le cpu ne fait rien alors qu'a d'autre moment sur une machine peut puissante il va devoir dropper des frames, l'idee est donc de pre-calcule des frames.
Donc c'est uniquement utile sur les petites becannes et/ou lorsque l'on fait fonctionner MplayerXP en meme temps que d'autres programmes.
Arpi a tout simplement repondu que l'on pouvait pre-decompresse des frames sans avoir recourt aux threads (il deteste apparemment) qui posent plusieurs problemes (debug et profilage plus difficile, prend plus de ressources...)
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par matiasf . Évalué à -5.
GNU/Linux supporte les threads via Linux et la libc. Si je veux faire tourner un programme qui utilise les threads, il faut que je cherche un OS qui supporte les threads.
Et je ne peux pas faire tourner Apache 2 sur MPlayer même si selon toi MPlayer supporte les threads :-) . Si le fait d'utiliser quelque chose fait que tu le supportes alors on peut dire que MPlayer supporte les systèmes de fichier journalisé :-) .
Si MPlayer lit du quicktime, c'est bien MPlayer qui fait le boulot et c'est donc bien lui qui donne un support pour quicktime.
Je sais que l'on lit souvent :
- la plate-forme Linux est supporté par tel programme.
Ce qu'il faut comprendre dans ce cas, c'est que les développeurs supportent le programme sur cette plate forme.
D'ailleur on a souvent :
- "Unsupported plateforme but seems to work..."
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par reno . Évalué à 6.
Pour voir s'il y a une difference entre mplayer et mplayerXP sur cette machine..
Dans sa présentation (très intéressante d'ailleurs), il dit que mplayer est rarement utilisée sur des machines SMP, ce qui doit etre vrai mais on peut penser que les machines SMT vont se généraliser:
- Intel avec son hyperthreading
- AMD a déposé un brevet sur le SMT, donc probablement dans le futur..
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par f l . Évalué à 7.
Donc l'optimisation pour les p4 hyperthréadés et autres quand la lecture d'un fichier vidéo en plein écran occupe moins de 5% du temps cpu, ca me parait pas être LA priorité.
Il parle aussi d'un projet de rendre mplayer utilisable en temps que plugin pour les browsers web; je trouve l'idée très alléchante. Par exemple j'ai installé le plugin realvidéo mais il doit marcher sans bidouille sur un site sur 10. Et pour le quicktime ou les autres formats (winmedia etc.) il n'existe pas de solution, à part peut être le crossover plugin (qui est payant et non libre) et qui marchait pas mieux que le plugin real quand j'ai essayé la démo.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par imr . Évalué à 4.
http://www.xs4all.nl/~jjvrieze/kmplayer.html(...)
je vais l'essayer bientot...
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Serge Rossi (site web personnel) . Évalué à 5.
Mais bon, un SMT bien fait (avec plus d'unités d'execution disponibles par exemple), ça pourrait devenir intéressant...
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par reno . Évalué à 3.
Je ne suis pas tout a fait d'accord avec toi sur le fait qu'il faut lancer 2 applis différente pour que le gain soit intérressant: n'oublie pas que les unités d'execution sont aussi pipelinée: le SMT te permet de boucher les trous du pipeline..
C'est vrai que le SMT peut etre plus lent dans certains cas comme quand il y a un conflit pour le cache par exemple or les caches du P4 ne sont pas énormes..
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par tanguy_k (site web personnel) . Évalué à 10.
faut que tu lises les tests, tout le monde est unanime pour dire que HyperThreading est une veritable reussite (tout comme ils etaient unanimes pour dire que le P4 1er generation c'etait de la merde)
seulement 35% des unites de calculs sont occupes en utilisation courante sur un P4 normale, HyperThreading essaye simplement de combler ce probleme. et pour cela ils utilisent seulement 5% de la surface du die, donc ca coute que dalle, surtout par rapport a du SMP.
A l'avenir Intel sortira le Prescot avec 4 processeurs logiques, 1 MB L2 et gravure 0.09µ
Si tu veux mon avis, le SMP va pratiquement disparaitre dans un avenir proche. Quel sera l'interet de payer un truc beaucoup plus cher pour peu de performance en plus ?
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par wismerhill . Évalué à 3.
SMP 2 processeurs réels: 100% de performance en plus dans tous les cas.
Et de toute façon, même en faisant 4 ou 8 processeurs virtuels, il n'y a jamais qu'un processeur réel, donc on peut au mieux l'utiliser à 100%, en SMP 4 processeurs c'est au mieux 400% d'un seul.
Moi je le vois l'intérêt.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par reno . Évalué à 2.
Le SMP coute nettement plus cher que le SMT!
Si tu vois l'interet pourquoi tu n'utilise pas du SMP avec 64 processeur?
Ah, c'est trop cher?
Pour autant que je me souviennes le SMT tel qu'implémenté sur les P4 prends 5% de surface de Silicium en plus sur la partie logique du CPU: des clopinettes quand on compare au prix du SMP avec carte mere spéciale et tout.
De plus tu peux tres bien utiliser du SMT en SMP, si tu as suffisamment de thread, ce n'est pas du tout incompatible..
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par wismerhill . Évalué à 1.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par tanguy_k (site web personnel) . Évalué à 3.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Faut arréter les rideaux ! C'est pas bon pour la santé.
Les P4 arrivent à fumer les Athlons pour des applis comme le divx grace au SSE. Sinon la fpu x87 du P4 est 2x plus lente que celle de l'athlon.
Le problème des nouvelles instructions est qu'il faut les utiliser pour bénéficier de leurs avantages qui sont bien réelle.
"La première sécurité est la liberté"
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par tanguy_k (site web personnel) . Évalué à 3.
C'est ridicule parceque il faut coder specifiquement pour ces instructions or tous les proc ne les supportent pas et dans un avenir probablement plus aucun proc ne les supporteront, il n'y a aucune garantie. Tu achetes un proc pour les performances qu'ils apportent juste pour les divx ou pour toutes les applications restantes ? Libre a toi d'acheter un Pentium 4 parceque il y a SSE2 dedans et pas dans les autres procs, moi je trouve ca particulierement stupide.
Y'a un principe fondamental en architecture (et pas uniquement dans ce domaine) : optimiser le cas le plus courant et ne pas perdre de temps sur les cas qui ne le sont pas.
Or ici tu viens juste d'ecrire que c'est utile que pour quelques applications notamment le divx : bref ces instructions specifiques ne profitent qu'a un faible pourcentage.
Si on resume les instructions que tu cheries tant, elles sont :
- applicables qu'a un faible nombre de soft
- il faut re-ecrire des parties du soft pour en tirer profit
- on devient plus ou moins dependant de ces instructions et ca complique le code avec tous les problemes que ca comporte
- il y a aucune garantie de perenite
Donc oui au final c'est utile pour les divx ou les mp3, cool : mieux vaut avec que sans mais ca reste anecdotique et principalement du marketing.
En attendant HyperThreading ca ameliore la rapidite de tous les softs dans un environement multi-threade tout comme les innovations comme le risc, ooo, l'introduction du pipeline, le branch prediction etc... sans devoir bidouiller le code de ton programme.
Lis Computer Architecture A Quantitative Approach
C'est une reference dans le domaine et ensuite tu comprendras que c'est du pipo, il y a un court paragraphe dessus.
merci d'avoir participer.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
optimiser le cas le plus courant et ne pas perdre de temps sur les cas qui ne le sont pas
Evidement ! Et quel sont les "killer" applications qui font vendre du pc puissant ? Les mp3, divx et autre jeux 3D. Et quelles sont les applications qui bénéficient des instructions SIMD ?
Sinon tu n'as jamais aucune garantie de pérénité pour aucun processeurs. Jamais. Par contre, si intel a gagné face au motorola et ses 68xxx puis power pc, c'est justement grâce à la compatibilité ascendante. Ils n'y toucheront donc jamais.
Donc oui au final c'est utile pour les divx ou les mp3, cool : mieux vaut avec que sans mais ca reste anecdotique et principalement du marketing.
Non, ce n'est pas du marketing ! A l'époque de la sortie du mmx, ce n'est pas de la faute d'Intel si les journalistes étaient trop incultes pour comprendre comment le MMX marchait.
De plus, tu as bien une augmentation des performances très substanciel des applications applicants des calculs lourds (3D, traitement du signal, traitement d'image,..). C'est une technique qui provient des supercalculateurs vectoriel, type Cray et autre Nec ESS (mais avec des vecteurs de centaines de nombre pas de 4). Ce n'est pas anécdotique du tout.
applicables qu'a un faible nombre de soft
Son, video, 3D, Simulation ... hum oui, tu as raison il manque juste la bureautique. Mais en wysiwyg, il y a souvent des rendus à faire...
- il faut re-ecrire des parties du soft pour en tirer profit
C'est le plus gros point noire. C'est aussi des instructions pas facile à utiliser (sinon tous les softs en bénéficieraient).
- on devient plus ou moins dependant de ces instructions et ca complique le code avec tous les problemes que ca comporte
Et alors ? C'est toujours le problème lorsque l'on veut des perfs (prefetch, strip mining, ...).
- il y a aucune garantie de perenite
Il n'y en a jamais eu sauf que l'histoire d'Intel fait qu'il ne joueront pas à ce jeu-là.
Sinon le SSE2, qui n'existe que sur le P4 et pas encore sur l'Athlon, apporte le support SIMD 64 bits (donc des double) qui sont très souvent utilisé dans les programmes scientifques car la précision 32 bits ne suffit souvent pas. C'est donc un progres dans l'utilisation d'instructions SIMD dans du code scientifique (Simulation, ...).
L'avantage du SIMD sur toute autre techniques est que tu augmentes le nombre d'opérations par cycle d'horloge sans augmenter d'une porte la complexité du circuit de control. C'est tous l'interret de la téchnique.
merci d'avoir participer.
nicO, f-cpueur.
"La première sécurité est la liberté"
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par tanguy_k (site web personnel) . Évalué à 2.
c'est con de se discrediter comme ca
j'ai la derniere edition (3e, 15 mai 2002) et ca traite de tous les procs actuelles sur le marche et des toutes dernieres evolutions : t'as le P4 et les derniers Athlons dedans et pas juste sur une page.
et moi je te dis que dans 10 ans ton SSE2 ca fera longtemps qu'on utilisera plus.
Dans la realite il y a peu d'applications qui utilisent ces instructions, et si on fait des benchs je suis persuades que sur la majorite des softs qui les utilisent, on voit meme pas la difference.
rien que en 4 ans, il y a eu MMX, SSE, SEE2 et le truc de Motorola. meme si c'est souvent complementaire, c'est un element essentiel de marketing et les constructeurs jouent dessus. On va pas s'amuser a re-ecrire du code tous les 18 mois.
de toute facon je me te ferais pas changer d'avis et tu risques pas de me faire changer du mien.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Sinon MMX -> SIMD entier (assez pourris d'ailleurs non orthogonal et beaucoup 16 bits)
SSE -> SIMD float
SSE2 -> SIMD double
ALTIVEC -> SIMD pour Power PC, pourquoi voudrais-tu que cela soit compatible avec des instructions x86 ?
Donc les 4 ne sont pas vraiment équivalent entre eux !
et moi je te dis que dans 10 ans ton SSE2 ca fera longtemps qu'on utilisera plus.
Et moi, je dis que l'on utilisera plus que ça. Parce que des codes accèlère vraiment beaucoup avec et parce qu'il existe des instructions SSE scalaire que Gcc préfaire mille fois à la pile x87...
(c'est une mauvaise raison mais c'est sans doute la plus vrai)
Il y a 20 ans y'a beaucoup de monde qui trouvait que les 8086 ne valait pas grand chose devant les 68000.
et si on fait des benchs je suis persuadé que sur la majorité des softs qui les utilisent, on voit meme pas la difference.
Et bien tu te gourres lourdement ! Quand tu as un gros MAC à faire, qu'est-ce qu'il vaut mieux comme coeur de boucle :
MUL [V1] [V2] V3
Add V3 V4
V1, V2 coeff et donné, V3 donnés temporaires et V4 Accumulateur dont il faut ensuite additonner les 4 valeurs (chez intel) pour avoir le résultat final.
ou 4 fois la même chose en scalaire ?
Peut-être te rappelles-tu la fierté des Maceux dont les filtres Photoshop allait bien plus vite que ceux des PC ayant une fréquence quasi double ? Et bien, c'était juste grace à l'ALTIVEC bien mieux foutu que le MMX.
"La première sécurité est la liberté"
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par tanguy_k (site web personnel) . Évalué à 1.
oui voila un point interessant.
A l'heure ou l'on programme en Java, actuellement c'est dans les applications clientes que l'on utilise ces instructions. C'est completement anachronique !
c'est le job du compilo. Tant que l'on devra se palucher le code a la mano et ben c'est de la rigolade et ca restera anecdotique.
la pile x87 dans 5 ans il en restera plus grand chose.
Il y a 20 ans y'a beaucoup de monde qui trouvait que les 8086 ne valait pas grand chose devant les 68000
et c'est toujours le cas
c'est pas toujours les meilleurs qui gagnent et la majorite n'a pas toujours raison : c'est injuste mais c'est la vie
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Gniarf . Évalué à 10.
dans tes rêves, petit, dans tes rêves...
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Pascal Havé . Évalué à 3.
Compilation d'un noyau avec 'make -j 4'
avec HT : 365s
SANS HT : 206s !!
J'ai refait le test plusieurs fois, car tellement j'y croyais pas.
Alors dites moi encore que le HT est un succes...
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par matiasf . Évalué à 2.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Alexandre Beraud . Évalué à 2.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par wismerhill . Évalué à 3.
Sinon ta comparaison ne veut rien dire!
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Alexandre Beraud . Évalué à 1.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par M . Évalué à 0.
Et puis vu que le divx et xvid sont tous les 2 du mpeg4, je vois pas le rapport avec le format d'encodage, mais ça a plutot un rapport avec le "codec" utilisee pour la decompression, et la il se peut que certains comme xvid soit plus optimise pour ton processeur que d'autre (divx)....
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Alexandre Beraud . Évalué à 0.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par matiasf . Évalué à 2.
J'ai eu des valeurs similaire avec 2.4.17 . Je n'ai plus retrouvé de telle valeur avec un 2.4.18.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Alexandre Beraud . Évalué à 1.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par matiasf . Évalué à 1.
Lorsque je suis passé sous 2.4.18 j'avais enfin des valeurs cohérentes.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Alexandre Beraud . Évalué à 1.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Olivier Jeannet . Évalué à 0.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Alexandre Beraud . Évalué à 3.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Beretta_Vexee . Évalué à 9.
Le mainteneur de mplayer a été trés claire la dessus ( il a méme laisser partir l'un de ses meillieur dev faire son fork mplayerXP ), le multithreading n'apporterait rien ou presque a mplayer méme sur un systéme SMP, a moin que ce soit des 486 ! mplayer tourne largement sur un processeur méme peut puissant ( 500-600Mhz ), si ton systéme est bien foutue le shudler va equilibrer la charge et foutre mplayer sur l'un des processeur point barre, nul besoin d'utiliser les 2 via des thread puis que 1 est emplement suffisant.
Niveau hypertrucmuche de intel ca prouve simplement gain de 50% de perfs c'est du pipo, et que cette technologie sert simplement a complet la perte de perf du a l'utilisation de trops nombreux threads via une gestion du cache astucieuse dans ce cas precis mais desastreuse pour les autres, mais la on entre dans des interet economique autres ( voir la new sur l'ecart croissant entre AMD et Intel ).
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par pasBill pasGates . Évalué à 6.
Ca permet de :
1) Faire le boulot tant que tu as le temps, tu ne sais pas si dans les 2 minutes qui suivent toto ne va pas lancer une compile avec un make -j 25 pour le fun ou autre truc bourrin qui va etrangler ton mplayer niveau acces CPU
2) Balancer la charge, plutot qu'avoir ton mplayer qui passe de 5 a 20% d'utilisation de temps en temps, la courbe d'utilisation CPU s'adoucit, ce qui est bien mieux point de vue temps de reponse
3) Le design est plus propre, et tire parti au mieux des perfs du systeme. Parce qu'il faut bien se souvenir que les x% de cycles CPU utilises par mplayer pendant un moment donne(et qui auraient pu etre utilise avant quand il n'y avait pas urgence) sont x% de cycles que les autres softs ne peuvent pas utiliser, et peut-etre qu'ils en auraient besoin eux.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Alexandre Beraud . Évalué à 6.
2) Je n'ai jamais constate de telles variations d'occupation du CPU, que ce soit pour
lire du mpeg, du divx ou des DVDs. J'ai en permanence du 22% +ou- 3%. L'interet d'adoucir la courbe se trouve grandement reduit.
3) Oui, mais comme 1)
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par pasBill pasGates . Évalué à 4.
Et le fait est que l'on est en train de se diriger vers ce genre de chose pour les PC de maison aussi, avec genre une machine qui est au centre d'un tas de bordel qu'elle controle, et tout ca tourne en arriere plan, et tu n'as aucune idee de ce que tel periph voudra faire demain pendant que toi tu seras en train de regarder ton DivX ou autre, donc autant faire les choses bien des le debut plutot qu'avoir un design limite qui demandera encore plus de changements plus tard.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par M . Évalué à 1.
Je crains qu'en multithreads ça fasse la meme chose, si le truc un peu lourd dure un peu longtemps, et puis mplayer possede une option cache qui permet d'eviter d'avoir des pb si l'occupation du cpu est de courte durree...
...donc autant faire les choses bien des le debut plutot qu'avoir un design limite qui demandera encore plus de changements plus tard.
oui, mais d'apres le developpeur de mplayer seul les noyeaux recents permetent une gestion correcte des threads et il faudra encore attendre le noyeau 2.5, pour que la frequence passe de 100Hz a 1000hz
Enfin je prefere qu'ils se concentrent sur des choses plus importante (comme un meilleur support des cartes nvidia) avant de penser aux threads...
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
1/ Pour faire, la même tâche si tu utilises 2 threads au lieu d'un seul tu perds des cycles à passer de l'un à l'autre. Si TUX (serveur http noyau) déchire, c'est parce qu'il fait de la zero copie et qu'il n'a PAS un thread par utilisateur. Sur un monoprocesseur, à cause des changement de tâche, tu perds du temps. Si quelqu'un lance un gros boulot, le scheduler doit juste scheduler un thread de plus. Cela ne lui fait que perdre du temps.
Sur un bi-pro (ou SMT), tu repartis la charge, genre 2% sur chaque cpu. Or les partages de mémoire font que les caches sont sous utilisé (en SMP) mais pas en SMT. Or en SMT, si des optimisations typé SMP sont utilisé (grosse séparation des flux mémoire pour éviter de trasher les caches) la pression sur les caches devient énorme (les caches miss s'envole aussi). Les optimisations SMT/SMP sont antagonistes sur la gestion des caches.
2/ Vu que l'ordonanceur à un process/thread de plus à traiter, tu le ralentie. Si tu est sur un bi-pro, dans le cas monothread, un cpu est libre donc le temps de réponse est minimal à un événement extérieur. Ce n'est absoluement pas le cas en multi-thread.
3/ Tu tire mieux parti d'un bi-pro certe mais au détriment du temps de réponse. Tu ne fais que perdre du temps sur un monoprocesseur. Le design est bien plus complexe à maintenir. Cela semble sans doute plus propre pour un serveur mais du point de vue performance c'est pas terrible du tout.
Parce qu'il faut bien se souvenir que les x% de cycles CPU utilises par mplayer pendant un moment donne(et qui auraient pu etre utilise avant quand il n'y avait pas urgence) sont x% de cycles que les autres softs ne peuvent pas utiliser, et peut-etre qu'ils en auraient besoin eux.
A tache égal, un multithread prendra toujours plus de cycle globalement qu'un monothread. Donc, je ne comprends pas ce que tu veux dire.
"La première sécurité est la liberté"
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par pasBill pasGates . É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.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Il est donc parfaitement inutile de programmer un thread pour ça.
De plus, lors d'acces io, si le temps est trop long, le scheduler peut décider de donner la main à un autre process (cela se voit facilement avec l'utilisation d'un lentissime printf). Tu ne perds donc aucun cycle.
Si ta machine ne fait qu'une seule tache, un monothread sans io non bloquante étant bloqué à chaque io, tu perds des perf sur ce process-là uniquement. Mais globalement, ta machine peut faire d'autres trucs. Il n'y a pas de gaspillage.
Si tu veux augmenter les perf c'est-à-dire parraléliser acces disque et calcul, et bien, les io asynchrones ou non bloquantes sont faites pour ça !
"La première sécurité est la liberté"
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par pasBill pasGates . Évalué à 3.
Il est donc parfaitement inutile de programmer un thread pour ça.
Non, ce que je decris c'est une methode naturelle d'utiliser au mieux les perfs, que ta machine soit SMP ou pas, le soft fera au mieux (rien n'interdit d'utiliser les async I/O dans un soft multithread, c'est meme conseille), tout en simplifiant le design.
De plus, lors d'acces io, si le temps est trop long, le scheduler peut décider de donner la main à un autre process (cela se voit facilement avec l'utilisation d'un lentissime printf). Tu ne perds donc aucun cycle.
Exact, ce qui revient a dire que pendant que l'acces I/O s'effectue, ton process qui est sense afficher une video est stoppe.
Hors le but ici ce n'est pas d'economiser au maximum des cycles, c'est d'avoir une video qui s'affiche de maniere fluide, et de faire du boulot en avance en prevision de problemes futurs.
Si les threads s'imposent de plus en plus comme le modele a suivre c'est pas pour rien, c'est definitevement plus efficace que le modele monothread.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
euh ? oui, mais ce n'est pas forcément grave. Ce n'est important que si ton process ne tient pas ses deadlines dans tous les autres cas...
Si tu veux anticipé des brusques indisponnibilités du système, tu utilises des caches. Un asynch io fait le boulot que tu veux faire : lire le bloc suivant pendant que tu traites le bloc courant.
Les thread ne sont pas plus efficaces (sauf lors d'application vraiement interractive et qui ont des phases lente à faire laguer l'affichage comme certain client mail).
Ils sont juste plus facile à coder. L'exemple typique sont les serveurs multi-threadé qui enfle à chaque nouveau connecté. Si TUX (serveur web kernel plus rapide encore que khttpd) déchire tant c'est bien parce que il n'utilise pas un thread par connection !
"La première sécurité est la liberté"
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Schwarzy . Évalué à 2.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Benjamin . Évalué à 2.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par matiasf . Évalué à 3.
1)
2)
3)
> Le desing est plus propre
Il n'y a pas de raison à çà. La lecture de flux video est très séquencielle.
> tire parti au mieux des perfs du systeme.
Le temps de gestion des threads (verrouillage de ressources etc...) il faut bien le payer.
Apache 2 a gagné en perfo en utilisant les threads par rapport à Apache 1.3 car il économisait des fork() . Le fork() étant plus couteux sous windows, c'est sous windows que le gain de perfo est important.
Malheureusement, mplayer ne forke pas ...
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par pasBill pasGates . Évalué à 2.
1) lecture depuis le disque
2) decodage
3) affichage
Vu le type d'operation effectue, il est evident qu'un model multithreade est plus efficace pour ce type de soft.
Faire sequentiellement de la lecture(qui revient a s'arreter et attendre que le systeme d'I/O complete la requete), decodage, puis affichage, c'est perdre du temps.
Tu peux tout a fait avoir un thread qui lit depuis le disque et stocke les buffer en RAM et d'autres threads qui s'occupent du decodage et de l'affichage pendant que l'operation d'I/O du/des buffers suivants est effectuee, ca c'est un modele qui optimise l'utilisation du CPU et qui te donne un player performant.
J'aurais presque envie d'ajouter quelque mots sur les I/O completion ports, mais je vais aller dormir un peu avant :+)
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Tu ne peux que gaspiller de la puissance dans la gestion des thread et le traching de mémoire cache en faisant plus compliqué.
Tu aura peut-être plus de puissance pour tenir des deadline à 500 images/s mais ce n'est pas ça que l'on demande au codec.
"La première sécurité est la liberté"
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Bien sur, on peut aussi faire ça avec les io async mais cela complique aussi le design de l'application.
"La première sécurité est la liberté"
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par matiasf . É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.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par pasBill pasGates . Évalué à 0.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par matiasf . Évalué à 1.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par vrm (site web personnel) . Évalué à 1.
c'est pas evident de passer à de la prog avec des threads sans avoir à reflechirs tout les problemes de sync.
Il y a à gagner en terme de perf (P4 & SMP), mais bon tout recoder avec des threads, les lock et companie ca doit les gonfler
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par matiasf . Évalué à 1.
C'est que la gestion d'une fifo !
Il n'y a qu'un producteur et qu'un consommateur !
Donc le pointeur lecture courante est un mis à jour par un proces.
Le pointeur écriture courante est un mise à jour par un proces.
Il n'y a pas d'écriture d'une même zone mémoire par deux proces différents.
J'aimerai que tu me montres où il est nécessaire d'utilser des sémaphore, spin-lock ou autre !
Faut pas chercher midi à 14 heure.
[^] # ???
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par bleh . Évalué à 1.
A vrai dire c'est justement pour ce genre de situation que Dijkstra a introduit les sémaphores étant donné que la solution proposée par Peterson induisait des inversions de priorité et gachait du temps CPU. Ta solution ne garantit aucune exclusion mutuelle puisqu'il n'y a pas de protection de la mémoire en écriture. Au final, il y'a de très grandes chances pour que les données lues soient incorrectes.
Le problème consommateur/Producteur ne peut pratiquement se résoudre qu'à l'aide de sémaphores ou bien de moniteurs (mais bon c'est très anecdotique) donc, là, il faut chercher midi à 14 heure et utiliser les sémaphores.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
En gros, tu fonctionnes avec un tableau pointeur sur des paquets de donné.
- Tu sauves la valeur de pointeur
- Tu sauves les données à modifier
- Tu modifies les données (ou tu les créait)
- Tu utilise le compare and swap sur la vieille valeur du pointeur et le pointeur, si il a changé retour au début
- sinon, tu a updaté le pointeur.
A prioris, tu ne peux pas perdre de cohérence avec ça. Si tu utilises le même algo partout pour l'acces aux donnés du tableau de pointeurs.
"La première sécurité est la liberté"
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par bleh . Évalué à 1.
En tout cas je pense que si on reste à un niveau supérieur à l'assembleur (le C par exemple), les sémaphores sont l'unique solution à ce problème. Ce qui est drôle c'est que ce problème est assez vieux (les sémaphores datent de 1965, il me semble) mais on continue de chercher des solutions à ce problème :+)
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par matiasf . Évalué à 1.
# Re: document sur le développement de mplayer
Posté par glos . Évalué à 2.
Excuser moi encore ça été plus fort que moi
[^] # Re: document sur le développement de mplayer
Posté par tanguy_k (site web personnel) . Évalué à 0.
[^] # Re: document sur le développement de mplayer
Posté par Yann Hodique (site web personnel) . Évalué à 1.
[^] # Re: document sur le développement de mplayer
Posté par tanguy_k (site web personnel) . Évalué à -2.
si ca termine par "ez" c'est parceque c'est justement pas un infinitif.
"excusez moi"
le verbe est a l'imperatif, ce n'est pas un infinitif
on donne un ordre a l'autre personne, on peut le reformuler par "tu dois m'excuser" et sous cette forme on voit clairement que c'est pas tres polie mais c'est desormais passe dans les moeurs et on y est habitue.
si on remplace le verbe excuser par prendre on ne dit pas "prendre moi" mais "prenez moi" ba la c'est pareil on ecrit pas "excuser moi" mais "excusez moi" (on dit aussi "prend moi" ce qui donne "excuse moi")
On ne s'excuse pas soi meme, on demande gentillement (donc sans imperatif) a la personne de nous excuser.
Donc on s'en sort tres bien si on cherche pas des erreurs la ou il y en a pas. Il faut tremper 7 fois sa plume dans son encrier avant d'ecrire une connerie.
Maintenant tu as le droit de repondre et de demander si je peux t'escuser avec une jolie phrase "je vous prie de bien vouloir m'excuser".
[^] # Re: document sur le développement de mplayer
Posté par Yann Hodique (site web personnel) . Évalué à 1.
Bref... je te renvoie au commentaire un peu plus bas qui est plus complet sur la question de l'orthographe. Il est déjà agaçant d'avoir des commentaires sur une malheureuse faute d'orthographe/grammaire, mais si ce dernier en contient 8 (sans compter les accents)...
-1 (ah non merde ya plus, il serait bien utile pourtant)
[^] # Re: document sur le développement de mplayer
Posté par Olivier Jeannet . Évalué à 2.
«tient j'en rajoute une couche, on ne dit pas "je m'excuse" ni meme "excusez moi" mais "je vous pris de bien vouloir m'excuser"»
- "tient" -> "tiens"
- "je vous pris" -> "je vous prie"
- "excusez moi" -> "excusez-moi".
«parceque s'excusez soi meme tout le monde comprendra que c'est tres mal polie. de meme donnez un ordre avec un verbe a l'imperatif c'est pas mieux»
- "parceque" -> "parce que"
- "s'excusez" -> "s'excuser"
- "soi meme" -> "soi-même"
- "c'est tres mal polie" -> "c'est très malpoli"
Par ailleurs, il manque des virgules dans ton texte, que j'écrirais ainsi :
"parce que s'excuser soi-même, tout le monde comprendra que c'est très malpoli. De même, donner un ordre avec un verbe à l'impératif, ce n'est pas mieux"
[^] # Re: document sur le développement de mplayer
Posté par wismerhill . Évalué à 1.
[^] # Re: document sur le développement de mplayer
Posté par Olivier Jeannet . Évalué à 1.
"ça ne sert pas qu'a jouer à" -> "ça ne sert pas qu'à jouer à" (il y a un accent car il ne s'agit pas du verbe "avoir")
"ça me gène" -> "ça me gêne"
"une idée personnel" -> "une idée personnelle"
Quand à "excuser moi", Tanguy Krotoff a déjà fait la correction mais incomplète car il a oublié le tiret : "excusez-moi".
[^] # Re: document sur le développement de mplayer
Posté par glos . Évalué à 1.
Merci encore.
En esperant ne pas me ramasser un -5. :)
ps:
n'empeche que maintenant dans le titre de la nouvelle il y a bibliotheque. :)
merci encore.
# KMPlayer
Posté par tanguy_k (site web personnel) . Évalué à 10.
http://www.xs4all.nl/~jjvrieze/kmplayer.html(...)
c'est un frontend pour MPlayer pour KDE et ca s'integre a Konqueror/khtml
les commentaires et votes sur apps.kde sont positifs :
http://apps.kde.com/fr/2/info/vid/8515?br=true&sid=dad585ad9dc1(...)
[^] # Re: KMPlayer
Posté par Infernal Quack (site web personnel) . Évalué à 1.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: KMPlayer
Posté par imr . Évalué à 1.
Il faut mettre un type mime spécial?
# Re: Document sur le développement de mplayer
Posté par Michel_lgx . Évalué à 3.
[^] # Re: Document sur le développement de mplayer
Posté par Olivier Jeannet . Évalué à 1.
[^] # Re: Document sur le développement de mplayer
Posté par champi . Évalué à 1.
[^] # Re: Document sur le développement de mplayer
Posté par Michel_lgx . Évalué à 2.
[^] # Re: Document sur le développement de mplayer
Posté par Laurent Saint-Michel . Évalué à 3.
/usr/X11R6/lib/xscreensaver/ifs -root
(le répertoire peut varier en fonction des distribs)
A+
[^] # Re: Document sur le développement de mplayer
Posté par wismerhill . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.