Reprise du message précédent :

Tu as raison, mais ce problème se contourne assez facilement : une table de sinus faisant généralement moins de 1 Ko, il suffit de la prefetcher directement en L1 à grands coups de prefetchT1, non ?

 
c'est quand meme un peu bete de se fusiller son L1 pour juste un sinus, non ? A voir comment un bete prefetch en debut de boucle m'a fait gagner 15% sur une routine, plus encore une paire de pourcent grace au movntq d'amd, j'ai l'impression qu'il vaut mieux optimiser a mort les acces ram plutot que de se battre pour eviter un fsin, qu'en dis tu ?

Ce sont 2 écoles... honnètement, comme tu le dis, je suis "old school", je viens de la démo pure et dure, ou le Dieu Virgule Fixe était roi et le fpu était le bouffon réservés aux nantis et aux codeurs fainéants... C'est clair que maintenant, mon raisonnement est has been, et que l'architecture des procs aidant, il faut coder différemment. Voila pourquoi trouver une doc récapitulant le nombre de cycles utilisés par les instructions du proc AMD m'aurait fait plaisir, histoire de voir un peu le chemin parcouru depuis les premiers Pentium MMX (qui sont apparus peu de temps avant que j'arrète les démos).

pour faire de la 3D on ne calcule le sinus qu'une fois par objet, et on en déduit la martice de rotation.
comme ça on s'en fout du temps pris par le calcul du sinus

 
la trigo est toujours le pire après la racine carrée

aujourd'hui y'a la racine carrée à précision réduite, + rapide et assez précise pour un calcul d'éclairage.
pareil pour la division.
C'est vrai que la trigo reste ce qu'il y a de pire, mais on peut souvent l'éviter.

vi newton-raphson est passé par loa.......

y'a un truc que je comprends pas à propos de la trigo.
à partir du 68040 ils ont viré les instructions trigo des cpu.
ben en compilant un programme C (donc le compilo se chargeait de faire la trigo à partir des instructions de bases), je gagnais davantage sur la trigo que sur le reste de la fpu, en upgradant de 68020+68882 vers 68040. Mystère!
Bon y'en a qui vont me dire que la trigo devait être moins précise, parce que c'est vrai que je vois pas d'autre explication

bin sur le powperpc la trigo est faite par un algo utilisant les instructions standard.
 
en fait dans tous les cpus, la trigo est fait par un microcode lourd et itératif, donc ou lieu de complexifier le cpu, ils ont choisis d'allouer des transistors aux instructions utilisée à haut fréquence, et de reporter ça vers du code asm/compilé...

c'est vrai, mais de là à aller + vite sans, c'est bizzare non?
enfin finalement sur nos PC on les a toujours même s'il faut s'en servir le moins possible.