Utiliser l’optimisation guidée par des profils d’exemple (SPGO) pour améliorer les performances en C++

Profile-Guided Optimisation (PGO) utilise des données d’exécution pour aider le compilateur à prendre de meilleures décisions d’optimisation. À l’aide des données de profil d’exécution collectées à partir de charges de travail représentatives, PGO permet au compilateur de prendre des décisions plus intelligentes sur l’incorporation, la disposition du code et la séparation du code chaud/froid. Ces décisions sont impossibles à prendre à partir de l’analyse statique seule.

SPGO adopte une approche différente. Au lieu d’instrumenter votre binaire et de l’exécuter via des scénarios d’apprentissage synthétique, SPGO utilise l’échantillonnage de compteurs de performances matériels collectés à partir de vos fichiers binaires de mise en production réels. Les processeurs modernes offrent des fonctionnalités d’échantillonnage matériel. Vous pouvez collecter ces exemples avec une surcharge d’exécution négligeable, ce qui permet de collecter des profils d’exécution directement à partir du code de production.

Étant donné que les profils SPGO libèrent des bits au lieu des builds instrumentées, il offre beaucoup plus de flexibilité dans l’emplacement et la façon dont vous collectez des données. Vous pouvez collecter des profils d’exécution à partir de serveurs de production, de machines de développement, de laboratoires de performances ou de n’importe quelle combinaison. Il en résulte un binaire qui exécute plus efficacement les portions de code les plus sollicitées, avec un gain de performances typique de 5 à 15 % selon la qualité des données de profilage.

Dans ce tutoriel, vous allez parcourir le flux de travail SPGO complet : créez un exemple d’application, profilez-le à l’aide xperf, préparez les données de profil et régénérez-les avec les données de profil. Lorsque vous avez terminé, vous pouvez appliquer le même processus à vos propres projets.

Prerequisites

Avant de commencer, vérifiez que vous disposez des logiciels et du matériel suivants.

Software

• MSVC build tools for x64/x86/ARM64 v14.51 ou version ultérieure : installez-les via le programme d’installation de Visual Studio. Sous Composants individuels, recherchez « Outils de génération MSVC ».
• Windows Performance Toolkit (xperf.exe) : le profileur xperf collecte des exemples de données pendant l'exécution de votre programme. Téléchargez l’Windows Assessment and Deployment Kit (ADK) à partir de ADK install. Lorsque vous exécutez le programme d’installation d’ADK, sélectionnez le composant Windows Performance Toolkit pour obtenir xperf. Vous n’avez pas besoin d’installer l’ADK complet.
• Fichier texte War and Peace : utilisé comme exemple de charge de travail pour générer des données de profilage. Téléchargez-le à partir de Project Gutenberg : https://www.gutenberg.org/ebooks/2600. Enregistrez-le sous forme de fichier texte brut dans votre répertoire de travail.

Configuration matérielle requise

Le didacticiel comporte trois chemins de profilage. Le chemin d’accès que vous utilisez dépend de votre matériel. Vous exécutez des commandes de détection dans Choisir votre méthode de profilage pour déterminer le chemin pris en charge par votre ordinateur. Pour l’instant, utilisez ce tableau pour confirmer que vous remplissez au moins l’une des conditions requises.

La plupart des ordinateurs de bureau x64 modernes prennent en charge le LBR. Les machines virtuelles et certains matériels plus anciens ont PMC ou un minuteur de système d’exploitation.

Fonctionnement de SPGO

SPGO collecte les données de profil à partir de votre fichier binaire en cours d’exécution et les alimente vers le compilateur lors de la prochaine génération. Le compilateur utilise ces données pour prendre de meilleures décisions sur l’incorporation, la disposition du code et la prédiction de branche. Une commodité est qu’aucune instrumentation n’est requise.

Le flux de travail est le suivant :

1. Générez votre fichier binaire avec l’indicateur de l’éditeur de liens /spgo . Cette étape crée un exemple de base de données de profil vide (.spd fichier).
2. Profilez le fichier binaire à l’aide de xperf pour produire un fichier de trace ETL.
3. Convertissez l’ETL en fichier SPT à l’aide SPTAggregate.exede , puis convertissez le SPT en fichier SPD à l’aide SPDConvert.exede .
4. Regénérer avec l’indicateur de l’éditeur de liens /spdin pointant vers l’exemple de base de données de profil rempli (SPD). L’éditeur de liens applique des optimisations SPGO.

L’optimiseur utilise le SPD pour répondre à des questions telles que : quelles branches sont prises le plus souvent ? Quelles fonctions sont appelées dans des boucles chaudes ? Ce processus produit une meilleure disposition du code et des décisions d’incorporation que l’analyse statique seule.

SPGO fonctionne avec C et C++. Le flux de travail et les indicateurs sont identiques pour les deux langues.

