Pourquoi mon code Go simultané est-il plus lent que son homologue séquentiel ?

Pourquoi l'ajout de la concurrence ralentit-il ce code Go ?

Cette question explore la dégradation inattendue des performances lors de l'introduction de la concurrence dans un programme Go existant. Le code simule les interactions avec des monstres dans un jeu, en gardant une trace des chutes d'objets réussies. Pour améliorer l'efficacité, le programmeur a essayé de répartir la charge de travail entre les processeurs disponibles en utilisant la concurrence, mais cela a entraîné un ralentissement significatif.

Code original et performances

Sans concurrence, le programme exécute une série de simulations. (1 000 dans ce cas), et chaque simulation exécute un nombre spécifié d'interactions (1 000 000 dans cet exemple). Les résultats sont ensuite utilisés pour calculer le nombre total d'interactions réussies.

Modification de la concurrence

Pour paralléliser le code, le programmeur crée plusieurs goroutines, chacune chargée d'exécuter une partie des simulations. Ils répartissent correctement la charge de travail entre les processeurs disponibles, en faisant correspondre le nombre de goroutines au nombre de processeurs.

Ralentissement inattendu

Étonnamment, au lieu d'améliorer les performances, le code simultané s'est exécuté 4 à 6 fois plus lent que son homologue séquentiel.

Cause fondamentale

Le problème réside dans le fait que l'état partagé est accessible par des goroutines simultanées. Plus précisément, la fonction rand.Float64() utilise une instance Rand globale partagée avec un verrou mutex associé. Lorsque plusieurs goroutines tentent d'accéder à l'instance Rand globale, elles doivent acquérir le verrou mutex, ce qui entraîne des conflits et ralentit le code.

Solution

Pour résoudre le problème de performances, le programmeur crée un instance Rand distincte pour chaque goroutine. Cela élimine les conflits pour l'instance Rand globale, permettant aux goroutines de s'exécuter indépendamment.

Amélioration des performances

La création d'une instance Rand distincte pour chaque goroutine améliore considérablement les performances. Le code concurrent s'exécute désormais environ 2,5 fois plus rapidement que la version non simultanée sur un processeur double cœur.

Leçon apprise

Ce scénario démontre l'importance de comprendre les mécanismes de synchronisation utilisés par les ressources partagées. lors de la mise en œuvre de la concurrence. Cela souligne l'impact des modèles d'accès aux données sur les performances et la nécessité de prendre en compte le compromis entre l'utilisation du processeur et la surcharge de synchronisation.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!