Forum Programmation.c Utilisation de Oprofile.

Posté par  (site web personnel) .
Étiquettes : aucune
0
14
août
2004
Bonjour,

Après un peu de boulot sur xvid, j'ai réussi a rendre le décodeur environ 25% plus rapide... ces optims ont été le fruit de la règle maîtresse en la matière:
Avant d'optimiser une fonction, il faut s'abstenir de l'appeler.

En effet, le décodeur étant un peu laissé à l'abandon, aucun dev n'avait fait l'effort de vérifier qu'on ne faisait que le strict minimum (ie: pas de répétition inutile d'une étape de décodage)... et pire, dû à quelques changements hâtifs coté codeur, on avait des fois des fonctions optimisées en assembleur qui n'étaient pas exploitées coté décodeur.

Mais bon voilà, je pense en avoir fini avec ça, et je pense que maintenant, il est temps de se jeter dans du profilage bien ficelé et efficace. Pour cela j'utilise Oprofile qui me permet d'avoir des flats profiles et l'annotation des sources avec une granularité que gprof ne peut avoir (1. car oprofile profile au niveau de l'instruction et 2. gprof est incapable de profiler du code asm écrit à la main, il lui manque les entetes mouchardes qui updatent les compteurs des fonctions).

La question:
Seulement voila, c'est un peu pauvre coté présentation des résultats, alors je me demandais si quelqu'un avait une liste de scripts annexes pour mieux exploiter un fichier du genre:
http://ed.gomez.free.fr/vrac/decoder.oprofile.c(...)
http://ed.gomez.free.fr/vrac/encoder.oprofile.c(...)

PS: le site d'Oprofile ne pointe sur pas grand chose, prospect de HP ne donne pas bcp plus d'infos que opreport+opannotate, et Google reste bien vague sur la question.

Merci

  • # Aussi...

    Posté par  (site web personnel) . Évalué à 2.

    Si y a un bon codeur/optimiseur de code parmi vous, prêt à donner un peu de son temps, je suis preneur d'une bonne analyse aussi ;-)

    Les outils c'est bien, mais rien ne vaut la synthèse faite par l'humain.

    • [^] # Re: Aussi...

      Posté par  (site web personnel) . Évalué à 1.

      ben comme tu le voix l'idct prend 12% du temps de calcul (ou alors je lis mal)

      J'avais vu celle de ffmpeg. Il me semble qu'il y a beaucoup de référence mémoire. Souvent pour des petites tables, cela peut aller plus vite de les inliner dans le code.

      "La première sécurité est la liberté"

      • [^] # Re: Aussi...

        Posté par  (site web personnel) . Évalué à 1.

        Sur mmx standard on utilise la version de ffmpeg qui a été optimisée par Michael Niedermayer (basée sur celle de Lespinass, comme presque toutes les idct open source dispos :-), mais sur AMD, on utilise une version schédulée à la main pour les pipelines des Athlon/Duron plus rapide :-)

        Nan de toute facon tout ce qui est optimisé à la main (ie: postfixé par mmx/3dne/xmm/sse2) est déjà très optimisé, je pense plutôt que la où pêche XviD serait une utilisation abusive du bus mémoire... le problème c'est que pour économiser le bus mémoire, ca équivaut à voir quelles étapes peuvent être fusionnées pour éviter des résultats intermédiaires. Or je me disais qu'il y avait peut être quelques % à gratter sur la forme du C avant de s'attaquer au fond (qui demandera plus de travail, puisque certaines étapes seront fusionnées et demanderont la création de nouevlles séries de fonctions).

        • [^] # Re: Aussi...

          Posté par  (site web personnel) . Évalué à 2.

          Dans ce cas, je te recommande la lecture de mon vieille article sur le sujet :)

          http://f-cpu.seul.org/nico/article_hack_C.html(...)

          C'est assez complexe de trouver l'utilisation optimale du bus mémoire sachant comment fonctionne les caches et les write buffer.

          Le prefetch est censé amélioré ça mais la distance optimal est variable avec le cpu. Je suis plutôt pour le "preload". Charger le plus tôt possible les données dans le flots surtout si l'acces est "aléatoire".

          "La première sécurité est la liberté"

        • [^] # Re: Aussi...

          Posté par  (site web personnel) . Évalué à 2.

          Une des règles que j'ai oublié aussi :
          - Un 1er acces à la mémoire prends en gros 150 cycles.

          Donc tout 1er acces aléatoire qui peut être remplacé par une centaine d'instruction sera plus rapide.

          "La première sécurité est la liberté"

  • # pas oprofile, mais d'autres...

    Posté par  (site web personnel) . Évalué à 2.

    tu a essaye le cache simulation de valgrind aussi ?
    (MMX seulement)

    Ou encore celui-la qui est cense supporter le 3DNow!/MMX/SSE/SSE2 :
    http://www.elis.rug.ac.be/~ronsse/diota/(...)

    sinon une lecture des plus interressantes :

    OPTIMISING FOR MODERN PROCESSORS de Alan Cox :

    http://josu.uninet.edu/n1/acox.html(...)

    (merci pour oprofile je connaissais pas !)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.