Il y a quelques années, dans l'environnement Windows, j'ai fait des tests, en laissant plusieurs instances de calcul de la CPU intensive + accès à la mémoire intensive + E / S Access intensif de l'application. J'ai développé 2 versions: l'une est exécutée sous la multi-traitement, une autre fonctionne sous la multi-threading. P>
J'ai trouvé que la performance est bien meilleure pour la multi-traitement. J'ai lu ailleurs (mais je ne me souviens pas du site). p>
qui stipule que la raison est que, sous la multi-threading, ils "se battent" pour un pipeline de mémoire unique et un pipeline d'E / S, qui rend la performance pire par rapport au multi-traitement fort> p>
Cependant, je ne trouve plus cet article. Je me demandais jusqu'à ce que ce soit aujourd'hui, si le ci-dessous est toujours vrai? P>
dans Windows, avoir l'algorithme
Code exécuté sous traitement multi-traitement, il y a un haut
chance que la performance soit
mieux que multi-threading. p>
blockQuote>
3 Réponses :
Je ne suis pas sûr de ce que signifie même la citation. C'est très proche de non-sens. P>
La principale chose que les threads in-processus partagent est un espace d'adresse de mémoire virtuelle. P>
Cela dépend de la manière dont les différents threads ou processus (je vais utiliser le terme collectif "tâches" pour les deux) doivent communiquer, notamment en partageant la mémoire: c'est facile, bon marché et rapide pour les threads, mais pas Pour le tout pour les processus, si beaucoup de choses se passent, je parie que la performance des processus est pas em> va battre les threads '. P>
En outre, les processus (en particulier sur Windows) sont "plus lourds" pour commencer, de sorte que si beaucoup de "démarrages de tâches" se produisent, les threads peuvent facilement battre les processus en termes de performances. P>
Ensuite, vous pouvez avoir des processeurs avec "hyperthreading", qui peuvent exécuter (au moins) deux threads sur un noyau très rapidement - mais non les processus (puisque les threads "hyperthread" ne peuvent pas utiliser des espaces d'adresses distincts) - Encore un autre cas dans lequel les threads peuvent gagner la performance-sage. P>
Si aucune de ces considérations ne s'applique, la course ne devrait pas être meilleure qu'une cravate, de toute façon. P>
J'ai trouvé que cela est vrai aussi. Mais je pense que cela a quelque chose à voir avec la planification. Parce que si vous l'exécutez assez longtemps, les multi-processus sont aussi rapides que les multi-threads. Ce nombre est d'environ 10 secondes. Si l'algorithme doit être exécuté pendant 10 secondes. Les multi-processus sont aussi rapides que multi-thread. Mais si cela n'a besoin que de courir pendant moins de 1 seconde. Les multi-processus sont beaucoup plus rapides que multi-threads. p>