Pas exactement, un fiber n'a pas d'affinité avec un thread donné, tu peux exécuter ton fiber (poursuivre son exécution) sur n'importe quelle thread disponible (et actif).
Les fiber, sont (était) un outil pour diminuer le nombre de context switching en permettant à un thread de profiter de son quanta complètement. (sachant qu'un context switching arrive sur un sleep, sur l'attente d'un objet de synchro ou à la fin du quota, tu peux éviter ces deux premiers cas à l'aide d'un fiber).
Cependant faut relativiser leur utilité maintenant: le context switching est relativement de moins en moins cher (les cpu deviennent de plus en plus rapide, alors que les quantas CPU alloués par thread n'ont pas diminué de la même façon), et ce qu'on veut éviter quand on cherche des perfs, c'est de perdre sa cache (ce qui coute relativement de plus en plus cher, vu que la mémoire n'évolue pas aussi vite que la fréquence du cache...)
Enfin, je parle pas de parallélisation, mais de montée en charge, il est amha, naif de croire que rendre tout parallèle permet toujours de gagner en temps d'exécution, en fait, c'est même le contraire, une fois arrivé à un CPU par thread, la question est de ne pas bloquer les thread, pas d'en rajouter plus (et comme ce n'est pas toujours possible, ne fut-ce que parce que la plupart des applications requérant de la scalability sont IO bound, faciliter la gestion des threads, ça aide...).
[^] # Re: ...
Posté par tene . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 2.
Les fiber, sont (était) un outil pour diminuer le nombre de context switching en permettant à un thread de profiter de son quanta complètement. (sachant qu'un context switching arrive sur un sleep, sur l'attente d'un objet de synchro ou à la fin du quota, tu peux éviter ces deux premiers cas à l'aide d'un fiber).
Cependant faut relativiser leur utilité maintenant: le context switching est relativement de moins en moins cher (les cpu deviennent de plus en plus rapide, alors que les quantas CPU alloués par thread n'ont pas diminué de la même façon), et ce qu'on veut éviter quand on cherche des perfs, c'est de perdre sa cache (ce qui coute relativement de plus en plus cher, vu que la mémoire n'évolue pas aussi vite que la fréquence du cache...)
Enfin, je parle pas de parallélisation, mais de montée en charge, il est amha, naif de croire que rendre tout parallèle permet toujours de gagner en temps d'exécution, en fait, c'est même le contraire, une fois arrivé à un CPU par thread, la question est de ne pas bloquer les thread, pas d'en rajouter plus (et comme ce n'est pas toujours possible, ne fut-ce que parce que la plupart des applications requérant de la scalability sont IO bound, faciliter la gestion des threads, ça aide...).