Se connecter
Se connecter

ou
Créer un compte

ou
Agrandir
Les Mains dans le Cambouis
Bidouille & Développement Informatique

Le pub des programmeurs

  • 1 927 réponses
  • 117 participants
  • 129 156 vues
  • 130 followers
Sujet de la discussion Le pub des programmeurs
Salut :coucou: y a des programeurs sur AF si oui vous bossez sous quoi ?
Afficher le sujet de la discussion
251

Citation : - dans la fonction process, est ce que tu utilises des appels systeme ?


Ca je sais que c'est pas conseillé :mrg:

Citation : - Lorsque tu utilises des sin,cos et autre fonctions transcendentales, est ce que tu utilises les fonctions standarts de la libc ?


Des log et des pow principalement, j'imagine qu'il faut éviter...

Citation : - est ce que tu utilises bien le cache de ton proc ?


Je m'en sers pas du tout, comment on fait ? :oops:

Citation : - est ce que tu calcules plusieurs fois les memes valeurs ?


L'avantage des classes c'est que j'évite ce genre de trucs :clin:

Citation : Il y a des trucs simples pour l'optimisation: par exemple, en maths, diviser par deux et multiplier par 0.5, c'est pareil. Sur un pentium, en flottant, diviser est facilement 5 a 10 fois plus couteux qu'une multiplication. Si tu as besoin de cos et sin regulierments espaces, tu peux utiliser des tables et des formules de recurrence, etc... Aussi, il faut bien connaitre le compilo, et toutes les options d'optimisation. Ca peut changer beaucoup de choses.


La faut que je me renseigne...

Citation : La méthode ultime pour savoir ce qui te bouffe du CPU : le profiling


Connais pas du tout, je vais faire du google :mrg:

Merci des infos !

Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape | Soundcloud

252
Pour le profiling, essaie LTProf par exemple, ça va te dire dans quelles fonctions le programme passe le plus de temps.

Si tu utilises des log, sqrt ou pow par sample, c'est clair que le problème de perf vient de là ;) Dans ce cas, précalcule des tables ou simplifie ton modèle avec des approximations.
253

Citation :
Je m'en sers pas du tout, comment on fait ?



tu t'en sers forcement ;) Mais il s'agit d'optimiser tes fonctions pour respecter le principe dit de localite, pour que tout ce que tu utilises dans un e petite boucle par exemple soit dans le cache.

J'ai fait un petit programme, et voila ce qu'il me dit pour le cout de exp, log, sqrt et cos (sous linux, gcc, et les flags d optimisation de base pour le compilo):

316 cycles pour exp en double (ca me parait beaucoup)
183 pour log en double
67 pour sqrt en double
224 pour cos

Typiquement, si tu over sample 2 fois, que tu es a 44.1 khz, a vue de nez, si tu fais un log sur chaque sample, tu bouffes deja 30 millions de cycles par seconde en stereo ! Faut voir que souvent, t'as des grosses contraintes sur ces fonctions (resultat exact, renvoi de nan s'il le faut, etc...), dont tu te fous en audio. Il y a aussi le probleme des nombres denormaux (Laurent de Soras a un bon article a ce sujet).

Par exemple, recemment, j'ai eu besoin d'un exp rapide, et aussi exact que la version IEEE. Pour ca, j'ai pas mal bidouille: ca prend du temps, mais ca vaut le coup si tu reutilises ensuite. Le principe de base pour les fonctions transcendantales, c'est de decouper l'entree en partie entiere et fractionnaire. La partie entiere est souvent simple a calculer, et le partie fractionnaire etant dans un intervalle limite, tu peux avoir des approximations qui convergent plus rapidement. Pour exp, les etaptes sont les suivantes:

- utiliser l'equivalent exp(x) = 2^(x/ln(2))
- calculer xi et xf la partie entiere et frac de x/ln(2)
- calculer 2^xi: la, il faut ruser, en utilisant le fameux truc x << 2 = x / 2 pour une puissance de 2, mais en manipulant bit par bit l'exposant au format IEEE (tu peux pas utiliser directemen xi >> 2, car ca peut depasser facilement la valeur max d'un int en 32 voire 64 bits).
- calculer 2^xf: la, tu utilises une approx polynomiale (il y a mieux que Taylor pour xf entre -1 et 1: tu peux aboutir a la precision 64 bits en 3 ou 4 termes).

En gardant la precision, tu peux gagner un facteur 3-4 facilement. Si tu abandonnes la precision, tu peux gagner un facteur 5 a 10 je pense.

J'avais ecrit un petit post sur le profiling, mais j'ai fais la commande reboot sur le mauvais ordi :oops: Bref, pour resumer, ce que je te conseillerai, c'est deja de pouvoir compiler facilement ton plug in en mode non VST, de maniere a ce que tu puisse le charger dans un hote bidon que tu as programme, pour pouvoir controler facilement l'environnement. L'hote n'a pas besoin de grand chose: en gros, charger le plug, lister les parametres, et appeler la fonction process avec des entrees bidons. Tu peux meme le programmer en python ;)
254

Citation : J'avais ecrit un petit post sur le profiling, mais j'ai fais la commande reboot sur le mauvais ordi Bref, pour resumer, ce que je te conseillerai, c'est deja de pouvoir compiler facilement ton plug in en mode non VST, de maniere a ce que tu puisse le charger dans un hote bidon que tu as programme, pour pouvoir controler facilement l'environnement. L'hote n'a pas besoin de grand chose: en gros, charger le plug, lister les parametres, et appeler la fonction process avec des entrees bidons. Tu peux meme le programmer en python



