Le pub des programmeurs
- 1 927 réponses
- 117 participants
- 131 735 vues
- 130 followers
Afficher le sujet de la discussion
Ca je sais que c'est pas conseillé
Des log et des pow principalement, j'imagine qu'il faut éviter...
Je m'en sers pas du tout, comment on fait ?
L'avantage des classes c'est que j'évite ce genre de trucs
La faut que je me renseigne...
Connais pas du tout, je vais faire du google
Merci des infos !
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 ;)
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.
Trop fort ces militaires, ils bossaient deja sur le cell avant que sony et IBM l'inventent
Plus serieusement, j'ai l'impression que tu as une experience fpga et dsp. Pour ces architectures, le dsp est souvent obligatoire, au moins au partie, ne serait-ce que parce que le C ne peut pas transcrire certaines instructions dsp (muladd, typiquement, addressage inverse pour la FFT). Puis la memoire est rapide, il y a pas de cache (au moins sur les trucs simples, mais je connais que les trucs tres simples en DSP
).
Le probleme de l'assembleur sur les procs recents, c'est qu'ils sont tellement complexes (niveau de pipeline, on etait a plus de 20 sur le prescott, je crois), avec tout ce que ca a comme consequence (reordonencement, entre autre), que ca devient difficile de prevoire ce qui va se passer. Et ce qui est plus rapide sur un athlon peut etre plus lent sur un P4. Je parle meme pas des problemes de taille de cache, etc... Donc a part quelques trucs bien precis, il vaut mieux rester en C et/ou intrinsices sse. Par exemple, pour exp, en restant en C, tu peux facilement gagner un facteur 2 a 4 par rapport a la GNU C (je pense que sous windows/mac, c'est plus optimise, mais c'est plus cher, aussi). Par contre, connaitre l'assembleur est un plus, ne serait-ce que pour avoir une idee de comment les choses marchent par derriere.
En audio, un truc bien complexe a gerer, c'est l'oversampling. Pour eviter l'aliasing, par exemple dans les oscillo modules, il faut over-sampler ton signal pour avoir de bons resultats. Tout le truc, c'est de savoir de combien t'as besoin d'oversampler, selon tes modulations; et en interne, dans ton moteur audio, tu peux avoir plusieurs frequences de fonctionnement en parralllele selon les parties...
Typiquement, j'aurais tendance a penser que reaktor est un des logiciels les plus complexes en audio (les dernieres versions auraient un compilateur JIT, mais c'est dur de trouver des infos fiables a ce sujet)
Quelques threads relativement recents sur des techniques pour le son
http://www.music.columbia.edu/pipermail/music-dsp/2004-December.txt (infos sur les langages recents, generation de code, etc...)
http://www.music.columbia.edu/pipermail/music-dsp/2005-December.txt (infos sur processing par block contre process par sample).
In fine, le truc ultime serait quelque chose analogue aux techniques employees par fftw et atlas, a savoir generation de code automatique dependant de la machine, ou justement des trucs style JIT, etc... Java a lance le truc dans l'industrie, et il existe maintenant des implementations open source assez sophistiquees pour voir des choses qui il y a encore 5 ans etaient cantonnes a l'academique: machines virtuelles comme mono ou parrot. En generation de code a partir d'algo, il y a FAUST sous linux:
http://faudiostream.sourceforge.net/
Dans la categorie "langages specialises pour faire du son", il y a supercollider qui me vient en tete, qui est relativement "ancien". Il y a aussi chuck dont j'ai deja parle.
Pas vraiment choque, c'est juste que ca rappelle furieusement le cell, un coeur ppc plus des dsp, c'est tout. J'ai pas suivi ce qui se passait, parce qu'il y a trop de buzz pour l'instant, mais je me disais qu'une ps3. une fois que ca devient abordable, et s'il y a un kit linux, pouvait etre interessant pour programmer en dsp.
Ca depend de tes reponses impulsionnelles: si elles sont courtes (le courte dependant du processeur, mais de l'ordre de quelques dizaines pour les trucs courants et une bonne implementation fft), a "la main", sinon, en effet, avec la FFT, en faisant gaffe parce que multiplication fft = convolution circulaire (il faut padder tes blocs pour eviter "l'aliasing temporel"). Si tu veux faire du temps reel, ca devient nettement plus complique car il faut gerer la latence avec des blocs de taille variable, et des decoupages de la reponse impulsionnelle (avec les brevets qui vont avec
).
Tu peux regarder brutefir pour voir un peu comment ca marche dans ces cas.
Bon heureusement c'est du mono
Pour l'instant y a un certain nombre d'étages de gain à la suite, par exemple 5, chacun étant constitué d'une fonction de waveshaping polynomiale et de deux filtres avant et après... Pour la dénormalisation, j'ajoute du bruit en entrée de chaque filtre à -200 dB, que j'ai calculé au lancement du programme et stocké dans un tableau pour éviter les calculs en temps réel.
L'oversampling a une influence dramatique sur les perfs n'empêche
le passage par la FFT serait plus rapide ??
tu as des retours sur ces cartes d'évaluation ?
parcque c'est vrai qu'elles sont sympa, et en plus, l'outil de dev en ASM est pas dégueu !
y a des programeurs sur AF si oui vous bossez sous quoi ?Wolfen
14007
Rédacteur·trice
Membre depuis 23 ans
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
466
Posteur·euse AFfamé·e
Membre depuis 22 ans
Pov Gabou
19553
Drogué·e à l’AFéine
Membre depuis 23 ans
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
466
Posteur·euse AFfamé·e
Membre depuis 22 ans
Pov Gabou
19553
Drogué·e à l’AFéine
Membre depuis 23 ans
zieQ
466
Posteur·euse AFfamé·e
Membre depuis 22 ans
bigbill
665
Posteur·euse AFfolé·e
Membre depuis 22 ans
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.
A man, a plan, a canal : Panama
Wolfen
14007
Rédacteur·trice
Membre depuis 23 ans
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
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
14007
Rédacteur·trice
Membre depuis 23 ans
Bigbill > tes liens sont énormes 
Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape | Soundcloud
Pov Gabou
19553
Drogué·e à l’AFéine
Membre depuis 23 ans
bara
6949
Membre d’honneur
Membre depuis 21 ans
Mon impression par rapport à toutes ces histoires d'optim. Débat vachement interressant, d'ailleurs.
J'ai eu l'occasion dans mon premier boulot (donc avant de faire mumuse avec du midi et de l'algorythmique musicale) de coder pour un usage ultra-critique (militaire). Alors là, c'est sur que l'aspect temps-réel c'est vachement important.
La stratégie, à mon sens, et je rejoins ce qui a été dit ici, c'est:
1. estimer le gap entre la spec et les résultats réels: passé un certain niveau de complexité, on va passer 1000 ans à gagner presque rien, donc limite vaux mieux changer d'archi ou d'approche.
Par exemple, j'ai eu à réaliser une FFT sur une plate-forme un peu zarbi à l'époque: des FPGA qui contenait un coeur de processeur IBM PowerPC. Donc, j'ai codé mon merdier bourrinement, et j'allais 40 fois plus lentement que voulu. J'ai enablé tous mes caches et mes prefetches, regardé la gueule de l'assembleur généré par le compilateur, commuté l'horloge de la carte de dév' (et donc du proc) de 100MHz à 450MHz (si si, on peux oublier de faire ça). J'en suis arrivé à coder tous mes papillons en assembleurs, en restant 4 fois plus lent que voulu. On a fini par fabriquer une palanquée d'opérateurs "papillon de FFT" purement FPGA (VHDL, quoi, ma formation de base), le processeur n'étant là que pour séquencer le merdier, donner à bouffer aux papillons hardware, gérer les entrées-sorties et interruptions diverses. Là, on était 2 fois plus rapides que la spec.
2. localiser les points critiques: si une fonction est appellée pour traiter chaque sample, ça peux valoir le coup de l'optimiser plus que l'init du soft qui ne sera utilisée qu'une fois
3. optimiser à proprement parler, et là ya plein de pistes:
a. passer aux fonctions les bons paramêtres, ni plus ni moins
b. vérifier que tous les cas limites sont traités UNE SEULE FOIS
c. effectivement, bien connaitre son compilateur: j'en ai vu qui pour diviser par deux des entiers réalisaient une division, d'autres qui castaient en flottant, multipliaient par 0.5 et faisaient des arrondis, et d'autres enfin qui décalaient vers la droite... C'est pas le même prix.
d. ne pas hésiter à changer le format des données et des constantes dès l'entrée: un MulAcc sur 32 bits prends parfois un seul cycle sur certaines machines, bicoze ils ont un copro qui ne fait que ça. Deux MulAcc sur 16 bits prendront deux fois plus de temps. Ca vaux le coup de concaténer parties réelles et imaginaires quand on fait du papillon de FFT (je sais plus bien ce que j'avais magouillé, mais j'avais pas mal gagné sur certaines plate-formes avec un truc dans ce genre là).
e. effectivement, relativiser la précision du bordel: selon l'application, un développement limité à l'odre 1 ou 2 sera plus rapide qu'un cosinus et tout aussi acceptable du point de vue de la précision. De même, les log se tabulent vachement bien selon ce que l'on en fait, ou s'approximent avec plusieurs bouts de droite.
Bon, et là j'ai la sale impression d'avoir écrit un tissu de conneries et de Lapalissades. Désolé
Sinon, simu d'ampli, j'ai fait aussi . Envoie moi un mail, Wolfen...
J'ai eu l'occasion dans mon premier boulot (donc avant de faire mumuse avec du midi et de l'algorythmique musicale) de coder pour un usage ultra-critique (militaire). Alors là, c'est sur que l'aspect temps-réel c'est vachement important.
La stratégie, à mon sens, et je rejoins ce qui a été dit ici, c'est:
1. estimer le gap entre la spec et les résultats réels: passé un certain niveau de complexité, on va passer 1000 ans à gagner presque rien, donc limite vaux mieux changer d'archi ou d'approche.
Par exemple, j'ai eu à réaliser une FFT sur une plate-forme un peu zarbi à l'époque: des FPGA qui contenait un coeur de processeur IBM PowerPC. Donc, j'ai codé mon merdier bourrinement, et j'allais 40 fois plus lentement que voulu. J'ai enablé tous mes caches et mes prefetches, regardé la gueule de l'assembleur généré par le compilateur, commuté l'horloge de la carte de dév' (et donc du proc) de 100MHz à 450MHz (si si, on peux oublier de faire ça). J'en suis arrivé à coder tous mes papillons en assembleurs, en restant 4 fois plus lent que voulu. On a fini par fabriquer une palanquée d'opérateurs "papillon de FFT" purement FPGA (VHDL, quoi, ma formation de base), le processeur n'étant là que pour séquencer le merdier, donner à bouffer aux papillons hardware, gérer les entrées-sorties et interruptions diverses. Là, on était 2 fois plus rapides que la spec.
2. localiser les points critiques: si une fonction est appellée pour traiter chaque sample, ça peux valoir le coup de l'optimiser plus que l'init du soft qui ne sera utilisée qu'une fois
3. optimiser à proprement parler, et là ya plein de pistes:
a. passer aux fonctions les bons paramêtres, ni plus ni moins
b. vérifier que tous les cas limites sont traités UNE SEULE FOIS
c. effectivement, bien connaitre son compilateur: j'en ai vu qui pour diviser par deux des entiers réalisaient une division, d'autres qui castaient en flottant, multipliaient par 0.5 et faisaient des arrondis, et d'autres enfin qui décalaient vers la droite... C'est pas le même prix.
d. ne pas hésiter à changer le format des données et des constantes dès l'entrée: un MulAcc sur 32 bits prends parfois un seul cycle sur certaines machines, bicoze ils ont un copro qui ne fait que ça. Deux MulAcc sur 16 bits prendront deux fois plus de temps. Ca vaux le coup de concaténer parties réelles et imaginaires quand on fait du papillon de FFT (je sais plus bien ce que j'avais magouillé, mais j'avais pas mal gagné sur certaines plate-formes avec un truc dans ce genre là).
e. effectivement, relativiser la précision du bordel: selon l'application, un développement limité à l'odre 1 ou 2 sera plus rapide qu'un cosinus et tout aussi acceptable du point de vue de la précision. De même, les log se tabulent vachement bien selon ce que l'on en fait, ou s'approximent avec plusieurs bouts de droite.
Bon, et là j'ai la sale impression d'avoir écrit un tissu de conneries et de Lapalissades. Désolé
Sinon, simu d'ampli, j'ai fait aussi
. Envoie moi un mail, Wolfen...Pov Gabou
19553
Drogué·e à l’AFéine
Membre depuis 23 ans
Citation :
Par exemple, j'ai eu à réaliser une FFT sur une plate-forme un peu zarbi à l'époque: des FPGA qui contenait un coeur de processeur IBM PowerPC
Trop fort ces militaires, ils bossaient deja sur le cell avant que sony et IBM l'inventent
Plus serieusement, j'ai l'impression que tu as une experience fpga et dsp. Pour ces architectures, le dsp est souvent obligatoire, au moins au partie, ne serait-ce que parce que le C ne peut pas transcrire certaines instructions dsp (muladd, typiquement, addressage inverse pour la FFT). Puis la memoire est rapide, il y a pas de cache (au moins sur les trucs simples, mais je connais que les trucs tres simples en DSP
).Le probleme de l'assembleur sur les procs recents, c'est qu'ils sont tellement complexes (niveau de pipeline, on etait a plus de 20 sur le prescott, je crois), avec tout ce que ca a comme consequence (reordonencement, entre autre), que ca devient difficile de prevoire ce qui va se passer. Et ce qui est plus rapide sur un athlon peut etre plus lent sur un P4. Je parle meme pas des problemes de taille de cache, etc... Donc a part quelques trucs bien precis, il vaut mieux rester en C et/ou intrinsices sse. Par exemple, pour exp, en restant en C, tu peux facilement gagner un facteur 2 a 4 par rapport a la GNU C (je pense que sous windows/mac, c'est plus optimise, mais c'est plus cher, aussi). Par contre, connaitre l'assembleur est un plus, ne serait-ce que pour avoir une idee de comment les choses marchent par derriere.
En audio, un truc bien complexe a gerer, c'est l'oversampling. Pour eviter l'aliasing, par exemple dans les oscillo modules, il faut over-sampler ton signal pour avoir de bons resultats. Tout le truc, c'est de savoir de combien t'as besoin d'oversampler, selon tes modulations; et en interne, dans ton moteur audio, tu peux avoir plusieurs frequences de fonctionnement en parralllele selon les parties...
Typiquement, j'aurais tendance a penser que reaktor est un des logiciels les plus complexes en audio (les dernieres versions auraient un compilateur JIT, mais c'est dur de trouver des infos fiables a ce sujet)
Quelques threads relativement recents sur des techniques pour le son
http://www.music.columbia.edu/pipermail/music-dsp/2004-December.txt (infos sur les langages recents, generation de code, etc...)
http://www.music.columbia.edu/pipermail/music-dsp/2005-December.txt (infos sur processing par block contre process par sample).
In fine, le truc ultime serait quelque chose analogue aux techniques employees par fftw et atlas, a savoir generation de code automatique dependant de la machine, ou justement des trucs style JIT, etc... Java a lance le truc dans l'industrie, et il existe maintenant des implementations open source assez sophistiquees pour voir des choses qui il y a encore 5 ans etaient cantonnes a l'academique: machines virtuelles comme mono ou parrot. En generation de code a partir d'algo, il y a FAUST sous linux:
http://faudiostream.sourceforge.net/
Dans la categorie "langages specialises pour faire du son", il y a supercollider qui me vient en tete, qui est relativement "ancien". Il y a aussi chuck dont j'ai deja parle.
bara
6949
Membre d’honneur
Membre depuis 21 ans
miles1981
8370
Je poste, donc je suis
Membre depuis 21 ans
Bosser sur des cartes comme ça, ça me plairait bien, pour faire de l'audio, ça doit aussi jeter 
Y'a certain DSP qui n'ont même pas l'adressage inverse, chez Analog Device ou TI, ça paraît être un comble, mais c'est la vérité - je crois que c'était les Blackfin où j'avais dû faire le calcul à la main, mais comme la bestiole permet d'écrire de l'assembleur parallèle, elle compense à l'aise -
Y'a certain DSP qui n'ont même pas l'adressage inverse, chez Analog Device ou TI, ça paraît être un comble, mais c'est la vérité - je crois que c'était les Blackfin où j'avais dû faire le calcul à la main, mais comme la bestiole permet d'écrire de l'assembleur parallèle, elle compense à l'aise -
Audio Toolkit: http://www.audio-tk.com/
Pov Gabou
19553
Drogué·e à l’AFéine
Membre depuis 23 ans
Citation :
Le composant en question est le Xilinx Virtex-II Pro, je vois pas pourquoi t'as l'air choqué
Pas vraiment choque, c'est juste que ca rappelle furieusement le cell, un coeur ppc plus des dsp, c'est tout. J'ai pas suivi ce qui se passait, parce qu'il y a trop de buzz pour l'instant, mais je me disais qu'une ps3. une fois que ca devient abordable, et s'il y a un kit linux, pouvait etre interessant pour programmer en dsp.
Citation :
Sinon, tiens, en ce moment je m'interresse à la convolution: Gabou tu pratiques ça comment ? Bourrin en faisant la somme come un gros sale ? Ou FFT -> Multiplication -> FFT inverse ?
Ca depend de tes reponses impulsionnelles: si elles sont courtes (le courte dependant du processeur, mais de l'ordre de quelques dizaines pour les trucs courants et une bonne implementation fft), a "la main", sinon, en effet, avec la FFT, en faisant gaffe parce que multiplication fft = convolution circulaire (il faut padder tes blocs pour eviter "l'aliasing temporel"). Si tu veux faire du temps reel, ca devient nettement plus complique car il faut gerer la latence avec des blocs de taille variable, et des decoupages de la reponse impulsionnelle (avec les brevets qui vont avec
).Tu peux regarder brutefir pour voir un peu comment ca marche dans ces cas.
Wolfen
14007
Rédacteur·trice
Membre depuis 23 ans
Gabou > pour l'assembleur, c'est juste que j'ai vu pas mal de développeurs VST qui s'en servent, ainsi que des jeux d'instructions SSE par exemple, pour optimiser leur bordel 
J'ai vu aussi des calculs faits sur du binaire, des optimisations sur l'utilisation des tableaux... Et pour le bout de code, c'est vraiment gros ma fonction processReplacing avec tous les appels de classe En plus je fais de l'oversampling x8 en utilisant la classe HalfBandFilter de MusicDSP, ça me parait être un des éléments critiques, faudrait le remplacer par un unique filtre designé sous Matlab... Le reste c'est des filtres de base et des fonctions polynomiales, en tout cas pour le temps réel...
Miles > C'est quoi pour toi les meilleurs DSP pour faire de l'audio ? Analog Device a l'air bien côté...
Bara > Wow le post
Le mieux c'est avec les FFT, à fond, si tu as des impulses qui font au moins une centaine d'échantillons Moi j'ai utilisé deux librairies C++, FFTW et FFTReal (la deuxième est beaucoup mieux à utiliser d'ailleurs, et on peut l'utiliser sur des produits commerciaux). Après faut gérer le partitionnement du signal d'entrée pour le temps réel (algorithmes overlap-add ou overlap-save), ainsi que celui de la réponse impulsionnelle si sa taille est grande devant celle du buffer d'entrée... Des infos sur DSPGuide.
Je t'envoie vite fait un message aussi pour la simulation d'ampli
Très intéressant tout ça
J'ai vu aussi des calculs faits sur du binaire, des optimisations sur l'utilisation des tableaux... Et pour le bout de code, c'est vraiment gros ma fonction processReplacing avec tous les appels de classe En plus je fais de l'oversampling x8 en utilisant la classe HalfBandFilter de MusicDSP, ça me parait être un des éléments critiques, faudrait le remplacer par un unique filtre designé sous Matlab... Le reste c'est des filtres de base et des fonctions polynomiales, en tout cas pour le temps réel...Miles > C'est quoi pour toi les meilleurs DSP pour faire de l'audio ? Analog Device a l'air bien côté...
Bara > Wow le post
Citation : Sinon, tiens, en ce moment je m'interresse à la convolution: Gabou tu pratiques ça comment ? Bourrin en faisant la somme come un gros sale ? Ou FFT -> Multiplication -> FFT inverse ?
Le mieux c'est avec les FFT, à fond, si tu as des impulses qui font au moins une centaine d'échantillons
Moi j'ai utilisé deux librairies C++, FFTW et FFTReal (la deuxième est beaucoup mieux à utiliser d'ailleurs, et on peut l'utiliser sur des produits commerciaux). Après faut gérer le partitionnement du signal d'entrée pour le temps réel (algorithmes overlap-add ou overlap-save), ainsi que celui de la réponse impulsionnelle si sa taille est grande devant celle du buffer d'entrée... Des infos sur DSPGuide.Je t'envoie vite fait un message aussi pour la simulation d'ampli
Très intéressant tout ça
Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape | Soundcloud
Pov Gabou
19553
Drogué·e à l’AFéine
Membre depuis 23 ans
Wolfen
14007
Rédacteur·trice
Membre depuis 23 ans
Citation : oversampling x8, ca veut donc dire qu'en stereo, tu dois traiter 8*88200 ~ 650000 samples / s. A ce train la, tout ce que tu peux faire va prendre vachement cpu: si tu calcules un cos, un sin et un exp betement sur chacun des samples, tu peux deja bouffer 500 Mhz.
Bon heureusement c'est du mono
Citation : Tu fais quoi concretement dans ce plug ?
Pour l'instant y a un certain nombre d'étages de gain à la suite, par exemple 5, chacun étant constitué d'une fonction de waveshaping polynomiale et de deux filtres avant et après... Pour la dénormalisation, j'ajoute du bruit en entrée de chaque filtre à -200 dB, que j'ai calculé au lancement du programme et stocké dans un tableau pour éviter les calculs en temps réel.
L'oversampling a une influence dramatique sur les perfs n'empêche
Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape | Soundcloud
Pov Gabou
19553
Drogué·e à l’AFéine
Membre depuis 23 ans
Pov Gabou
19553
Drogué·e à l’AFéine
Membre depuis 23 ans
miles1981
8370
Je poste, donc je suis
Membre depuis 21 ans
Anonyme
521397
Conernant l'utilisation d'un GPU comme d'un dsp, j'ai lu que le la vitesse du port AGP était trop faible pour pouvoir faire des traitements intéréssant, a voir ensutie avec le PCIe
Pour les cells, il parait que ceux de la PS3 sont des grosses merde, que la console est aussi (peut etre plus) dur à utiliser que la PS2, et que la plupart des gens qui bossent dessus sont très inquiets car les perfs sont a peu pret lamentable...
Pour les cells, il parait que ceux de la PS3 sont des grosses merde, que la console est aussi (peut etre plus) dur à utiliser que la PS2, et que la plupart des gens qui bossent dessus sont très inquiets car les perfs sont a peu pret lamentable...
miles1981
8370
Je poste, donc je suis
Membre depuis 21 ans
Anonyme
521397
thie91
87
Posteur·euse AFfranchi·e
Membre depuis 20 ans
Citation : Sinon, tiens, en ce moment je m'interresse à la convolution: Gabou tu pratiques ça comment ? Bourrin en faisant la somme come un gros sale ? Ou FFT -> Multiplication -> FFT inverse ?
le passage par la FFT serait plus rapide ??
Citation :
mais si je devais choisir là tout de suite, je prendrai le Blackfin d'AD, même s'il a des trucs qui manquent, la carte d'évaluation elle-même a 4 entrées audio, 6 sorties + un vidéo, USB, réseau, donc il y a de quoi se faire plaisir.
tu as des retours sur ces cartes d'évaluation ?
parcque c'est vrai qu'elles sont sympa, et en plus, l'outil de dev en ASM est pas dégueu !
- < Liste des sujets
- Charte