Tu m'épates là ! Tes arguments sont complétements à inverser.
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.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Document sur le développement de mplayer. É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é"