Bonjour,
 
Je dois implémenter un système de contrôle dans un micro-contrôleur (PIC32), système qui doit faire un certain nombre de calculs trigonométriques (multiplications par des sinus/cosinus en fait). Étant donné que les premiers problèmes de performance commencent déjà à pointer leurs nez, j'ai pensé que le 1er endroit où il faudrait optimiser, c'est au niveau des très gourmandes fonctions math.h.
Déjà, est-ce que c'est vrai que sin(f)/cos(f) sont aussi coûteuses? Je spécifie le "f" car actuellement je fais tous mes calculs en float (ce qui pourrait être porté à changer si je manque toujours de performances).
Ensuite, j'ai pensé que le mieux pour gagner en rapidité c'est de faire une lookup-table. En cherchant sur internet (et en particulier sur wiki : http://en.wikipedia.org/wiki/Lookup_table ) j'ai trouvé plusieurs méthodes plus ou moins gourmandes en ressources mais je n'arrive pas à me rendre compte à quel point j'y gagne/perd en ressources.
 
Vous en général vous utilisez quoi dans ce genre de cas?
 
Merci à vous

Principalement    
Sinon un truc con mais qui peut faire gagner de la place c'est de pas créer 2 tables pour sin et cos (et tan) mais d'utiliser la meme
Mais à part faire ce que dit wikipedia je vois pas trop comment d'autre on peut créer une table, c'était quoi les autres méthodes que t'as vu ?

Par exemple le fait de faire du un-uniforme sampling du sinus

Quand tu es proche de pi/2 et 3.pi/4 tu précalcules plus de valeurs, non ? En gros du fais varier ton pas de sampling en fonction de ton abscisse (modulo 2.pi)

Ben en gros je dirais qu'il y a 3 choses à considérer :  
- la précision dont t'as besoin
- la rapidité du µC
- l'emmerdemment que t'es pret à subir pour programmer le machin
 
Quelque soit la méthode choisie on peut supposer que ca occupera la même place dans la RAM.
 
Avec la méthode la plus simple (à programmer et à executer pour le µC) "espaçage uniforme" et tu cherche la valeur la plus proche, t'as une erreur R maxi de 0.5*e, e étant l'espace entre 2 points. Pour n points entre -pi et pi, R = pi / (n-1)
( n = 101 -> R = 0.03 )
 
La méthode que j'utiliserais c'est simplement d'ajouter l'interpo linéaire. Ca serait une insulte de dire que c'est plus compliqué à programmer et ca alourdit à peine la charge du µC. D'après wiki tu passerais à une erreur max sur tes valeurs de R = e²/8 = 0.5 * pi² / (n-1)²
( n = 101 -> R = 0.00005 )
 
Si tu as vraiment besoin de plus de précision pour moi l'étape d'après ce serait d'utiliser les symétries pour distribuer tes n points entre 0 et pi/2 seulement. R est divisé par 4 dans le premier cas et par 16 dans le deuxième. C'est pareil pour le µC mais bon, c'est plus embettant à programmer.
 
Si c'est pas encore assez tu peux tenter de répartir les points de facon non-uniforme. Sans interpolation linéaire (ce que je recommanderais pas) il faudrait augmenter le nombre de points autour de 0, et avec interpolation autour de (+/-)pi/2.  
Ca devrait pas rajouter trop de travail pour le µC mais c'est encore plus merdique à programmer, faut etre capable de retrouver les bons points à partir d'une abscisse donnée.
 
Bon tout ca c'est à la louche, si quelqu'un a des valeurs chiffrées je suis preneur, je serai surement amené à faire ca un jour

les tables de lookup pour les table trigo ca fait lurette que ca sert à rien. Si tu as de vrais angles (aka entre pi/4 et -pi/4) y a des polynomes tres simples qui se caclule rapidos avec un polynome d'estrin.

J'ai faillit dire la même chose par habitude des processeurs classiques, mais je connais pas du tout les micro-controlleurs, le rapport vitesse de calcul vs. temps d'accès à la ram est le même ?

Oui mais moi j'ai des angles entre -pi et pi. Donc est-ce que ça reste rentable d'utiliser ces polynômes si après je dois quand même jouer sur les relations trigo pour reconstituer mon angle ?

Edit : Et dans ce cas, est-ce que c'est pas tout simplement ce que la biblio math.h intègre?

non, elle a un polynome complet pour +inf,-inf. Dans mes outisl de dev scientifique, on c'ets amusé à recodé cos/sin par section avec des polynomes bien pensés et on va en gros 50 fois plus vite que std::cos  
 
cf mon talk a bosot'con de cette année

Je vois
Donc dans mon cas je fais quoi alors? Je cherche un polynôme pour -pi à pi ou bien c'est plus rapide de prendre l'algo dont tu parles et qui est valable sur un plus petit domaine et après jouer sur les symétries et relations trigo?

Mesure à l'oscillo

Hein?

Pourquoi tu compares pas le temps d'exécution des différentes méthodes en mesurant ?

parce que là j'ai aucun pin de libre sur mon PCB pour pouvoir controler ça. Donc je demandais tout simplement si qqn le savait

Je suppose que t'as pas de timer sur le PIC20 ?
 

Si j'ai compris ton powerpoint de BoostCon correctement, tu choisis un polynome (éventuellement par morceaux) qui approche le sinus. Quand tu as besoin d'une valeur de sinus tu évalues ton polynome au point qui t'interesse, de préférence facon Estrin plutot que a + b.x + c. x^2 ...
C'est ca ?
 

Je comprend pas le rapport : pour faire des calculs t'es bien aussi obligé d'acceder à la ram ? En quoi aller chercher les coefficients d'un polynome et faire des calculs serait plus rapide que juste aller chercher la réponse dans une table toute prête (précision mise à part) ?
 

 
Oui. On fait du Estrin car ca nous permets d'evaluer le max de produit-somme en parallele dans le pipeline, produit-somme qui avec les bonnes extensions SIMD se réduisent à une instruction. Horner marche aussi pour les "petits" polynomes. Ensuite, on a un polynome par sous-interval de définition du sinus/cosinus.