Meilleurs candidats pour SPGO : Applications C/C++ volumineuses et remplies de branches avec des boucles internes serrées. Les gains augmentent avec la taille de la base de code et la complexité des branches. Le petit exemple de ce tutoriel montre environ 7% amélioration. Les bases de code de production plus volumineuses voient souvent plus d’amélioration.

Comparaison du processus de compilation

Cette section présente comment SPGO s’intègre dans le pipeline de compilation si vous souhaitez en comprendre le fonctionnement.

Processus de génération normal

Dans une build de version C/C++ standard :

• Entrées: Fichiers de code source (.cpp, .h) et indicateurs de compilateur en mode mise en production (/O2, /GLetc.).
• Processus: Le compilateur applique des optimisations standard telles que l’incorporation d’heuristiques, les hypothèses de prédiction de branche et les décisions de disposition de code basées uniquement sur l’analyse statique. Il n’a pas de données sur le comportement du programme lorsqu’il s’exécute.
• Sortie: Exécutable (.exe), fichiers DLL (.dll), informations de débogage (.pdb).

Sans données d’exécution, les chemins d’accès chauds et les chemins froids reçoivent un traitement similaire.

Processus de génération avec SPGO

SPGO ajoute des données de profilage en tant qu’entrée au pipeline de build :

• Entrées: Code source, .spd fichier de profil (exemples de nombres à partir d’une exécution de profilage), indicateurs du compilateur en mode mise en production, /link /spgoet /spdin:<path> pour spécifier un fichier SPD d’entrée (s’il n’est pas spécifié, est défini par défaut sur un .spd à l’aide du nom binaire et situé dans le dossier obj).
• Processus: L’éditeur de liens lit le SPD en même temps que le code intermédiaire. Il utilise des données de fréquence des branches pour prendre de meilleures décisions d’intégration en ligne, de disposition du code et d’ordonnancement des branches. Les fonctions chaudes sont disposées pour un accès rapide ; le code froid sort du chemin critique.
• Sortie: Exécutable optimisé (.exe), fichiers DLL optimisés (.dll), informations de débogage (.pdb) et nouveau .spd fichier pour les futures itérations de profilage.

L’idée essentielle : SPGO fait passer les décisions d’optimisation des heuristiques du compilateur et de l’éditeur de liens à des choix fondés sur des données issues de l’exécution réelle.

Indicateurs clés

Différences entre SPGO et PGO

PGO (Profile-Guided Optimisation) vous oblige à compiler votre fichier binaire avec des indicateurs d’instrumentation (/GENPROFILE), à exécuter le binaire instrumenté lent pour collecter les .pgc fichiers de nombre d’exécutions, puis à relinker avec /USEPROFILE. Le compilateur obtient le nombre exact d’exécutions, mais vous devez d’abord instrumenter le code. Pour plus d’informations sur ce processus, consultez optimisations guidées par profil.

SPGO utilise des compteurs de performances de processeur matériel pour collecter des échantillons statistiques à partir de votre binaire de mise en production nontrumentée. Exécutez votre binaire existant, analysez-le à l’aide de xperf, convertissez la trace en un fichier SPD, puis recompilez. Il n’y a ni version instrumentée ni ralentissement lors du profilage. Le compilateur obtient des données d’échantillonnage statistique au lieu de nombres exacts, ce qui est moins précis, mais plus facile à obtenir et ne nécessite aucune modification du code. Il permet également le profilage des composants système ou des composants en temps réel qui sont difficiles à collecter des données pour une approche instrumentée. Vous pouvez également profiler les fichiers binaires finals/d’expédition.

Ce tutoriel traite de trois méthodes de profilage : LBR, PMC et minuteur de système d’exploitation. Vous choisissez votre méthode dans Choisir votre méthode de profilage. Pour obtenir une comparaison détaillée du processus de génération normal par rapport au processus de génération SPGO, y compris une table de référence d’indicateur, consultez Comparaison des processus de génération.

Configurer perfcore.ini

⚠️ Obligatoire : sans cette étape, xperf ne fournit pas les données de profilage nécessaires. Effectuez cette étape avant d’exécuter xperf.

Le Windows Performance Toolkit (WPT) utilise perfcore.ini, situé si vous avez installé wpT à l’emplacement par défaut à C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\perfcore.ini, pour inscrire les fournisseurs DLL dont il a besoin pour SPGO.

Ouvrez Windows Bloc-notes en tant qu’administrateur. Ouvrez ensuite perfcore.ini. Recherchez la section liste DLL et ajoutez les entrées suivantes, une par ligne :

perf_spt.dll
perf_lbr.dll

Si xperf.exe n’est pas installé, consultez Problèmes généraux pour l’installer.

Enregistrez et fermez perfcore.ini. Les fichiers DLL sont déjà fournis dans le même répertoire que xperf.exe vous n’avez donc pas besoin de les copier n’importe où. Vous ne les enregistrez que dans perfcore.ini. Assurez-vous que xperf se trouve dans votre variable PATH.

