Hard contre Soft
- 36 réponses
- 10 participants
- 779 vues
- 2 followers
Anonyme
Pov Gabou
Citation :
(à dire vrai sur pentium, je bosserais avec des entiers en utilisant les pipelines u et v pour transposer directement l'algo entier du dsp 24bit plutôt que de réécrire tout en fpu
L'ennui, c'est que tu n'as pas le choix : le VST, et certainement d'autres interfaces classiques ( faudrait voir pour AudioUnit ) t'impose l'usage des flottants. Et même si c'est beaucoup plus complexe à gérer que les entiers, le pipeline et cie fait qu'en pratique, les additions et multiplications sont à peu près aussi rapide en flottants et en fixe ( en 32 bits ). Sans compter qu'en te débrouillant bien, tu peux souvent faire deux opérations avec la fpu "en même temps" si elles sont indépendantes ( en 32 bits ), voir 4 avec SSE.
Mais de toute façon, les DSP ont l'air d'avoir des avantages énorme pour certaines choses, comme la rapidité d'accés à la mémoire ( gros pb sous PC : à partir d'un moment, ça devient plus rapide de recalculer plutôt que d'utiliser des tables à cause de la lenteur de la ram ). Je verrai ça le jour où je pourrai concrètement programmer qqch sur dsp ( en gros, quand j'aurai le temps, et que je pourrai m'acheter un chameleon
).Citation :
On peut parfaitement faire entrer des données 24bits non signés dans un algo, faire le traitement sur un dsp 24 bits ou sur un pc 32 bits avec fpu et avoir dans les deux cas exactement le même résultat en 24bits non signés si l'algo est strictement respecté.
Si j'écris un décrypteur qui à une clef de décryptage et à un bloc de donnée cryptées me renvoies un résultat "décrypté" différent selon que je l'implémente sur un motorola 68030 ou sur un alpha, c'est que j'ai sérieusement merdé par rapport à l'algo d'origine.
Le problème de ton exemple, c'est que le cryptage n'utilise que des entiers. Pas la fpu, ni les calculs dsp en MAO. Pour ton premier exemple, je te défie de le faire pratiquement... C'est strictement impossible. Le pb des flottants, c'est qu'il existe des nombres que tu ne peux pas représenter. Des fois, pour des opérations du type floor(a), où a est flottant et vaut 0.5 en théorie, à la suite d'un calcul en flottant, ça peut valoir 0 ou 1, car selon les calculs précédents, pratiquement, ce sera 0.4999999999 ou 0.50000000000001, par exemple.
Tel est pris qui croyait prendre
Anonyme
Pov Gabou
Sinon, bien sûr, il fallait prendre round et pas floor, je "m'ai trompé"
Et dans les deux cas, ça donne un résultat différent. Un algo, en pratique, pour un filtre par exemple, les erreurs d'arrondis en flottant et en entier ne sont pas du tout les mêmes. Entre autre parce que pour un entier, plus t'es proche de zaeros, moins la précision est bonne ( tu peux rapprocher ça de la quantification linéaire ), alors que les flottants ont toujours la même précision, quel que soit l'amplitude ( un peu comme la quantif non linéaire ).Mais c'est vrai qu'on s'écarte pas mal du sujet ( ça me rappelle la discussion sur lesdistributions avec blue bird ).
Inusable™
Pov Gabou
Dj gad
- < Liste des sujets
- Charte