Comme dit plus haut. Ca dépend de ce que tu veux faire... Décider qu'une archi est meilleure qu'une autre abstraitement ca me parait assez léger.
Pour de l'HPC je ne vois pas de cas ou ca pourrait se justifier effectivement. Pour des serveurs là ca se discute. Je ne dis pas que c'est toujours une bonne solution, car ce n'est pas le cas. Si c'est pour écrire un serveur HTTP qui livre du contenu statique ca semble pas la meilleure option effectivement. Par contre je dis qu'il existe des cas où une architecture comme cela fait sens.
Il y a des très gros à priori sur les perfs de ce modele alors que les bench montrent que quand c'est adapté ca marche plutot bien tant niveau perf que scalabilité (je me souviens de http://www.mailinator.com/tymaPaulMultithreaded.pdf).
Le problème du multithreadé c'est que derrière de bonnes intentions ca reste assez facile de fracasser ces perfs théoriques sur des erreurs. Il y a très peu de gens capable designer et d'implémenter quelque chose de performant de bout en bout. Et tu te retrouves effectivement à faire des bêtes thread pools, avec gavé de structure partagées, ou t'auras quand même gras de context switchs et de perte d'affinitée proc, sans pouvoir gérer les pics de charge, et tu supposes que ton résultat est plus performant et plus scalable que l'autre solution. Pas dit... Je vais pas trop détailler mais si ca t'intéresse y'a de très bons articles sur l'implémentation correcte d'un producteur/consommateur là: http://mechanical-sympathy.blogspot.com/ . Et encore une fois une telle archi ne s'adapte pas à tout les problèmes, ni tout les protocoles.
[^] # Re: En clair
Posté par ckyl . En réponse au journal Vente liée : comment se tirer soi-même une balle dans le pied. Évalué à 4.
Comme dit plus haut. Ca dépend de ce que tu veux faire... Décider qu'une archi est meilleure qu'une autre abstraitement ca me parait assez léger.
Pour de l'HPC je ne vois pas de cas ou ca pourrait se justifier effectivement. Pour des serveurs là ca se discute. Je ne dis pas que c'est toujours une bonne solution, car ce n'est pas le cas. Si c'est pour écrire un serveur HTTP qui livre du contenu statique ca semble pas la meilleure option effectivement. Par contre je dis qu'il existe des cas où une architecture comme cela fait sens.
Il y a des très gros à priori sur les perfs de ce modele alors que les bench montrent que quand c'est adapté ca marche plutot bien tant niveau perf que scalabilité (je me souviens de http://www.mailinator.com/tymaPaulMultithreaded.pdf).
Le problème du multithreadé c'est que derrière de bonnes intentions ca reste assez facile de fracasser ces perfs théoriques sur des erreurs. Il y a très peu de gens capable designer et d'implémenter quelque chose de performant de bout en bout. Et tu te retrouves effectivement à faire des bêtes thread pools, avec gavé de structure partagées, ou t'auras quand même gras de context switchs et de perte d'affinitée proc, sans pouvoir gérer les pics de charge, et tu supposes que ton résultat est plus performant et plus scalable que l'autre solution. Pas dit... Je vais pas trop détailler mais si ca t'intéresse y'a de très bons articles sur l'implémentation correcte d'un producteur/consommateur là: http://mechanical-sympathy.blogspot.com/ . Et encore une fois une telle archi ne s'adapte pas à tout les problèmes, ni tout les protocoles.