Créer l’exemple d’application

L’exemple d’application de ce tutoriel est un programme C++ qui lit le texte à partir d’une entrée standard et produit un nombre de lignes, un nombre de mots, un nombre total de caractères, une table de fréquences de caractères et un temps écoulé pour traiter le fichier en millisecondes. Il est écrit en C++, mais SPGO fonctionne également avec C. Le flux de travail est identique pour les projets C.

Créez un fichier nommé textCount.cpp dans votre répertoire de travail et ajoutez le code source suivant :

// textCount.cpp : Text Statistics Counter
// Counts words, lines, and character frequencies from standard input
// Usage: textCount < file.txt

#include <iostream>
#include <string>
#include <map>
#include <cctype>
#include <chrono>

int main()
{
    auto start = std::chrono::steady_clock::now();

    std::map<unsigned char, int> charFrequency;
    int wordCount = 0;
    int lineCount = 0;
    int totalChars = 0;

    std::string line;
    bool inWord = false;

    while (std::getline(std::cin, line))
    {
        lineCount++;

        for (char c : line)
        {
            totalChars++;
            unsigned char uc = static_cast<unsigned char>(c);
            charFrequency[uc]++;

            if (std::isspace(static_cast<unsigned char>(c)))
            {
                inWord = false;
            }
            else
            {
                if (!inWord)
                {
                    wordCount++;
                    inWord = true;
                }
            }
        }

        inWord = false;
    }

    std::cout << "\n=== TEXT STATISTICS ===" << std::endl;
    std::cout << "Lines: " << lineCount << std::endl;
    std::cout << "Words: " << wordCount << std::endl;
    std::cout << "Total Characters: " << totalChars << std::endl;

    std::cout << "\n=== CHARACTER FREQUENCIES ===" << std::endl;

    std::cout << "\nLetters:" << std::endl;
    for (unsigned char ch = 'a'; ch <= 'z'; ch++)
    {
        unsigned char upperCh = static_cast<unsigned char>(std::toupper(ch));
        int count = charFrequency[ch] + charFrequency[upperCh];
        if (count > 0)
        {
            std::cout << static_cast<char>(ch) << ": " << count << std::endl;
        }
    }

    std::cout << "\nDigits:" << std::endl;
    for (unsigned char ch = '0'; ch <= '9'; ch++)
    {
        if (charFrequency[ch] > 0)
        {
            std::cout << static_cast<char>(ch) << ": " << charFrequency[ch] << std::endl;
        }
    }

    std::cout << "\nSpecial Characters:" << std::endl;
    for (const auto& pair : charFrequency)
    {
        unsigned char ch = pair.first;
        if (!std::isalnum(ch))
        {
            std::string displayChar;
            switch (ch)
            {
                case ' ': displayChar = "[space]"; break;
                case '\t': displayChar = "[tab]"; break;
                case '\n': displayChar = "[newline]"; break;
                case '\r': displayChar = "[return]"; break;
                default:
                    if (ch >= 32 && ch < 127)
                    {
                        displayChar = std::string(1, static_cast<char>(ch));
                    }
                    else
                    {
                        displayChar = "[byte:" + std::to_string(static_cast<int>(ch)) + "]";
                    }
                    break;
            }
            std::cout << displayChar << ": " << pair.second << std::endl;
        }
    }

    auto end = std::chrono::steady_clock::now();

    auto elapsed = std::chrono::duration<double, std::milli>(end - start);
    std::cout << "Elapsed time: " << std::fixed;
    std::cout.precision(3);
    std::cout << elapsed.count() << " ms\n";

    return 0;
}

Générer et exécuter l’exemple pour obtenir une base de référence

Avant d’appliquer SPGO, générez textCount et exécutez-le sur un fichier texte volumineux, tel que War and Peace (vous pouvez le télécharger à partir de Project Gutenberg), pour voir la vitesse d’exécution. Cette étape vous montre les performances avant de l’optimiser à l’aide de SPGO :

Construire:

cl /EHsc /GL /O2 textCount.cpp

Exécuter:

textCount.exe < warAndPeace.txt

Vous voyez un résultat similaire à :

=== TEXT STATISTICS ===
Lines: 66041
Words: 566333
Total Characters: 3227531

=== CHARACTER FREQUENCIES ===

Letters:
a: 202719
...

Elapsed time: 512.000 ms

Enregistrez la valeur Elapsed time. Vous la comparerez au temps optimisé pour SPGO dans Mesurer les résultats.

Générer textCount avec /spgo

Maintenant, générez textCount avec SPGO activé. Cette étape définit le travail de base pour collecter des données de profilage.

cl /EHsc /GL /O2 textCount.cpp /link /debug /spgo

Une fois la build terminée, vous voyez un message comme suit :

