> ça fait la répartition de charge en gardant un nombre de threads égal au nb de cores
C'est bien pour des trucs mathématiques, etc. Des trucs qui se parallélise bien (voire "à l'infini"). Des trucs avec peu de dépendances entre eux. Mais il y a des "trucs" qui demandent 3 threads (et pas plus). Tu ne peux pas tout paralléliser "à l'infini".
> ça propose des structures de données thread-safe
Ça c'est cool.
> ça répond très clairement à un besoin
Je n'ai pas dit que ça ne servait à rien !
Code une applie multi-thread optimisée aux petits oignons pour utiliser à fond du multi-cpu et tu vas comprendre comme c'est hard et difficilement généralisable. Actuellement je fais un programme pour de la vidéo (temps-réel) et c'est un enfer. L'enfer ce n'est pas de mettre un lock ou un signal ici ou là. C'est de savoir où le mettre et s'il faut le mettre. C'est la conception qui est prise de tête, la réalisation est moins prise de tête (il faut coder "comme d'hab"). TBB semble aider à la réalisation. C'est toujours ça de pris. Il y des applis qui se parallélisent bien. Certains calculs mathématiques, les serveurs, etc...
Par exemple pour un serveur avec x clients, tu vas avoir x threads. Et s'il y a deux fois plus de clients, tu as deux fois plus threads. Si tu ne veux pas faire écrouler la bécane avec des milliers de thread, tu mets des clients en attente (pool) et ne fait tourner que le nombre de thread qui correspond au nombre de cpu (ça permet aussi de profiter des spinlock et d'éviter des appels système). Ce type de besoin est assez générique et TBB semble y répondre. Comme make peut faire tourner plusieurs compilations à la fois par exemple. Mais il y a d'autres domaines très dificile. Va par exemple multi-threader Firefox pour que Firefox ne semble pas "freezer" lorsqu'il calcule une page (genre une dépêche linuxfr avec pleins de commentaires). Pour que les menus soit toujours dispos, qu'on puisse se promener dans les tab et les lire alors qu'il calcul le rendu d'une grosse dépêche linuxfr.
[^] # Re: Multicoeur ?
Posté par IsNotGood . En réponse à la dépêche Intel libère TBB. Évalué à 0.
C'est bien pour des trucs mathématiques, etc. Des trucs qui se parallélise bien (voire "à l'infini"). Des trucs avec peu de dépendances entre eux. Mais il y a des "trucs" qui demandent 3 threads (et pas plus). Tu ne peux pas tout paralléliser "à l'infini".
> ça propose des structures de données thread-safe
Ça c'est cool.
> ça répond très clairement à un besoin
Je n'ai pas dit que ça ne servait à rien !
Code une applie multi-thread optimisée aux petits oignons pour utiliser à fond du multi-cpu et tu vas comprendre comme c'est hard et difficilement généralisable. Actuellement je fais un programme pour de la vidéo (temps-réel) et c'est un enfer. L'enfer ce n'est pas de mettre un lock ou un signal ici ou là. C'est de savoir où le mettre et s'il faut le mettre. C'est la conception qui est prise de tête, la réalisation est moins prise de tête (il faut coder "comme d'hab"). TBB semble aider à la réalisation. C'est toujours ça de pris. Il y des applis qui se parallélisent bien. Certains calculs mathématiques, les serveurs, etc...
Par exemple pour un serveur avec x clients, tu vas avoir x threads. Et s'il y a deux fois plus de clients, tu as deux fois plus threads. Si tu ne veux pas faire écrouler la bécane avec des milliers de thread, tu mets des clients en attente (pool) et ne fait tourner que le nombre de thread qui correspond au nombre de cpu (ça permet aussi de profiter des spinlock et d'éviter des appels système). Ce type de besoin est assez générique et TBB semble y répondre. Comme make peut faire tourner plusieurs compilations à la fois par exemple. Mais il y a d'autres domaines très dificile. Va par exemple multi-threader Firefox pour que Firefox ne semble pas "freezer" lorsqu'il calcule une page (genre une dépêche linuxfr avec pleins de commentaires). Pour que les menus soit toujours dispos, qu'on puisse se promener dans les tab et les lire alors qu'il calcul le rendu d'une grosse dépêche linuxfr.
Bonne chance :-) Avec TBB ou non.