Non, pas besoin de reprogrammer un hôte, y'en a déjà des tout fait avec les sources itou itou. Qui plus est, le logiciel LTProf que j'ai conseillé ne nécessite pas de recompilation donc c'est tout bon ;)
255

Citation : Non, pas besoin de reprogrammer un hôte, y'en a déjà des tout fait avec les sources itou itou.



Apres ca depend de ce que tu recherches et de ce qui est dispo. La, je viens de telecharger les sources du sdk vst, et il y a pas de support linux, par exemple. Il faut donc porter le code correspondant.

Je suis pas tres au courant de la "scene" prog VST, mais je me demande par exemple s'il existe des hotes scriptables, pour pouvoir envoyer n'importe quel type d'entrees/sorties, pour tester les alloc+acces memoire sous valgrind, etc...
256
En fait, pas d'hôtes scriptables mais plusieurs petits utilitaires pour tester un VST :
- minihost, savihost ou l'hôte du sdk comme hôtes minimaux debuggables
- VST-scanner by V. Burel (VB audio)
- VST Plugin Analyser by Christian Budde
- Plugin Consultant by Achitophel Consulting

Pour en revenir aux approximations, je consulte *toujours* le bouquin "Numerical Recipes" lorsque j'ai un problème numérique à résoudre. C'est gratuit, c'est en pdf, et c'est là :
http://www.nr.com/
257

Citation : Il y a aussi le probleme des nombres denormaux (Laurent de Soras a un bon article a ce sujet).


Je connais le papier le L. de Soras, mais j'ai jamais réussi à mettre en évidence un impact sur les perfs. Les procs récents auraient-ils résolu ce problème :?!:

Wolfen > ce qui peut se produire aussi c'est que ton compilo peut être 'mauvais' quand tu le fais travailler sur des flottants. C'est ce qui m'est arrivé il y a quelques mois avec une vieille version de compilateur Borland: malgré les optims mises à fond, je me suis rendu compte qu'il se servait très bêtement de la pile du FPU. Alors qu'il y a beaucoup de perf à gagner à ce niveau-là, particulièrement dans les boucles. Tu peux compter sur un facteur 5, voire plus :8O:

Par ailleurs, comme te le disait Pov Gabou, quand tu utilises les libs de maths fournies avec ton compilo, il rajoute à ton code une gestion d'exceptions qui peut être très lourde. Exemple typique: sauvegardes et restaurations du registre de statut du FPU. Quand tu connais tes datas et que tu peux prévoir leur excursion, ces mécanismes de sécurité deviennent superflus et tu as intérêt à essayer de les court-circuiter, temporairement du moins..

Eventuellement, tu peux avoir besoin de descendre au niveau assembleur. Si ça ne te rebute pas, alors tu peux consulter cette page chez AMD, et plus particulièrement ce PDF qui pourra t'apporter des réponses sur les optimisations de cache et de branchements.

Tu trouveras dans ce PDF la liste des instructions FPU, et dans le chapitre 6 de ce PDF une bonne introduction à la prog du FPU.
A man, a plan, a canal : Panama
258
Merci tout le monde, là je crois que j'ai de quoi tester pour améliorer mes programmes

Ca me fait halluciner le nombre de cycles pour l'exponentielle :oo:

Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape | Soundcloud

259
Bigbill > tes liens sont énormes :aime:

Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape | Soundcloud

260
Je regarderais pas trop vers l'assembleur dans un premier temps, surtout si tu connais pas. Ca ve te prendre un temps fou, et c'est facile de faire n'importe quoi. Tu perds (evidemment) la portabilite, sans compter que ce qui est vrai pour un proc ne l'est plus pour un autre (pentium 4 vs M vs athlon vs opteron).

La regle de base avec l'ASM, c'est de ne pas l'utiliser avant d'avoir tout essaye. Typiquement, si tu as des problemes de denormalisation, d'utilisation de exp/sqrt/etc... a la place de tes propres fonctions, tu peux deja gagner un ordre de grandeur facile, alors que l'ASM, c'est de l'ordre de la micro optimization.

Citation :
Pour en revenir aux approximations, je consulte *toujours* le bouquin "Numerical Recipes" lorsque j'ai un problème numérique à résoudre. C'est gratuit, c'est en pdf, et c'est là :



Le probleme du NR, c'est qu'il est oriente maths, et que le plus souvent, t'as pas besoin de cette precision. Rggarde ); return false;" rel="nofollow" target="_blank">http://www.musicdsp.orgm, dans
archive, il y a pas mal de code C et ASM pour approximer log, sqrt, exp (en base 2 le plus souvent).

Citation :
Exemple typique: sauvegardes et restaurations du registre de statut du FPU.



Ca me fait penser a un autre truc hyper couteux: convertir les flottants en entier. Il faut pas laisser le compilo le faire pour toi. Les denormaux, ca depend de ce que tu codes. Ca peut arriver facilement dans tout code "recursif", comme les IIR; ca arrive rapidement avec l'exponentielle, aussi.

T'as pas un bout de code d'un truc qui prend du temps que tu peux poster ?