Pourquoi le code CUDA tourne-t-il tellement plus vite dans NVIDIA Visual Profiler ?

Question

Un morceau de code qui prend bien plus d'une minute en ligne de commande a été fait en un rien de temps secondes dans NVIDIA Visual Profiler (en exécutant le même .exe). La question naturelle est donc de savoir pourquoi ? Y a-t-il un problème avec la ligne de commande, ou est-ce que Visual Profiler fait quelque chose de différent et n'exécute pas vraiment tout comme sur la ligne de commande ?

J'utilise CUBLAS, Thrust et cuRAND.

Par ailleurs, j'ai constaté très récemment un ralentissement notable du code compilé sur ma machine, même du vieux code qui s'exécutait rapidement auparavant, d'où mes soupçons.

Mise à jour :

• J'ai vérifié que le sortie calculée en ligne de commande et Visual Profiler est identique - c'est-à-dire que tout le code requis a été exécuté dans les deux cas.
• GPU-shark a indiqué que mon état de performance était inchangé à P0 quand je suis passé de la ligne de commande à Visual Profiler.
• Cependant, Utilisation du GPU a été signalé à 0.0% lorsqu'il est exécuté avec Visual Profiler mais est monté jusqu'à 98% en cas de fuite ligne de commande .
• De plus, loin Moins de mémoire est utilisée avec Visual Profiler . Lorsqu'il est exécuté en ligne de commande, le gestionnaire de tâches indique une utilisation de 650 à 700 Mo de mémoire (avec des pics au premier démarrage). cudaFree(0) appel). Dans Visual Profiler, ce chiffre descend à ~100MB.

Answer 1

Il s'agit d'une vieille question, mais je viens de finir de résoudre le même problème (même si la cause n'est peut-être pas la même).

En effet, mon application atteint entre 900 et 1100 images (lancements synchrones) par seconde lorsqu'elle fonctionne sous NVVP, mais environ 100-120 lorsqu'elle fonctionne en dehors du profileur.

La cause semble être un message d'état que j'imprimais à la console via cout . J'avais prévu que cela ne se produise qu'une fois toutes les 100-200 images environ. Au lieu de cela, le message d'état était imprimé pour chaque image, et l'entrée-sortie de la console devenait le goulot d'étranglement.

En n'imprimant le message d'état que toutes les 100 images (bien que le nombre optimal dépende de votre application), la fréquence d'images est remontée pour correspondre à ce que je voyais dans le NVVP. Bien sûr, cette opération peut également être gérée dans un thread CPU séparé si ce type de surcharge est inacceptable dans votre cas.

Le NVVP doit réorienter stdout dans son propre tampon interne afin de capturer la sortie de l'application (qu'elle affiche dans son onglet console). Il semble que le mécanisme du NVVP pour la mise en mémoire tampon ou le traitement de cette sortie soit nettement moins coûteux que de laisser le système d'exploitation la gérer directement. Il semble que le NVVP mette tout en mémoire tampon et l'affiche dans un thread séparé, ou qu'il sauvegarde simplement un tas de données de sortie jusqu'à ce qu'un certain seuil soit atteint, lorsqu'il ajoute ce tampon à son propre onglet de console.

Je vous conseille donc de désactiver les entrées-sorties de la console et de voir si cela a un impact sur les choses.

(Le fait que VS2012 ait refusé de profiler mon application CUDA n'a pas aidé. Il aurait été agréable de voir que 80 % du temps d'exécution était consacré aux entrées-sorties de la console).

J'espère que cela vous aidera !

Answer 2

Cela ne devrait pas arriver. Je n'ai jamais vu quelque chose comme ça ; probablement quelque chose dans votre configuration.

Answer 3

Il se pourrait que certains Étape de compilation JIT est ignoré par le profileur. Cela pourrait expliquer la différence d'utilisation de la mémoire. Essayez de créer un binaire gras ?