J'ai besoin d'améliorer le débit du système.
Le cycle d'optimisation habituel a été effectué et nous avons déjà atteint un meilleur débit supérieur de 1,5 fois.
Je commence maintenant à me demander si je peux utiliser la sortie Cachegrind pour améliorer le débit du système.
Quelqu'un peut-il me dire comment commencer sur ceci?
Ce que je comprends, c'est que nous devons nous assurer que les données les plus fréquemment utilisées doivent rester suffisamment petites de manière à ce qu'elle reste dans le cache L1 et que le prochain ensemble de données doit s'intégrer dans le L2.
Est-ce la bonne direction que je prends?
4 Réponses :
Selon La documentation de cachegrind Les détails que vous avez indiqué par Cachegrind sont le nombre de cache misses pour une partie donnée de votre code. Vous devez savoir comment les caches fonctionnent sur l'architecture que vous ciblez afin de savoir comment corriger le code. En pratique, cela signifie que les données sont plus petites ou modifier le modèle d'accès de certaines données afin que les données en cache soient toujours dans le cache. Cependant, vous devez comprendre les données et l'accès aux données de votre programme avant de pouvoir agir sur les informations. Comme il le dit dans le manuel,
En bref, la cachegrind peut vous dire où sont quelques-uns des goulots d'étranglement de votre code, mais cela ne peut pas vous dire comment les réparer. Vous devez travailler cela pour vous-même. Mais au moins vous avez l'information!
Si vous rencontrez des difficultés à l'analyse de la sortie de cachegriture, regardez dans KCachegrind (il devrait être disponible dans votre distribution de choix). Je l'utilise et je le trouve utile.
C'est vrai que la production de cachegriture en soi ne donne pas trop d'informations sur la manière d'optimiser le code. Il faut savoir comment interpréter et ce que vous dites sur le raccord des données dans L1 et L2 est en effet la bonne direction.
Comprendre parfaitement comment les modèles d'accès à la mémoire influencent les performances, je vous recommande de lire un excellent papier "Que chaque programmeur Devrait savoir sur la mémoire " par Ulrich Drepper, le responsable de la GNU libc.
Merci Kaustaurya, c'était en effet un excellent article. Je me souviens d'avoir traversé cet article plus tôt, mais j'ai pu apprécier les inticagons beaucoup mieux cette fois-ci.
1.5x est une belle vitesse. Cela signifie que vous avez trouvé quelque chose qui a pris 33% du temps que vous pourriez vous débarrasser. Je parie que vous pouvez faire plus, même avant de vous remettre à des problèmes de bas niveau tels que le cache de mémoire de données. C'est un exemple de comment. Fondamentalement, vous pourriez avoir Des problèmes de performance supplémentaires (et des opportunités de vitesse) qui n'étaient pas importants avant, comme 25% disent. Eh bien, avec le speed-up 1.5x, que 25% sont maintenant de 37,5%, il s'agit de "vaut plus" plus ". Souvent, un tel problème se présente sous la forme d'un appel de la fonction de pile moyen qui demande des travaux qui, une fois que vous savez combien cela coûte, vous pouvez décider n'est pas complètement nécessaire. Depuis que Kcachegrind ne vient pas vraiment les identifier, vous ne pourrez peut-être pas réaliser que c'est un problème.
Je suis surtout d'accord. Cependant, je ne considérerais pas le cache un problème de bas niveau. Toute plate-forme que vous êtes susceptible d'être ciblé aura une cache (même des cartes CUDA modernes). L'optimisation du cache est également susceptible de produire de grandes améliorations et peut être effectuée sans regarder la sortie de l'assemblage du compilateur.
@ Jørgenfogh: Droite. Les développeurs de processeurs ont tout positif dans leur domaine pour optimiser le temps de traitement. Nous, les développeurs de logiciels ne sont pas toujours réciproques en veillant à ce que notre code soit «maigre et méchant». Je le vois tout le temps.
C'est définitivement vrai. Mon point est qu'il n'ya aucun moyen qu'un bon processeur puisse compenser un algorithme inefficace. Cela inclut des algorithmes avec des performances de cache médiocres. L'efficacité du cache ne peut être ajoutée comme une réflexion après coup.