Le système de compilation Android pour Android 13 et versions antérieures prend en charge l'utilisation de la fonction Profilage guidé (PGO) sur les modules Android natifs disposant d'un build blueprint des règles de pare-feu. Cette page décrit Clang PGO, comment générer et mettre à jour continuellement profils utilisés pour PGO et comment l'intégrer au système de compilation (avec cas d'utilisation).
Remarque: Ce document décrit l'utilisation de PGO sur la plate-forme Android. Pour en savoir plus sur l'utilisation PGO à partir d'une application Android, consultez cette page.
À propos de Clang PGO
Clang peut effectuer une optimisation guidée par le profil à l'aide de deux types de profils:
- Les profils basés sur l'instrumentation sont générés à partir d'un programme cible instrumenté. Ces profils sont détaillés et ont un impact à l'exécution.
- Les profils basés sur l'échantillonnage sont généralement produits par pour échantillonner les compteurs matériels. Elles imposent des frais généraux d'exécution faibles et peuvent collectées sans aucune instrumentation ou modification du binaire. Ils sont moins détaillés que les profils basés sur l'instrumentation.
Tous les profils doivent être générés à partir d'une charge de travail représentative qui
le comportement typique de l'application. Bien que Clang accepte à la fois
Basés AST (-fprofile-instr-generate
) et LLVM IR
(-fprofile-generate)
, Android n'est compatible qu'avec les charges de travail infrarouges LLVM
PGO basé sur l'instrumentation.
Les options suivantes sont nécessaires pour créer une collection de profils:
-fprofile-generate
pour l'instrumentation infrarouge Grâce à cette , le backend utilise une approche en arbre syntaxique minimal pondéré de réduire le nombre de points d'instrumentation et d'optimiser leur emplacement à faible pondération (utilisez également cette option pour l'étape de liaison). Le Clang transmet automatiquement l'environnement d'exécution de profilage (libclang_rt.profile-arch-android.a
) à l'éditeur de liens. Cette bibliothèque contient des routines pour écrire les profils sur le disque lors du programme de sortie.-gline-tables-only
pour la collecte de profils basée sur l'échantillonnage pour générer un minimum d'informations de débogage.
Un profil peut être utilisé pour PGO à l'aide de
-fprofile-use=pathname
ou
-fprofile-sample-use=pathname
pour un modèle basé sur l'instrumentation
et les profils basés sur l'échantillonnage.
Remarque:Au fur et à mesure que des modifications sont apportées au code, si Clang ne peut
à utiliser plus longtemps les données de profil générées
Avertissement : -Wprofile-instr-out-of-date
.
Utiliser PGO
L'utilisation de PGO implique les étapes suivantes:
- Créez la bibliothèque/l'exécutable avec l'instrumentation en transmettant
-fprofile-generate
au compilateur et à l'éditeur de liens. - Collectez des profils en exécutant une charge de travail représentative sur le binaire instrumenté.
- Post-traiter les profils à l'aide de l'utilitaire
llvm-profdata
Pour en savoir plus, consultez Gérer LLVM fichiers de profil). - Utilisez les profils pour appliquer PGO en transmettant
-fprofile-use=<>.profdata
au compilateur éditeur de liens.
Pour PGO dans Android, les profils doivent être collectés hors connexion et enregistrés parallèlement au code pour garantir des compilations reproductibles. Les profils peuvent être utilisés comme le code évolue, mais il doit être régénéré périodiquement (ou dès que Clang avertit que les profils sont obsolètes).
Collecter des profils
Clang peut utiliser les profils collectés en exécutant des analyses comparatives à l'aide d'un version instrumentée de la bibliothèque ou échantillonner les compteurs matériels lorsque l'exécution du benchmark. Pour le moment, Android ne permet pas d'utiliser des données collection de profils. Vous devez donc collecter des profils à l'aide d'un modèle instrumenté build:
- Identifier un benchmark et l'ensemble de bibliothèques collectivement exercés par ce benchmark.
- Ajoutez des propriétés
pgo
au benchmark et aux bibliothèques (détails). ci-dessous). - Produire un build Android avec une copie instrumentée de ces bibliothèques
avec:
make ANDROID_PGO_INSTRUMENT=benchmark
benchmark
est un espace réservé qui identifie le
Collection de bibliothèques instrumentées lors de la compilation. Le représentant
(et éventuellement un autre exécutable qui renvoie vers une bibliothèque
ne sont pas spécifiques à PGO et dépassent le cadre de cette
document.
- Flashez ou synchronisez le build instrumenté sur un appareil.
- Exécutez le benchmark pour collecter des profils.
- Utilisez l'outil
llvm-profdata
(décrit ci-dessous) pour post-traiter les profils et les préparer pour qu'ils puissent être vérifiés dans la source arborescence.
Utiliser des profils pendant la compilation
Vérifiez les profils dans toolchain/pgo-profiles
dans un Android
arborescence. Le nom doit correspondre à celui spécifié dans
Sous-propriété profile_file
de la propriété pgo
pour
la bibliothèque. Le système de compilation transmet automatiquement le fichier de profil à Clang
lors de la création de la bibliothèque. ANDROID_PGO_DISABLE_PROFILE_USE
peut être définie sur true
pour
désactiver temporairement PGO et mesurer ses avantages en termes de performances.
Pour spécifier des répertoires de profils supplémentaires spécifiques aux produits, ajoutez-les à
la variable make PGO_ADDITIONAL_PROFILE_DIRECTORIES
dans une
BoardConfig.mk
Si des chemins d'accès supplémentaires sont spécifiés, les profils
ces chemins d'accès remplacent ceux de toolchain/pgo-profiles
.
Lors de la génération d'une image de version à l'aide de la cible dist
pour
make
, le système de compilation écrit les noms des fichiers de profil manquants ;
à $DIST_DIR/pgo_profile_file_missing.txt
. Vous pouvez vérifier cela
pour voir quels fichiers de profil ont été accidentellement supprimés (qui ont été
désactive PGO).
Activer PGO dans les fichiers Android.bp
Pour activer PGO dans les fichiers Android.bp
des modules natifs, il vous suffit
spécifiez la propriété pgo
. Cette propriété présente les caractéristiques suivantes :
sous-propriétés:
Propriété | Description |
---|---|
instrumentation
|
Définissez ce paramètre sur true pour PGO à l'aide de l'instrumentation. La valeur par défaut est
false |
sampling
|
Définissez la valeur sur true pour PGO à l'aide de l'échantillonnage. La valeur par défaut est
false |
benchmarks
|
Liste de chaînes. Ce module est conçu pour le profilage
de la liste est spécifiée dans le build ANDROID_PGO_INSTRUMENT
. |
profile_file
|
Fichier de profil (relatif à toolchain/pgo-profile ) à utiliser
avec PGO. La compilation vous avertit que ce fichier n'existe pas en ajoutant cette
fichier dans $DIST_DIR/pgo_profile_file_missing.txt
sauf si la propriété enable_profile_use est définie sur
false OU le
La variable de compilation ANDROID_PGO_NO_PROFILE_USE est définie sur
true |
enable_profile_use
|
Défini sur false si les profils ne doivent pas être utilisés pendant
créer. Peut être utilisé pendant l'amorçage pour activer la collecte de profils ou pour
désactiver temporairement PGO. La valeur par défaut est true . |
cflags
|
Liste des options supplémentaires à utiliser lors d'un build instrumenté. |
Exemple de module avec PGO:
cc_library { name: "libexample", srcs: [ "src1.cpp", "src2.cpp", ], static: [ "libstatic1", "libstatic2", ], shared: [ "libshared1", ] pgo: { instrumentation: true, benchmarks: [ "benchmark1", "benchmark2", ], profile_file: "example.profdata", } }
Si les benchmarks benchmark1
et benchmark2
pour tester le comportement représentatif des bibliothèques libstatic1
,
libstatic2
, ou libshared1
, le pgo
de ces bibliothèques peut également inclure les benchmarks. La
Le module defaults
de Android.bp
peut inclure un élément
pgo
pour un ensemble de bibliothèques afin d'éviter de répéter la
les mêmes règles de compilation
pour plusieurs modules.
Pour sélectionner différents fichiers de profil ou désactiver de manière sélective PGO pour une
de l'architecture, spécifiez profile_file
,
enable_profile_use
et cflags
propriétés par
de l'architecture. Exemple (avec une cible d'architecture dans
gras):
cc_library { name: "libexample", srcs: [ "src1.cpp", "src2.cpp", ], static: [ "libstatic1", "libstatic2", ], shared: [ "libshared1", ], pgo: { instrumentation: true, benchmarks: [ "benchmark1", "benchmark2", ], } target: { android_arm: { pgo: { profile_file: "example_arm.profdata", } }, android_arm64: { pgo: { profile_file: "example_arm64.profdata", } } } }
Pour résoudre les références à la bibliothèque d'exécution de profilage pendant
profilage basé sur l'instrumentation, transmettez l'option de compilation
-fprofile-generate
à l'éditeur de liens. Bibliothèques statiques instrumentées
avec PGO, toutes les bibliothèques partagées et tout binaire qui dépend directement
La bibliothèque statique doit également être instrumentée pour PGO. Cependant, ces partages
les bibliothèques ou les exécutables n'ont pas besoin d'utiliser de profils PGO, et leurs
La propriété enable_profile_use
peut être définie sur false
.
En dehors de cette restriction, vous pouvez appliquer PGO à n'importe quelle bibliothèque statique, partagée
bibliothèque ou exécutable.
Gérer les fichiers de profil LLVM
L'exécution d'une bibliothèque instrumentée ou d'un exécutable génère un fichier de profil
nommé default_unique_id_0.profraw
dans
/data/local/tmp
(où unique_id
est un
hachage numérique propre à cette bibliothèque). Si ce fichier existe déjà,
l'environnement d'exécution de profilage fusionne le nouveau profil avec l'ancien lors de l'écriture
les profils. Notez que l'application n'a pas accès à /data/local/tmp
développeurs ; ils doivent utiliser
quelque chose comme
/storage/emulated/0/Android/data/packagename/files
.
Pour modifier l'emplacement du fichier de profil, définissez le LLVM_PROFILE_FILE
variable d'environnement lors de l'exécution.
llvm-profdata
est ensuite utilisé pour convertir le fichier .profraw
(et éventuellement
fusionner plusieurs fichiers .profraw
) dans une .profdata
:
llvm-profdata merge -output=profile.profdata <.profraw and/or .profdata files>
profile.profdata
peut ensuite être enregistré dans la source
à utiliser pendant la compilation.
Si plusieurs binaires/bibliothèques instrumentés sont chargés lors d'une analyse comparative,
chaque bibliothèque génère un fichier .profraw
distinct avec un fichier
un identifiant unique. En général, tous ces fichiers
peuvent être fusionnés en un seul
.profdata
et utilisé pour la compilation PGO. Dans les cas où une bibliothèque
est exercé par un autre benchmark, cette bibliothèque doit être optimisée à l'aide de
des deux benchmarks. Dans ce cas, le show
l'option llvm-profdata
est utile:
llvm-profdata merge -output=default_unique_id.profdata default_unique_id_0.profraw llvm-profdata show -all-functions default_unique_id.profdata
Pour mapper des identifiants unique_id avec des bibliothèques individuelles, recherchez la
une sortie show
pour chaque unique_id pour un nom de fonction qui
est propre à la bibliothèque.
Étude de cas: PGO pour ART
L'étude de cas présente l'ART comme un exemple auquel on peut s'identifier. en revanche, il n'est pas une description précise de l'ensemble réel de bibliothèques profilées pour ART ou leurs interdépendances.
Le compilateur d'avance dex2oat
dans ART dépend de :
libart-compiler.so
, qui à son tour dépend de
libart.so
L'environnement d'exécution ART est principalement implémenté
libart.so
Les benchmarks pour le compilateur
et l'environnement d'exécution seront
différent:
Benchmark | Bibliothèques profilées |
---|---|
dex2oat
|
dex2oat (exécutable), libart-compiler.so ,
libart.so |
art_runtime
|
libart.so
|
- Ajoutez la propriété
pgo
suivante àdex2oat
.libart-compiler.so
:pgo: { instrumentation: true, benchmarks: ["dex2oat",], profile_file: "dex2oat.profdata", }
- Ajoutez la propriété
pgo
suivante àlibart.so
:pgo: { instrumentation: true, benchmarks: ["art_runtime", "dex2oat",], profile_file: "libart.profdata", }
- Créer des builds instrumentés pour
dex2oat
et Benchmarksart_runtime
utilisant:make ANDROID_PGO_INSTRUMENT=dex2oat make ANDROID_PGO_INSTRUMENT=art_runtime
- Exécutez les analyses comparatives utilisant
dex2oat
etart_runtime
pour obtenir: <ph type="x-smartling-placeholder">- </ph>
- Trois fichiers
.profraw
dedex2oat
(dex2oat_exe.profdata
,dex2oat_libart-compiler.profdata
etdexeoat_libart.profdata
), identifié à l'aide de la méthode décrit dans la section Gérer un profil LLVM de destination. - Un seul élément
art_runtime_libart.profdata
.
- Trois fichiers
- générer un fichier profdata commun pour l'exécutable
dex2oat
;libart-compiler.so
utilisant:llvm-profdata merge -output=dex2oat.profdata \ dex2oat_exe.profdata dex2oat_libart-compiler.profdata
- Obtenir le profil de
libart.so
en fusionnant les profils selon les deux benchmarks:llvm-profdata merge -output=libart.profdata \ dex2oat_libart.profdata art_runtime_libart.profdata
Les décomptes bruts pour
libart.so
des deux profils peuvent être de disparates, car les benchmarks diffèrent par le nombre de scénarios de test et et la durée de leur exécution. Dans ce cas, vous pouvez utiliser une fusion pondérée:llvm-profdata merge -output=libart.profdata \ -weighted-input=2,dex2oat_libart.profdata \ -weighted-input=1,art_runtime_libart.profdata
La commande ci-dessus attribue deux fois la pondération au profil,
dex2oat
Le poids réel doit être déterminé en fonction du domaine les connaissances ou l'expérimentation. - Vérifiez les fichiers de profil
dex2oat.profdata
etlibart.profdata
entoolchain/pgo-profiles
pour à utiliser pendant la compilation.
Vous pouvez également créer un seul build instrumenté avec toutes les bibliothèques. instrumenté avec:
make ANDROID_PGO_INSTRUMENT=dex2oat,art_runtime (or) make ANDROID_PGO_INSTRUMENT=ALL
La deuxième commande tous les modules compatibles avec PGO et le profilage.