Oui, par défaut ce sont les cycles CPU, mais dans l'article je n'ai pas vu de précision sur ce qui est fait avec perf (et c'est un outil qui peut faire beaucoup d'autres choses).
Justement, ma question est de savoir précisément ce qui est mesuré avec perf. Dans la commande "time" on a droit à 3 mesures:
Le temps "user": temps passé à exécuter du code utilisateur
Le temps "system": temps passé à exécuter du code du noyau (appels système)
Le temps "real": temps total de l'exécution
On peut soustraire les deux premiers au troisième pour avoir le temps passé à ne pas exécuter de code du processus concerné (autres tâches en cours d'exécution, attente sur les entrées-sorties, etc).
Avec le compteur "cycles" de perf, on mesure au mieux les deux premiers, mais pas le troisième. Et donc le temps passé à ne pas exécuter de code n'est pas identifié. Je n'ai pas trouvé dans l'article ni dans le dépôt git du benchmark si tu as regardé la commande "time" pour voir si le code passe surtout du temps à s'exécuter ou surtout du temps à attendre les entrées-sorties. Ça peut être pas mal de vérifier ça pour s'assurer qu'on optimise au bon endroit. Si le programme est limité par les entrées-sorties, les gains en utilisation CPU ne seront pas visibles sur le throughput ou le temps d'exécution total pour un test donné (mais ils seront visibles sur la charge CPU et la consommation électrique).
Pour mesurer le temps passé ailleurs que dans le code avec perf: par exemple, en utilisant les évènements "syscalls:sys_enter_" on peut profiler tous les endroits qui font des appels systèmes (ce qui est en général assez coûteux, ça se place quelque part entre un appel de fonction et un switch de contexte pour exécuter un autre processus). Les évènements "block:" peuvent aussi être utiles pour regarder les entrées-sorties sur disque. On s'éloigne vite du C++ pour entrer dans les détails de la programmation système UNIX, mais ça peut être intéressant.
[^] # Re: Mesures avec perf
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Effortless Performance Improvements in C++: std::unordered_map. Évalué à 4.
Oui, par défaut ce sont les cycles CPU, mais dans l'article je n'ai pas vu de précision sur ce qui est fait avec perf (et c'est un outil qui peut faire beaucoup d'autres choses).
Justement, ma question est de savoir précisément ce qui est mesuré avec perf. Dans la commande "time" on a droit à 3 mesures:
On peut soustraire les deux premiers au troisième pour avoir le temps passé à ne pas exécuter de code du processus concerné (autres tâches en cours d'exécution, attente sur les entrées-sorties, etc).
Avec le compteur "cycles" de perf, on mesure au mieux les deux premiers, mais pas le troisième. Et donc le temps passé à ne pas exécuter de code n'est pas identifié. Je n'ai pas trouvé dans l'article ni dans le dépôt git du benchmark si tu as regardé la commande "time" pour voir si le code passe surtout du temps à s'exécuter ou surtout du temps à attendre les entrées-sorties. Ça peut être pas mal de vérifier ça pour s'assurer qu'on optimise au bon endroit. Si le programme est limité par les entrées-sorties, les gains en utilisation CPU ne seront pas visibles sur le throughput ou le temps d'exécution total pour un test donné (mais ils seront visibles sur la charge CPU et la consommation électrique).
Pour mesurer le temps passé ailleurs que dans le code avec perf: par exemple, en utilisant les évènements "syscalls:sys_enter_" on peut profiler tous les endroits qui font des appels systèmes (ce qui est en général assez coûteux, ça se place quelque part entre un appel de fonction et un switch de contexte pour exécuter un autre processus). Les évènements "block:" peuvent aussi être utiles pour regarder les entrées-sorties sur disque. On s'éloigne vite du C++ pour entrer dans les détails de la programmation système UNIX, mais ça peut être intéressant.