En faisant un peu de raytracing cet été, je me suis rendu compte qu'il y avait une manière plus rapide pour effectuer des calculs avec les vecteurs, je n'ai pas pris le temps de regarder comment ça fonctionne dans irrlicht, donc je fait appel à vous pour savoir si ça vaut le coup que j'essaye de l'implémenté, ou si c'est pas possible.
Actuellement dans irrlicht:
il me semble que dans le return il y a une allocation de memoire inutile, à moins que ça serve à autre chose dont je n'ai pas conscience ?
Ce que j'ai fait ressemble à ça:
Qu'en pensez-vous ?
Hors ligne
A mon avis c'est pareil, l'opérateur est bien obligé d'allouer un vecteur pour le retour et il n'est pas copié lors du return. Dans le tien, tu instancie également et tu cast mais je ne vois pas de différences après compile.
Ma foie je peux me tromper je ne suis pas métaprogrammeur.
Hors ligne
Oui, c'est plus rapide, d'ailleurs j'ai fait un test n'étant pas convaincu à la base, et pour 10.000.000 d'additions de vecteurs, je passe de 250 ms à 205 ms avec le deuxième type de définition.
Donc, oui, un gain de 20% chez moi, c'est pas négligeable
Hors ligne
Merci pour le test Tmyke
TUpac, je ne pourrai pas te dire ce qu'il se passe en mémoire, mais j'imagine qu'il doit y avoir allocation dans le premier cas,
sinon pour le deuxième cas, exemple:
return (char){1};
moi je traduit ça par: return 00000001; (en octet)
Donc je ne voit pas d'allocation, mais là je parle que par déduction, je ne suis pas sûre
Hors ligne
Certainement oui. C'est de la métaprog ça, mais la je suis une bille
Ce serait sympas que quelqu'un nous éclaire un peut. J'vais potasser un peu loulou.developpez pour voir..
En tout cas c'est à généraliser à tout les types possibles.
De mon coté j'ai un peu regardé le code concernant les vbo d'aip et tout est normal en tout cas pour les statics.
Il y'a juste un glBufferSubData() qui ne prend quasi pas de ressources.
Quesque ça veut dire?, c'est l'nsemble qui est mal codé ?
Du coup ca se pourrait bien qu'on ai qu'a recoder à coup d'inlining et de métaprog pour le booster.... :espoir:
Qu'en pensez-vous, vous avez une idée?
Dernière modification par TUpac (27-01-2011 00:19:53)
Hors ligne
Ouhou pas si vite, il y a peut être des raisons que l'on ignore, perso je pars plutôt pessimiste pour pas être déçu. et je pense qu'il ne faut pas crier victoire avant qu'un mod ai été testé par un certains nombres de membres, afin d'être sûre qu'il n'y ai pas de bug et qu'il soit bien fonctionnel.
De mon coté j'ai un peu regardé le code concernant les vbo d'aip et tout est normal en tout cas pour les statics.
ça veut dire quoi tout est normal ?
Hors ligne
D'après le forums anglophones, j'avais compris que les vbo étaient utlisés mais que les données étaient retransférées à chaque rendu. C'est faux ! en static, ils ne sont remplis (les vbo) qu'une fois.
Je n'ai pas testé beaucoup mais il est clair que malgré les vbo, irrlicht reste plus lent que les autres.
Hors ligne
la différence majeur entre le cas 1 et 2, c'est que dans le premier on passe par un constructeur, mais pas dans le second, en effect, pour faire simple on peut également interpreter d'une structure ou d'une class comme un tableau et y acceder comme t'elle.
struct tempory { char *filename; int size; };
tempory tmp;
nous pouvons y acceder par deux manière
la traditionner tmp.variable;
mais aussi tmp[i], où i est l'emplacement de la variable, donc ici 0 = filename et 1 = size.
sa reviens donc a faire:
char data[] = { a, b, c };
plutot que
char *data = new char[3],
data[0] = a;
data[1] = b;
data[2] = c;
cert concretement cela en revien au même mais le nombre d'intruction est différent
c'est un peut comme if(){} else{} et la forme "contracter" condition ? true : false;
edit: syntaxe
edit 2: non TUpac, l'inline est a éviter, même si cela peut représenter un gain par fois conséquant, ( entre 0 et 15fps ), je te le déconseil si tu souhaite faire du multithreading, sa fous tout en l'aire
a la rigeur essaye d'optimiser avec register, et un peut d'asm
edit3: if ...
Dernière modification par Magun (27-01-2011 10:21:08)
Hors ligne
Ok je comprend mieu merci Magun. Donc c'est bien de la métaprog, les données sont connus à la compilation et on se passe de constructeur.
Magun :
je te le déconseil si tu souhaite faire du multithreading, sa fous tout en l'aire
J'aimerai bien savoir pourquoi et du coup, dans quel cas précis c'est à proscrire. Car il faut vraiment l'utiliser un max.
ps: Ogre utilise l'inline pour les template vector par example.
Dernière modification par TUpac (27-01-2011 10:52:59)
Hors ligne
je parlais des inline
le soucis avec inline ses qu'il inject plus ou moin le code dans le code, au moment de la compilation, et il arrive qu'il enchevetre les instructions a cause du multithreading, où alors il peut confrondre les variables a modifier
par exemple:
inlne void free_memory(void *mem){ delete mem; mem = 0; }
l'apelle de cette fonction n'est pas standar, c'est a dire qu'au lieux de faire apelle a la fonction il va injecter sont code au moment de la compilation
on se retrouve donc avec
au lieux d'un apelle 'classic'
se pendant on peut tout a fait se retrouver avec
a cause du multithreading, même si ça na pas été coder comme ça, enfin c'est asser complex et pas facil à résumer en 10 ligne, sachant qu'une codition pour savoir si mem est allouer ou non, ne corrige pas toujours le probleme, bref, regarde du coter des thread-safe, rare sont les examples et applications, car il faut être sur cas t'elle moment on écris pas sur t'elle variable avec 2 thread .... etc
Dernière modification par Magun (27-01-2011 11:01:46)
Hors ligne
Magun :
sa reviens donc a faire:
char data[] = { a, b, c };
plutot que
char *data = new char[3],
data[0] = a;
data[1] = b;
data[2] = c;
Je ne pense vraiment pas, car char data[] va réservé 3 cases en ram il me semble, alors que (char){a, b ,c} j'ai plutôt l'impression que c'est le cpu qui va s'occuper de traduire la valeur en octet.
cela dit, je ne fait que supposer. aucune certitude.
Hors ligne
La différence c'est que c'est optimisé par le compilo car la valeur est connue avant l’exécution.
Comment? je n'en sais rien.
Hors ligne
l'exemple est pas très exacte mais j'ai comprit, en général quand je dit quelque chose c'est que je le sais, je fait rarement des spéculations
bref, quand tu fait { a, b, c } sa aloue forcement un tableau de 3 uniter, si tu rajoute (typename T) cela fait un cast en gros tu spésifie que le tableau alouer est de t'elle type donc un vector3d
il n'y a alors pas beusoin de passe par un constructeur les données sont alouer via le tableau ...
edit: c'est comme quand tu fait une chaine de caractère
char[] = "blablabla" et char[] = { 'b', 'l', 'a', 'b', 'l', 'a' } est équivalent tout comme (char*){ 'b', 'l', 'a', 'b', 'l', 'a' }
edit2: @Gehogor (en dessous) c'est se que j'explique depuis le debut, ce pendant même étant une pseudo allaction comme tu dit, ce n'est pas dangeureux si l'ont est sur de l'emploie, dans se cas ici il n'y a pas de probleme envisageable, après pour se qui est de l'emploie ou non c'est personnel
Dernière modification par Magun (27-01-2011 13:27:11)
Hors ligne
Coucou très cher vous, moi ce que j'en pense:
En C++, un objet, n'est rien d'autre qu'une structure (en terme de stockage mémoire) .
Donc, le vector3d d'Irrlicht, ses membres publics doivent être accessibles en faisant vector3d[0] (qui correspond à X), et ainsi de suite (comme si on considérait que vector3d est une structure en fait.
Donc dans ce cas là, pour moi, une "structure" avec les 3 champs va être créée (initialisation avec une liste de valeur), puis castée en vector3d pour être compatible avec la valeur de retour... C'est à mon sens :
- dégueulasse : on exploite le fait qu'une classe est "comme une structure" en C++
- dangereux : un objet doit être construit via un constructeur, et non via une "pseudo allocation via structure"
Soit je préfèrerai la propreté a une tentative d'optimisation. De plus, j'ai vérifié sur les sources de Qt, qui sont des fous, des pro et il font sans le cast de structure.
Et hop, bon appétit à vous si ce n'est déjà fait.
Dernière modification par Gehogor (27-01-2011 13:27:46)
Hors ligne
Peut être une nouvelle preuve que microsoft c'est de la ù$ù*$ : J'ai fait le test des deux opérateurs sur 100000000 additions avec GCC et surprise même temps de calcul pour les deux ......
Hors ligne
ouai bien vu gehogor, dans mon raytracer j'ai utilisé des structures
Donc moi je n'ai pas eu de soucis. tu pense que ça serait pas propre avec des class ? dommage
ps Magun: ok, mais essai d'être plus précis la prochaine fois sinon on comprend pas ce que tu veut dire
Hors ligne
Options | Liens officiels | Caractéristiques | Statistiques | Communauté |
---|---|---|---|---|
Corrections |
|
xhtml 1.0 css 2.1 Propulsé par FluxBB Traduit par FluxBB.fr |
882 membres 1429 sujets 11119 messages |
Dernier membre inscrit: LiseBuisson96 20 invités en ligne Aucun membre connecté RSS Feed |