Le pub des programmeurs
- 1 927 réponses
- 117 participants
- 129 501 vues
- 130 followers
y a des programeurs sur AF si oui vous bossez sous quoi ?
Wolfen
Citation : - dans la fonction process, est ce que tu utilises des appels systeme ?
Ca je sais que c'est pas conseillé
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 ?
Citation : - est ce que tu calcules plusieurs fois les memes valeurs ?
L'avantage des classes c'est que j'évite ce genre de trucs
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
Merci des infos !
Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape | Soundcloud
zieQ
Pov Gabou
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
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 ;)zieQ
Pov Gabou
zieQ
bigbill
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
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.
Wolfen
Ca me fait halluciner le nombre de cycles pour l'exponentielle
Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape | Soundcloud
Wolfen
Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape | Soundcloud
Pov Gabou
- < Liste des sujets
- Charte