Sujet Le pub des programmeurs
- 1 925 réponses
- 117 participants
- 122 532 vues
- 130 followers
Afficher le sujet de la discussion
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
y a des programeurs sur AF si oui vous bossez sous quoi ?bara
6949
Membre d’honneur
Membre depuis 20 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 22 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 20 ans
miles1981
8332
Je poste, donc je suis
Membre depuis 20 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 22 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
13826
Rédacteur·trice
Membre depuis 22 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
Pov Gabou
19553
Drogué·e à l’AFéine
Membre depuis 22 ans
Wolfen
13826
Rédacteur·trice
Membre depuis 22 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
Pov Gabou
19553
Drogué·e à l’AFéine
Membre depuis 22 ans
Pov Gabou
19553
Drogué·e à l’AFéine
Membre depuis 22 ans
- < Liste des sujets
- Charte