Version imprimable
Bonjour,
Je commence à faire en peu d'OpenGL et donc tu temps réel et j'aimerais par exemple savoir si faire 3 multiplications de int est plus rapide que de calculer un cosinus ou si faire 2 divisions de float est plus rapide que de faire un sqrt, etc...
Existe t-il des tableaux qui indique le temps CPU pour les opérateurs/fonctions du C++ ? (* / - + cos, sin, sqrt, etc) ?
merci
Si tu commences à bidouiller avec OpenGL, tu devrais déjà te pencher sur ce que coûtent les différentes structures / fonctions graphique que tu vas utiliser. C'est beaucoup plus important en termes de performances que des cos ou des multiplications.
Et puis je ne vois pas pourquoi tu veux comparer des sin à des multiplications, ou des divisions à des racines carrées ; à moins que tu n'implémentes des algorithmes subsidiaires pour les remplacer (ce que tu ne devrais pas faire, du moins pas avant longtemps).
Sinon, il est souvent trés intéressant de faire des tests de performance soi-même. Si on a le temps, c'est extrêmement formateur. Je viens de découvrir l'analyseur de performance VTune de Intel, dont une version d'évaluation 30jours est disponible en téléchargement sur leur site. Il est vraiment bien.
bah, c'est bien simple en fait : a l'heure actuelle, on en sait a peut près rien :?
tout ca à cause de l'ensemble des optimisation interne au processeur (cache, préfetch et autre branchement prédictif). En plus, en interne, les instruction processeurs ne sont plus des instruction CISC X86, mais une sorte de RISC.
les tableau de nombre de cycle par instruction, ca existait il y a 10/15 ans, mais depuis les pentium/pentium2, ca n'a plus trop cours, ca le temps d'execution d'une instruction depend de plus en plus de context d'execution qu'autre chose.
merci
J'ai déjà regardé la FAQ pour ça ( http://jeux.developpez.com/faq/openg...meliorer_perfs ) ;)Citation:
Envoyé par Laurent Gomila
S'était des exemples comme ça que j'ai donné sans trop réfléchir.Citation:
Envoyé par Laurent Gomila
Exemple plus concret : sachant que pour faire une rotation d'un objet, j'ai à ma disposition des matrices et des quaternions : que vaut-il mieux utiliser ?
- Soit une matrice où le processeur devra calculer X multiplications et Y cos/sin
- Soit un quaternion où le processeur devra calculer Z multiplications et W cos/sin
Si j'ai 10 000 cubes dans ma scène avec chacun une matrice de transformation différente, je risque de faire chauffer le processeur si je ne fait pas attention au nombre de cos/sin effectué par le processeur, non ?
Hum, a vrai dire, je m'attendait en peu à ce genre de réponse : ça dépend trop du processeur :(Citation:
Envoyé par bafman
Merci quand même à tous, je vais voir ce que c'est le testeur de performance d'Intel
Avant de regarder les cos et les multiplcations qui se cachent derrière les fonctions, cherche ce qui est le plus efficace selon le contexte. En général les quaternions sont plus appropriés pour représenter les rotations, mais une matrice peut parfois être plus appropriée ; ça dépend du contexte.
Dans quel contexte doit-on préférer les matrices (resp. les quaternions) ?Citation:
Envoyé par Laurent Gomila
Il faut préférer les quaternions si on a beaucoup de manipulations à faire dessus (que 4 composantes à manipuler, et les algos sont généralement plus simples).
Par contre si on doit stocker une rotation qui ne bougera jamais, mieux vaut utiliser une matrice puisque de toute façon ça doit être sous cette forme pour être passé à l'API 3D.
Ok, je comprends mieux alors.
:merci:
Tout dépend de ce que tu comptes faire de toute maniere....
Pour l'utilisation de l'OpenGL (ou de Direct3D, c'est pareil), le plus important est de comprendre comment fonctionnent les cartes graphiques aujourd'hui. les APIs existantes ne sont que des front-end à la state-machine du GPU. On place un certain nombre d'états, et on fait le rendu avec cet état là.
Du coup, il vaut parfois mieux faire un millier de multiplications en plus plutôt que de changer le pipeline pixel (c'est à dire le 'pixel program' ou 'pixel shader'). Un changement de pixel-shader peut aussi couter plus cher qu'un changement de texture.
Maintenant, si ton programme se charge aussi de la physique il devra faire une somme conséquente de calcul en amont, et il peut valoir le coup d'optimiser cette partie.
Pour exemple, le moteur sur lequel je travaille, passe les deux matrices de position à T et T+dt au geometry-shader, avec la position dans le temps entre ces deux "frames" physiques. Coté affichage, c'est donc le geometry shader qui s'occupe du blending entre les deux calculs.