SPD textCount.spd not found, compiling without profile guided optimizations

Ce message s’affiche sur la première /spgo build. L’éditeur de liens crée le fichier SPD, mais il est toujours vide. Il n’applique donc pas encore d’optimisations SPGO. Une fois que vous avez exécuté le fichier binaire, collectez les données de profil et convertissez-les en SPD, vous ne verrez pas ce message.

Explications d’indicateur :

L’indicateur /spgo n’optimise pas encore le binaire. Il le prépare pour le profilage. L’optimisation se produit dans Rebuild textCount avec /spdin une fois que le SPD est rempli avec des données d’exécution réelles.

Choisir votre méthode de profilage

SPGO prend en charge trois méthodes de profilage. La méthode que vous utilisez dépend de votre matériel.

Les trois méthodes de profilage

Avec le mode PMC /IP, chaque interruption matérielle vous donne un seul point de données : « le processeur était à l’adresse 0x1A2B3C4D lorsque l’interruption a été déclenchée ». Avec LBR, chaque interruption vous donne une pile des dernières branches 16 à 32 que le processeur a pris avant le déclenchement de l’interruption. L’optimiseur obtient de meilleures données de flux de contrôle et peut prendre de meilleures décisions en matière d’incorporation et de disposition.

Détectez votre chemin

Exécutez les deux commandes suivantes pour déterminer la méthode de profilage prise en charge par votre machine. Ces commandes ne nécessitent pas d’invite de commandes élevée.

Étape 1 : Recherchez la prise en charge de LBR. Ce test fonctionne sur Intel/AMD/ARM64.

Exécutez ce qui suit depuis une invite de commandes de développeur Visual Studio administrateur :

xperf.exe -on PMC_PROFILE -pmcprofile TotalIssues -LastBranch PmcInterrupt -setProfInt TotalIssues 2560000
xperf -stop -d lbrtest.etl
xperf -tle -i lbrtest.etl -a dumper | findstr "LBR,  TimeStamp"

• Si cette commande trouve une ligne contenant LBR, TimeStamp, votre ordinateur prend en charge LBR. Utilisez le chemin LBR.
• Sinon, passez à l’étape 2.

Étape 2 : Vérifier la prise en charge de PMC (sans LBR)

xperf.exe -pmcsources | findstr TotalIssues

• Si cette commande produit une sortie, votre ordinateur prend en charge les compteurs PMC, mais pas LBR. Utilisez le chemin PMC.
• Si cette commande ne produit aucune sortie, utilisez le chemin du minuteur du système d’exploitation.

Pour plus d’informations sur la collection d’événements PMU avec xperf, consultez Enregistrer des événements PMU matériels avec xperf.

Tableau de décision

Choisir votre approche

Déterminez s’il faut utiliser le chemin du minuteur LBR, PMC ou OS en fonction des résultats de la détection. Chaque chemin d’accès a des paramètres de démarrage différents xperf pour collecter les données de profilage appropriées. Suivez le chemin qui correspond à vos fonctionnalités matérielles.

Votre chemin d’accès :

• Utilisateurs de LBR (LBR détecté à l’étape 1) : accédez à chemin d’accès LBR.
• Pour les utilisateurs PMC (InstructionRetired détecté à l’étape 2) : accédez à Chemin PMC (sans LBR).
• Utilisateurs du minuteur de système d’exploitation (machine virtuelle ou matériel sans PMU) : accédez au chemin du minuteur du système d’exploitation.

Tous les parcours se rejoignent à l’étape Exécuter la charge de travail et arrêter xperf.

Les commandes de cette section dépendent du chemin d’accès de profilage que vous avez identifié dans Choisir votre méthode de profilage. Recherchez la sous-section qui correspond à votre chemin d’accès, exécutez la xperf commande de démarrage, puis continuez à exécuter la charge de travail et arrêtez xperf pour exécuter la charge de travail et arrêter xperf.

⚠️ Exécuter en tant qu’administrateur :xperf nécessite une invite de commandes de développeur avec élévation de privilèges (administrateur). Sans élévation, xperf retourne "failed to configure counters".

Chemin d’accès LBR

Commencez avec xperf la collection LBR :

xperf -on LOADER+PROC_THREAD+PMC_PROFILE -MinBuffers 4096 -MaxBuffers 4096 -BufferSize 4096 -pmcprofile BranchInstructionRetired -LastBranch PmcInterrupt -setProfInt BranchInstructionRetired 16384

Explication des paramètres :

Après avoir démarré xperf, continuez à exécuter la charge de travail et arrêtez xperf.

Chemin PMC (sans LBR)

Commencez xperf avec la collecte en mode PMC / IP :

xperf -on LOADER+PROC_THREAD+PMC_PROFILE+PROFILE -MinBuffers 4096 -BufferSize 4096 -pmcprofile InstructionRetired -setProfInt InstructionRetired 16384 -stackwalk profile

