Alors, j'avais bien précisé « parallèle » parce que si ce n'est « que » concurrent, ben du coup ça veut dire que deux processus ou threads peuvent se partager un cœur ou thread matériel et du coup tu n'exploites toujours pas ta machine (voire, au contraire, tu la rend plus lente, car il y a du coup des changements de contexte, des évictions de lignes de cache, etc.). :-)
Ce qui m'intéresse c'est qu'une application exploite la machine au mieux, donc la concurrence c'est bien si tu surcharges la machine de threads (c'est pas forcément une mauvaise idée s'il y a beaucoup d'entrées-sorties), mais si y'a des cœurs dispo, on obtient une machine sous-utilisée.
[à propos de node.js] Tu peu éventuellement lancer plusieurs threads pour en avoir autant que de CPU mais pas plus.
Donc on a bien un comportement parallèle ! VICTORY !
... Ahem.
L'idée c'est que tu ne peux pas faire plus de 4/8/16 choses en parallèles sur une machine selon la CPU. L'idée derrière ça c'est de faire de l'asynchrone plutôt que du vrai parallélisme. Il y a moins de deadlock et on passe moins de temps à faire des changements de contexte.
c'est quelque chose de « classique » en HPC : on module le parallélisme en fonction des ressources matérielles disponibles. Ça inclut le nombre d'unités de calcul (threads matériels, cœurs, etc.), mais aussi la bande-passante pour accéder à la mémoire vive, voire la bande-passante pour accéder à la mémoire de masse si le programme produit ou consomme beaucoup de données.
Bon après dans le cas spécifique du calcul intensif/parallèle, on a aussi des connexions réseau ultra-rapide et spécialisées qui ne nécessitent pas l'utilisation de TCP/IP, ce qui fait que la transmission de données est généralement pas spécialement plus lente qu'accéder à la RAM (voire moins, ça dépend de ce que t'es prêt à payer).
Pour l'histoire de deadlocks je suis un peu circonspect. C'est un fait que plus tu augmentes la concurrence d'un programme plus les problèmes de race condition/data race, ainsi que les problèmes d'accès aux verrous apparaissent vite. Mais réduire le nombre de processus ou threads ne fait que limiter le potentiel pour un deadlock, et ne supprime absolument pas le problème en lui-même : si t'as un deadlock, c'est que y'a un bug quelque part ! :-)
Bon et sinon, viser l'asynchronie, je suis à fond pour... même pour les threads. Plutôt qu'avoir des gros threads qui tournent et doivent explicitement acquérir 12000 verrous pour modifier l'état du système, je préfère des petits threads qui ne peuvent tourner que si toutes leurs dépendances (notamment en termes de données, mais aussi de ressources) sont satisfaites. Par contre en échange, le thread fait une (« petite ») chose, la fait bien, et ne peut plus être interrompu n'importe comment (donc il faut faire attention à comment on les utilise, sous peine de verrouiller toute la machine).
[^] # Re: L'annonce
Posté par lasher . En réponse au journal Grumpy : un nouveau concurrent à pythran. Évalué à 4.
Alors, j'avais bien précisé « parallèle » parce que si ce n'est « que » concurrent, ben du coup ça veut dire que deux processus ou threads peuvent se partager un cœur ou thread matériel et du coup tu n'exploites toujours pas ta machine (voire, au contraire, tu la rend plus lente, car il y a du coup des changements de contexte, des évictions de lignes de cache, etc.). :-)
Ce qui m'intéresse c'est qu'une application exploite la machine au mieux, donc la concurrence c'est bien si tu surcharges la machine de threads (c'est pas forcément une mauvaise idée s'il y a beaucoup d'entrées-sorties), mais si y'a des cœurs dispo, on obtient une machine sous-utilisée.
Donc on a bien un comportement parallèle ! VICTORY !
... Ahem.
c'est quelque chose de « classique » en HPC : on module le parallélisme en fonction des ressources matérielles disponibles. Ça inclut le nombre d'unités de calcul (threads matériels, cœurs, etc.), mais aussi la bande-passante pour accéder à la mémoire vive, voire la bande-passante pour accéder à la mémoire de masse si le programme produit ou consomme beaucoup de données.
Bon après dans le cas spécifique du calcul intensif/parallèle, on a aussi des connexions réseau ultra-rapide et spécialisées qui ne nécessitent pas l'utilisation de TCP/IP, ce qui fait que la transmission de données est généralement pas spécialement plus lente qu'accéder à la RAM (voire moins, ça dépend de ce que t'es prêt à payer).
Pour l'histoire de deadlocks je suis un peu circonspect. C'est un fait que plus tu augmentes la concurrence d'un programme plus les problèmes de race condition/data race, ainsi que les problèmes d'accès aux verrous apparaissent vite. Mais réduire le nombre de processus ou threads ne fait que limiter le potentiel pour un deadlock, et ne supprime absolument pas le problème en lui-même : si t'as un deadlock, c'est que y'a un bug quelque part ! :-)
Bon et sinon, viser l'asynchronie, je suis à fond pour... même pour les threads. Plutôt qu'avoir des gros threads qui tournent et doivent explicitement acquérir 12000 verrous pour modifier l'état du système, je préfère des petits threads qui ne peuvent tourner que si toutes leurs dépendances (notamment en termes de données, mais aussi de ressources) sont satisfaites. Par contre en échange, le thread fait une (« petite ») chose, la fait bien, et ne peut plus être interrompu n'importe comment (donc il faut faire attention à comment on les utilise, sous peine de verrouiller toute la machine).