Comment pouvons-nous désoptimiser une simulation Monte Carlo pour exposer les goulots d'étranglement du pipeline Intel Sandybridge ?

Désoptimisation d'un programme pour le pipeline dans les processeurs Intel de la famille Sandybridge

Le but de cette mission est de modifier un programme donné pour le rendre courir plus lentement, tout en conservant le même algorithme. Il s'agit de mieux comprendre le fonctionnement du pipeline Intel i7 et la manière dont les chemins d'instructions peuvent être réorganisés pour introduire des dangers.

Aperçu du programme

Le programme est une simulation de Monte-Carlo qui évalue les options d'achat et de vente vanille européennes. Il utilise l'algorithme de Box-Muller pour générer des nombres aléatoires gaussiens et effectue un grand nombre de simulations pour estimer les prix des options.

Incompétence diabolique

L'objectif est de intentionnellement créer du code incompétent qui ralentira l'exécution du programme. Voici quelques idées qui justifient cette approche par une « incompétence diabolique » :

Faux partage

• Créer des structures de données partagées accessibles par plusieurs threads, mais qui sont pas correctement synchronisé. Cela peut entraîner des ping-pong dans la ligne de cache et des effacements du pipeline de spéculation erronée sur l'ordre de la mémoire.

Stalls de transfert de magasin

• Évitez d'utiliser l'opérateur "-" pour les variables à virgule flottante. Au lieu de cela, XOR l'octet de poids fort avec 0x80 pour inverser le bit de signe, provoquant des blocages de transfert de magasin.

Mesure du temps excessif

• Temporiser chaque itération de la boucle principale avec une opération lourde comme CPUID/RDTSC, qui sérialise les instructions et bloque le pipeline.

Opérations mathématiques défavorables

• Remplacer les multiplications par des constantes par des divisions par leur réciproque ("pour faciliter la lecture"). La division est plus lente et n'est pas entièrement pipeline.

Vectorisation inefficace

• Vectorisez les opérations de multiplication/sqrt avec AVX, mais ne parvenez pas à utiliser vzeroupper avant d'appeler fonctions de bibliothèque mathématique scalaire, provoquant une transition AVX<>SSE stalls.

Structures de données

• Stockez la sortie RNG dans une liste chaînée ou dans des tableaux qui sont parcourus dans le désordre. Faites de même pour le résultat de chaque itération et additionnez à la fin. Cela introduit des charges de poursuite de pointeur et défait la localité du cache.

Utilisation abusive du multithread

• Multi-thread du programme mais force les deux threads à partager le même compteur de boucles (avec des incréments atomiques) pour créer de faux partages et conflits. Cela introduit également une surcharge inutile des opérations atomiques.

Autres suggestions

• Introduisez des branches imprévisibles pour créer des erreurs de prédiction et des vidages de pipeline.
• Utilisez des justifications diaboliquement incompétentes pour augmenter la longueur des chaînes de dépendances portées par des boucles.
• Introduisez des modèles d'accès à la mémoire non contigus pour minimiser l'utilisation du cache.
• Pour plus crédit : Écrivez votre propre algorithme de racine carrée pour remplacer celui fourni dans le devoir.

Impact des modifications

Ces modifications devraient avoir un impact significatif ralentir l'exécution du programme en introduisant des blocages de pipeline, des échecs de cache et d'autres goulots d'étranglement en termes de performances. La mission encourage la créativité et la volonté d'explorer différentes méthodes de pessimisation du code tout en conservant l'algorithme d'origine.

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!