Explication des paramètres :

Par rapport à LBR : pas d’indicateur -LastBranch ; utilise InstructionRetired au lieu de BranchInstructionRetired. Le résultat est des exemples de pointeurs d’instructions avec des piles d’appels, et non des séquences de branche. Ce chemin fournit toujours des données efficaces pour l’optimiseur, mais il est légèrement moins riche.

Après avoir démarré xperf, continuez à exécuter la charge de travail et arrêtez xperf.

Chemin d’accès du minuteur du système d’exploitation

Démarrez xperf avec l’échantillonnage basé sur le minuteur du système d’exploitation :

xperf -on LOADER+PROC_THREAD+PROFILE -MinBuffers 4096 -BufferSize 4096 -setProfInt Timer 1221 -stackwalk profile

Explication des paramètres :

Par rapport à LBR et PMC, cette méthode n’utilise pas de compteurs de performances matérielles. Le minuteur du système d’exploitation se déclenche à peu près à intervalles de temps fixes, quelle que soit l’activité du processeur. Les exemples sont moins densement corrélés au code chaud, mais fournissent toujours des données de flux de contrôle utiles pour l’optimiseur.

Exécuter la charge de travail et arrêter xperf (tous les chemins)

Une fois xperf en cours d’exécution, exécutez textCount sur « Guerre et Paix » :

textCount.exe < warAndPeace.txt

Une fois textCount terminé, arrêtez xperf et écrivez le fichier de trace. Laisser d’autres processus s’exécuter pendant le profilage dilue la qualité de l’échantillon. Pour obtenir de meilleurs résultats, fermez les applications inutiles avant d’exécuter la charge de travail.

xperf -stop -d textCount.etl

Après avoir arrêté xperf (cela peut prendre un certain temps pour écrire le fichier ETL), vérifiez que textCount.etl a été créé dans le répertoire courant.

Convertir le fichier ETL en SPT

Cette étape est la même pour les trois chemins de profilage.

Exécutez SPTAggregate.exe pour traiter la trace ETL brute et créer un fichier de profil SPT :

SPTAggregate.exe /binary textCount.exe /etl textCount.etl textCount.spt

Explication des paramètres :

SPTAggregate génère un résumé qui montre le nombre d’échantillons qu’il a collectés. Ce résumé est votre première confirmation que le profilage a fonctionné.

Vérifiez le résultat de SPTAggregate par rapport au parcours que vous avez suivi :

• Chemin LBR : Recherchez un nombre d’échantillons LBR utilisés non nul.
• Chemin PMC : Recherchez un nombre d’échantillons PMC ou de pile non nul.
• Chemin du temporisateur du système d’exploitation : Recherchez un nombre d’échantillons de pile utilisés non nul.

Si tous les nombres sont nuls, consultez Résolution des problèmes avant de continuer.

Convertir le fichier SPT en SPD

Votre chemin d’accès :

• Utilisateurs LBR (utilisez /mode:LBR) : mode LBR
• Utilisateurs de PMC (utiliser /mode:IP) : Mode IP (minuteur PMC et minuteur du système d’exploitation)
• Utilisateurs du minuteur de système d’exploitation (utilisation /mode:IP) : mode IP (PMC et minuteur de système d’exploitation)

Les chemins d’accès du minuteur PMC et du système d’exploitation utilisent /mode:IP tous deux parce que les deux produisent des exemples de pointeurs d’instruction.

L’étape suivante se divise selon le chemin de profilage, en particulier en fonction de l’indicateur /mode transmis à SPDConvert.exe.

Mode LBR

SPDConvert.exe /mode:LBR textCount.spd textCount.spt

/mode:LBR indique à SPDConvert d’interpréter le SPT comme contenant des données de séquence de branche LBR.

Mode IP (PMC et temporisateur du système d’exploitation)

Le temporisateur PMC et le temporisateur du système d’exploitation produisent tous deux des échantillons du pointeur d’instruction ; ils utilisent donc tous deux la même commande de conversion :

SPDConvert.exe /mode:IP textCount.spd textCount.spt

/mode:IP indique à SPDConvert d’interpréter le SPT comme contenant des échantillons de pointeur d’instruction.

Après l’exécution SPDConvert, vérifiez qu’il textCount.spd a été créé (ou mis à jour) dans le répertoire actif.

Interprétation de la sortie SPDConvert

La commande SPDConvert textCount.spd textCount.spt affiche un résumé de la couverture des blocs avant et après, par exemple :

Block coverage (before) : 33.90% ( 4507/ 13294)
Block coverage (after)  : 45.64% ( 6067/ 13294)

