121 lines
7 KiB
Markdown
121 lines
7 KiB
Markdown
# Profil de performance de la machine cible
|
||
|
||
Ce document décrit une politique de performance mesurée. Il ne modifie aucun
|
||
contrat de correction du Matcher, du Match Store ou du Match Result.
|
||
|
||
## Cible principale actuelle
|
||
|
||
- AMD Ryzen 7 8845HS, Zen 4, 8 cœurs et 16 threads SMT ;
|
||
- Radeon 780M à mémoire système partagée ;
|
||
- 16 Gio de RAM et zram d'environ 6 Gio ;
|
||
- Arch Linux, Clang 22, OpenCV 5.0.0.
|
||
|
||
Le build OpenCV observé emploie TBB 2023.1, expose 16 threads par défaut et les
|
||
chemins SIMD jusqu'à AVX512-SKX. Il a été compilé avec OpenCL, mais
|
||
`cv::ocl::haveOpenCL()` retourne faux. Vulkan énumère en revanche
|
||
`AMD Radeon 780M Graphics (RADV PHOENIX)`, API 1.4.354, avec une file compute
|
||
dédiée et de la mémoire UMA host-visible/cohérente.
|
||
|
||
Le runtime actuel de Lardon3D possède un worker. Le profil interactif conserve
|
||
12 threads OpenCV process-wide, quatre threads logiques pour le desktop et un
|
||
seul Matcher actif. Lorsque
|
||
les pools multi-workers seront introduits, la cible de départ recommandée est
|
||
deux Matchers avec huit threads OpenCV chacun pour une charge mixte. Les mesures
|
||
montrent toutefois que quatre Matchers à quatre threads favorisent SIFT et les
|
||
cas 4096, tandis que deux à huit favorisent ORB 8192. Le Governor devra donc
|
||
choisir à partir de la classe de charge, pas d'une constante universelle. Le
|
||
nombre de threads OpenCV devra être réglé une fois au démarrage :
|
||
`cv::setNumThreads()` est une configuration globale et ne doit jamais être
|
||
modifiée concurremment par des workers.
|
||
|
||
Quatre Matchers avec un ou deux threads chacun dégradent fortement les grands
|
||
cas ORB. Quatre fois quatre threads augmente le working set et la variance, mais
|
||
peut améliorer SIFT soutenu. Le Governor devra compter les threads OpenCV dans
|
||
le budget CPU afin d'éviter `workers × threads` supérieur aux 16 threads
|
||
matériels.
|
||
|
||
Le working set directement contrôlé d'un Matcher SIFT/RootSIFT reste inférieur
|
||
à environ 10 Mio, hors scratch TBB/OpenCV. Même plusieurs Matchers restent loin
|
||
de la pression mémoire sur 16 Gio ; les mesures n'ont produit aucun swap-in ni
|
||
swap-out. La limite pratique observée est le CPU, pas la RAM.
|
||
|
||
## Fallback portable
|
||
|
||
Le build portable conserve les réglages Meson génériques et ne force ni
|
||
`-march=native`, ni OpenCL, ni un nombre de threads spécifique au 8845HS. Sur une
|
||
autre machine, laisser OpenCV choisir son backend et limiter l'orchestration à
|
||
un Matcher reste le fallback sûr. Une future configuration multi-worker devra
|
||
être dérivée du profil matériel par le Resource Governor, sans second scheduler.
|
||
|
||
## Méthode et portée
|
||
|
||
`benchmark-matcher` utilise des Feature Sets synthétiques persistés, un warm-up
|
||
et sept répétitions dont il rapporte la médiane. Les mesures absolues sont
|
||
locales et sensibles au boost et à la température ; la décision repose surtout
|
||
sur le scaling et le débit soutenu. La campagne a été exécutée avec le governor
|
||
Linux `powersave`; après charge soutenue, 61–72 °C ont été observés et aucun
|
||
swap-in/swap-out. Le coût dominant reste l'évaluation exacte des distances dans
|
||
`cv::BFMatcher::knnMatch`.
|
||
|
||
Le backend Vulkan ORB de production est borné, utilise une invocation par query
|
||
et ne matérialise aucune matrice A×B. Sur la 780M, le workgroup 32 est le meilleur
|
||
des quatre candidats 32/64/128/256 à 4096 et 8192. Le chemin complet warm mesure
|
||
environ 0,18 ms à 256, 0,45 ms à 1024, 1,6 ms à 4096 et 4,0 ms à 8192, contre
|
||
environ 0,10, 0,96, 14,7 et 59,6 ms pour BFMatcher CPU lors de la campagne
|
||
production. L'initialisation lazy mesurée vaut environ 129–136 ms. Le seuil
|
||
`feature_count_a × feature_count_b >= 768²` évite le GPU pour les petits travaux.
|
||
|
||
La mémoire permanente directement contrôlée vaut 640 Kio de payload. Les tests
|
||
de parité couvrent exactement le top-2 jusqu'à 8192, le Match File complet et le
|
||
fallback CPU. Ces nombres décrivent la machine mesurée et ne sont pas un contrat
|
||
portable de latence.
|
||
|
||
## Geometric Verifier Fundamental — Gate A
|
||
|
||
Le 9 août 2026, `benchmark-geometric-verifier` a comparé FM_RANSAC, USAC_DEFAULT, USAC_MAGSAC,
|
||
USAC_ACCURATE et MAGSAC à seed locale sur le Ryzen 7 8845HS, OpenCV 5.0.0 et Clang 22.1.8. Sur
|
||
8192 correspondances, 70 % d'outliers et bruit 0,75 px, le candidat local mesure
|
||
10,80/11,04/11,35 ms médiane/p95/pire. FM_RANSAC mesure 316,44/318,87/319,66 ms avec seulement
|
||
0,413 de recall.
|
||
|
||
Avant campagne, PSI CPU/mémoire/I/O avg10 était nul, `MemAvailable` environ 9,72 Gio et
|
||
`pswpin/pswpout` nul. Après 30,4 s à environ 99 % d'un CPU, PSI et swap restaient nuls,
|
||
`MemAvailable` environ 9,74 Gio et le capteur CPU observé passait d'environ 54,6 à 55 °C. Ce sont
|
||
des proxies objectifs, pas une mesure subjective de fluidité.
|
||
|
||
Le coût court et le faible working set rendent Vulkan `NOT_JUSTIFIED` pour ce verifier sur la
|
||
Radeon 780M. Le GPU reste utilisé uniquement par le Matcher ORB existant.
|
||
|
||
Le profil production réserve un CPU logique, 4 Mio et un worker, avec lots 1/2/4/8. Un run de la
|
||
vraie Task sur 1000 parents, suivi de ses chemins de reprise/configuration, a traversé environ
|
||
2001 parents réutilisés en 5,870 s (environ 341/s). Ce chiffre inclut DB, checkpoints et fixture ;
|
||
il ne remplace pas la latence estimator-only Gate A. Le processus de test a culminé à 25 964 Kio
|
||
RSS. `MemAvailable` a varié de 10 702 988 à 10 692 916 Kio, sans swap ; PSI avg10 final était
|
||
0,34 % CPU et 0 % mémoire/I/O. Les latences médiane/p95 par parent et le RSS début/fin n'étaient
|
||
pas mesurables avec ce harness et ne sont donc pas extrapolés.
|
||
|
||
## Feasibility Vulkan SIFT / RootSIFT
|
||
|
||
Sur le même RADV PHOENIX, `shaderFloat64`, les timestamps compute, un subgroup
|
||
de 64 lanes et les workgroups jusqu'à 1024 invocations sont disponibles. La
|
||
meilleure variante SIFT FP32 utilise 64 lanes. Après fermeture d'une lecture
|
||
vidéo et retour à un PSI avg10 nul, cinq campagnes donnent à 8192² : SIFT
|
||
115,030 ms CPU contre 75,243 ms total potentiel (1,53×), et RootSIFT
|
||
117,484 ms contre 74,744 ms (1,57×). À 4096², les gains totaux tombent à 1,14×
|
||
et 1,11×. Les quatre paires asymétriques testées perdent face au CPU. FP64
|
||
atteint environ 271 ms à 8192².
|
||
|
||
La campagne numérique trouve une divergence top-2 sur des sommes égales
|
||
adversariales pour FP32 comme FP64, des distances et Match Files différents,
|
||
mais aucune divergence Lowe sur le corpus testé. Le backend devrait donc porter
|
||
une identité scientifique propre et ne pourrait pas employer le fallback CPU
|
||
transparent d'ORB. Cette complexité n'est pas justifiée par le profil de
|
||
performance : SIFT et RootSIFT Vulkan sont rejetés pour Lardon3D v1 sur cette
|
||
cible, OpenCV reste la référence production.
|
||
|
||
Un run soutenu de 5000 dispatchs mixtes 1024/4096/8192/4096 a traité environ
|
||
1232 paires/s en 4,06 s. Le processus de benchmark complet a culminé à environ
|
||
202 Mio RSS ; les compteurs `pswpin` et `pswpout` sont restés à zéro. Après le
|
||
run, PSI CPU `some avg10` valait 0,14 %, PSI mémoire et I/O 0 %, avec 76 °C CPU
|
||
et 64 °C au bord GPU. Ces mesures sont des observations ponctuelles, pas des
|
||
seuils du Resource Governor.
|