Ce résumé montre le pourcentage des blocs de code du binaire qui ont des données de profil associées. Un pourcentage plus élevé est meilleur. La couverture supérieure à 70% est excellente, tandis que la couverture inférieure à 40% peut limiter l’efficacité de l’optimisation. Si la couverture est faible, exécutez la charge de travail de profilage plus longue ou combinez plusieurs fichiers SPT à partir d’exécutions distinctes avec différentes charges de travail. Par exemple, vous pouvez exécuter textCount sur plusieurs fichiers texte pour exercer différents chemins de code.

Il se peut qu’un avertissement de SPDConvert s’affiche, comme celui-ci :

Compiler may be conservative on some hot functions due to sparse sample coverage.
SPGO is estimated to optimize better if sample density is increased to 5.4x of current level.
Sample density can be increased by sampling for longer period, or increasing sample rate.

Cet avertissement signifie que votre exécution de profilage n’a pas collecté suffisamment d’échantillons pour que l’optimiseur optimise en toute confiance toutes les fonctions chaudes. Le SPD est toujours utilisable, mais vous pouvez améliorer les résultats en :

• Exécution de la charge de travail plus longue (par exemple, 5 minutes ou plus au lieu de 1 minute) ou utilisation de différentes charges de travail.
• Réduction de la -setProfInt valeur dans la xperf commande pour augmenter le taux d’échantillonnage. Le compromis est que cette modification produit un fichier ETL plus volumineux, qui prend plus de temps à traiter.
• Combinaison de plusieurs fichiers SPT à partir d’exécutions de profilage distinctes en les transmettant tous à SPDConvert.

Le fichier SPT est un format binaire. Pour inspecter son contenu, vous pouvez exécuter SPTDump.exe textCount.spt. De même, PTDump.exe textCount.spt affiche les données de profil compilées après l’exécution SPDConvert. Les deux outils sont utiles pour vérifier des échantillons non zéro avant de continuer.

Reconstruire textCount avec /spdin

Reconstruire textCount à partir du fichier SPD renseigné. L’éditeur de liens lit les données de profil et applique des optimisations SPGO.

Cette étape est la même pour les trois chemins de profilage.

cl /EHsc /GL /O2 textCount.cpp /link /debug /spgo /spdin:textCount.spd

Nouvel indicateur (comparé à Build textCount avec /spgo) :

La commande inclut toujours /spgo. Il génère un nouveau fichier SPD en même temps que le fichier binaire optimisé, que vous pouvez utiliser comme point de départ pour les itérations de profilage suivantes.

Après la recompilation avec /spdin, l’éditeur de liens génère des statistiques sur la part de votre code qui a été optimisée grâce aux données de profilage. Par exemple:

221 of 221 (100.00%) profiled functions will be compiled for speed
201 of 1383 inline instances were from dead/cold paths
474 of 474 profiled functions (100.0%) were optimized using profile data
202738780 of 202738780 instructions (100.0%) were optimized using profile data

Un pourcentage élevé signifie que le SPD couvre bien votre binaire. Si le pourcentage est faible (par exemple, inférieur à 90%), soit la charge de travail de profilage n’a pas exercé suffisamment de binaire, soit le binaire a changé de manière significative depuis la collecte du profil. Dans les deux cas, reprofilez sur le fichier binaire actuel.

Que fait SPGO avec vos données de profil

SPGO utilise les données d’échantillons collectées pour renseigner le nombre d’occurrences de chaque bloc et de chaque arête dans le graphe de flot de contrôle du programme. Ces décomptes permettent des optimisations telles que :

• Intégration en ligne guidée par profil : intègre agressivement les sites d’appel fréquents tout en évitant le gonflement du code dû à l’intégration des chemins peu fréquents.
• Séparation du code chaud/froid : déplacement du code rarement exécuté vers des sections distinctes du binaire, améliorant ainsi l’utilisation du cache d’instructions et la gestion de la pagination.
• Organisation des fonctions : placez dans le binaire, à proximité les unes des autres, les fonctions qui s’appellent fréquemment, ce qui réduit les défauts de page et améliore la localité des références. Les fonctions optimisées sont organisées en groupes COFF d’affinité élevée dans le binaire.
• Décisions de taille/vitesse : Compilez les fonctions chaudes pour les fonctions de vitesse et de froid pour la taille. Les routines sans correspondances de profil observées peuvent être compilées à des fins de taille plutôt que de vitesse, ce qui limite les optimisations telles que l’inlining et le déroulement de boucles dans ces chemins froids.
• Dévirtualisation spéculative : lorsque l’échantillonnage révèle qu’un appel indirect cible systématiquement la même fonction, SPGO peut supposer qu’il s’agit de cette cible et l’intégrer en ligne, avec un mécanisme de repli pour le cas peu fréquent.

Mesurer les résultats

Exécutez textCount à nouveau et comparez les temps d’exécution.

textCount.exe < warAndPeace.txt

Collectez plusieurs exécutions pour chaque configuration et utilisez la médiane. Une seule exécution n’est pas fiable, car la planification du système d’exploitation et le bruit du système peuvent fausser les mesures individuelles.

Dans un test, SPGO utilisant la méthode LBR a livré environ 7% réduction du temps écoulé. Vos résultats peuvent varier avec vos propres projets, car les gains SPGO dépendent de la façon dont la charge de travail de profilage représente une exécution classique. Les bases de code plus volumineuses et remplies de branches ont tendance à voir plus d’amélioration dans la plage de% 5 à 10. La méthode de profilage affecte la qualité de l’optimisation. LBR produit généralement de meilleurs résultats que PMC, ce qui produit de meilleurs résultats que le minuteur de système d’exploitation. Si vous utilisez le mode de minuterie du système d’exploitation, attendez-vous à des gains plus modestes.

Le chemin LBR suivi dans ce tutoriel a été appliqué au projet SQLite , qui est une bibliothèque de base de données de production. Le binaire SQLite optimisé pour SPGO a montré une amélioration d’environ 7%.

Appliquer SPGO à votre propre projet

Utilisez cette liste de contrôle pour appliquer SPGO à votre propre application C ou C++.

1. Ajoutez /link /spgo à votre commande de build de mise en production existante. Modifiez votre script de build ou fichier projet :

   cl /EHsc /GL /O2 myapp.cpp /link /spgo
   

2. Choisissez une charge de travail représentative. Sélectionnez un scénario d’utilisation réel qui sollicite les chemins critiques de votre application. Utilisez des données de type production. Évitez d’utiliser les éléments suivants comme charge de travail principale pour le profilage : les tests de couverture du code (ils ne sollicitent pas les goulets d’étranglement en matière de performances), les chemins d’erreur peu fréquents, les phases de démarrage et d’arrêt, et les chemins de code obsolètes. Cette charge de travail pilote le profil qui alimente l’optimiseur.

3. Exécutez xperf en utilisant le chemin d’accès détecté. Utilisez le chemin que vous avez identifié dans Choisir votre méthode de profilage (LBR, PMC ou minuteur de système d’exploitation). Démarrez xperf, exécutez la charge de travail une fois, arrêtez xperfet capturez le fichier ETL.

4. Pour le chemin du minuteur PMC ou du système d’exploitation, exécutez SPTAggregate et SPDConvert avec l’indicateur correct /mode . Convertissez ETL en SPT, puis en SPD. Utilisez /mode:LBR pour les données LBR ; utilisez /mode:IP pour les données PMC ou de temporisateur du système d’exploitation.

5. Reconstruire avec /spdin:<your-spd-path>. Compilez votre application avec le SPD rempli :

   cl /EHsc /GL /O2 yourApp.cpp /link /spgo /spdin:yourApp.spd
   

6. Mesurez avant et après. Exécutez votre charge de travail avec les binaires non optimisés et les binaires optimisés par SPGO. Collectez la médiane de plusieurs exécutions pour chaque configuration. Une seule exécution n’est pas fiable pour l’évaluation.

7. Enregistrez le .spd fichier dans la gestion de version. Vérifiez le .spd fichier dans votre système de contrôle de code source en même temps que votre code source.

8. Activez SPGO dans les builds release du développeur. Les builds Release de votre équipe utilisent les mêmes fichiers binaires optimisés pour SPGO que la production. Cela permet d’intercepter les régressions de performances au début.

9. Désactivez SPGO dans les builds Debug.

10. Regardez les statistiques de complétivité du profil de l’éditeur de liens. Après chaque build avec /spgo, notez le pourcentage de fonctions profilées optimisées à l’aide des données de profil. Si cela diminue considérablement (moins de 90%), reprofilez le fichier binaire actuel. Les modifications de code s’accumulent et le SPD peut devenir obsolète.

Alternative à l’utilisation de xperf

Une autre façon de collecter des données de profil consiste à utiliser un profileur d’échantillonnage comme Windows Enregistreur de performances (WPR). WPR est installé par défaut sur Windows 10 et versions ultérieures. Il collecte des données similaires à xperf. Vous pouvez configurer WPR pour collecter des échantillons du processeur avec leurs piles d’appels, puis exporter les données dans un fichier ETL que vous pouvez traiter avec SPTAggregate et SPDConvert comme pour l’ETL xperf. Voici un exemple d’utilisation de WPR pour collecter des données de profil :

wpr -start CPU.light -filemode
textCount.exe < warAndPeace.txt
wpr -stop spgo_data.etl

Pour plus d’informations sur l’utilisation de WPR, consultez Utilisation de l’Enregistreur de performances Windows.

Distribution de SPD

Vous pouvez :

• Vérifiez le fichier directement dans le .spd contrôle de code source en même temps que votre code source.
• Partagez le fichier .spd avec vos coéquipiers afin qu’ils puissent effectuer des builds avec les optimisations SPGO sans avoir à recréer le profilage.
• Empaqueter le .spd fichier avec vos fichiers binaires en tant qu’artefact avec version (par exemple, un package NuGet) et enregistrer la version correspondant à quel binaire.
• Régénérez le .spd fichier à tout moment en répétant le flux de travail de profilage.

Le SPD est lié au binaire exact à partir duquel il a été compilé. Après des modifications significatives du code, reprofilez pour générer un nouveau SPD. Pendant la /spdin build, le compilateur produit également un nouveau .spd fichier. Enregistrez ce nouveau SPD en tant qu’artefact de build. Il s’agit du point de départ de votre prochaine itération de profilage.

Réutilisation des informations SPD entre les builds

Le concept de « report » dans SPGO vous permet d’ajouter des données de profilage à un fichier SPD existant sans profiler à nouveau tous vos scénarios à partir de zéro et sans perdre les informations de profil existantes. Vous pouvez également ajuster le poids à donner aux données de profil plus anciennes. Cette flexibilité est utile lorsqu’il peut y avoir des modifications comportementales au fil du temps et que vous ne souhaitez pas perdre complètement les informations de profilage des exécutions de scénarios précédents. Par exemple, une DLL peut être confrontée à l’appel de différentes API à mesure que l’application qui l’appelle évolue. Vous voulez toujours bénéficier des optimisations liées à son comportement antérieur, tout en intégrant des possibilités d’optimisation pour les cas où il se comporte désormais parfois différemment. Vous pouvez faire évoluer le profil au fil du temps en mélangeant les données anciennes et nouvelles.

Lorsque vous exécutez SPDConvert avec un nouveau fichier SPT, passez le nom du fichier SPD existant. Utilisez ensuite l’option /retire:N pour contrôler dans quelle mesure SPDConvert atténue les anciennes données de profil lorsque vous ajoutez de nouveaux fichiers SPT :

• La valeur par défaut (/retire:8) accorde davantage de poids aux données les plus récentes.
• Utilisez /retire:0 pour attribuer le même poids à toutes les exécutions.
• Utilisez /retire:16 pour que seules les données les plus récentes soient prises en compte.

Résolution des problèmes

Recherchez votre problème :

• Problèmes de chemin d’accès LBR :problèmes de chemin LBR
• Problèmes de chemin PMC :problèmes de chemin PMC
• Problèmes de minuteur du système d’exploitation :problèmes de chemin du minuteur du système d’exploitation
• Problèmes affectant tous les chemins d’accès :Problèmes généraux

Problèmes de chemin d’accès LBR

Problèmes de chemin d’accès PMC

Problèmes de chemin d’accès du minuteur du système d’exploitation

Problèmes généraux (tous les chemins d’accès)

Étapes suivantes

Après avoir terminé ce tutoriel, découvrez ces fonctionnalités pour tirer le meilleur parti de SPGO :

• Fusion de profils : Exécutez plusieurs charges de travail, accumulez des fichiers SPT à partir de chaque exécution et transmettez-les tous à SPDConvert. Un SPD mixte reflète la gamme complète de modèles d’utilisation réels et produit de meilleures optimisations qu’un profil à scénario unique. Utilisez l’option /retire:N pour contrôler dans quelle mesure SPDConvert atténue les anciennes données de profil lorsque vous ajoutez de nouveaux fichiers SPT. La valeur par défaut (/retire:8) accorde plus de poids aux données les plus récentes. Utilisez /retire:0 pour donner un poids égal à toutes les exécutions ; utilisez /retire:16 pour que seules les données les plus récentes soient prises en compte.
• Les meilleurs résultats proviennent de la fusion de profils à partir de plusieurs sources, telles que des benchmarks qui stressent les scénarios clés ainsi que des données réelles (le cas échéant). Passez des fichiers SPT de toutes les sources à SPDConvert. Répétez un fichier SPT dans la liste d’arguments pour lui accorder plus de poids (par exemple, SPDConvert myapp.spd critical.spt critical.spt common.spt accorde à critical.spt un poids deux fois plus important qu’à common.spt).
• Optimisation itérative : Chaque reconstruction avec /spdin produit un nouveau SPD. Vous pouvez répéter le cycle exécution, profilage et reconstruction. Les itérations ultérieures peuvent offrir un rendement décroissant, mais un second passage peut parfois repérer des schémas que le premier n’a pas détectés.
• Modifications du code : Après des modifications importantes de la source, récoltez les données de profil. Le SPD existant est lié au binaire par rapport auquel il a été profilé. Il ne correspondra pas à un binaire largement reconstruit.
• Actualisation du profil : L’éditeur de liens signale le pourcentage de fonctions profilées optimisées à l’aide de données de profil après chaque /spdin build. Si ce pourcentage diminue considérablement, c’est le signe que le code s’est écarté du profil. Reprofilez le binaire actuel.