Je pense que de nos jours le compilateur se charge d'optimiser ça tout seul.
Mais sinon tu peux utiliser la multiplication plutôt que la division quand c'est possible, par exemple pour une comparaison.

caelacanthe,

Bonne question. Il fut une epoque ou si var3 est une puissance de 2 alors le decalage de bits etait plus rapide. De nos jours, ca depend de ton architecture. Si tu travailles sur un processeur x86, il n'y a pas de difference. Sur des architectures exotique (genre ARM), ca peut faire une difference en fonction de quel type de ARM on parle.

Par exemple, sur le arm7 que l'on trouve sur GBA, le processeur ne sait pas faire /. La division est faite par un appel de fonction au niveau du compilateur. Sur le arm9 que l'on trouve dans les nintendo ds, la division est traiter par un co processeur de calcul, et ca prends un peu de temps de l'acceder. (Mais beaucoup moins que sur l'arm7). Pour les arms moderne, aucune idee.

Tu peux aussi améliorer le perf en passant tes signed en unsigned si tu es sûr qu'ils sont positif ou nuls (et qu'ils sont dividende). Le cast en unsigned est moins couteux (pas couteux ?) que diviser un signed.

vraiment? c'est plus couteux de diviser un signed qu'un unsigned? Materiellement un complement a deux ca coute pas cher. Quel architecture presentait/presente ce comportement?

"De nos jours, ca depend de ton architecture. Si tu travailles sur un processeur x86, il n'y a pas de difference. "

tu parles bien d'une puissance de 2 dans les deux cas? si on divise par une puissance de 2, comparativement à un décalage de bits avec l'exposant de cette puissance?

car j'ai un programme dans lequel un endroit du code fait deux divisions par des valeurs fixes, et la vitesse d'exécution a notablement augmenté quand j'ai remplacé ces valeurs fixes par de proches homologues puissance de 2, et les divisions par des décalages de bits. c'était le comportement attendu, mais je n'ai pas regardé si remplacer ce décalage de bits par une division avec la puissance faisait une différence. c'était sur un pentium 3.

"Mais sinon tu peux utiliser la multiplication plutôt que la division quand c'est possible, par exemple pour une comparaison."

oui, c'est souvent utilisé en jeu vidéo dans les comparaisons de distance... au lieu de faire une racine, ils utilisent le carré de l'autre opérande. plutôt astucieux.

sinon, je faisais les tests exclusivement sur de l'architecture x86.

godrik >> http://embeddedgurus.com/stack-overflow/2009/07/efficient-c-tips-10-use-unsigned-integers/

Je n'arrive pas à retrouver plus précis par contre désolé

caelacanthe, etrange. Je me rappelle avoir lu des benchmarks sur des P4 qui montrait que les decalage de bits etait plus lent que des divisions. C'etait pour une raison d'architecture des processeurs obscures...

paulop, je vois l'idee. Des processeurs super cheap probablement

"Je me rappelle avoir lu des benchmarks sur des P4 qui montrait que les decalage de bits etait plus lent que des divisions. C'etait pour une raison d'architecture des processeurs obscures..."

donc ça change entre chaque processeur? ça promet...

tu te rappelle de la différence de vitesse? si c'était vraiment flagrant, de l'ordre de deux fois plus lent, ou juste "légèrement" plus lent?

bon, à la base, je pensais en rester sur l'optimisation par décalage de bits, une majorité de processeurs doivent le faire plus rapidement.

http://code.google.com/p/corkami/wiki/x86oddities

Les bizarreries de x86. J'avoue je ne comprend pas tout ^^

caelacanthe, si tu fais du x86, laisse le compilo faire

je fais uniquement du x86, et mon compilateur est le compilateur intégré de code::blocks... minGW, je crois.

par "le laisser faire", tu veux dire... il remplacerait les divisions en puissance de 2 par des décalages de bits ou inversement?

"par "le laisser faire", tu veux dire... il remplacerait les divisions en puissance de 2 par des décalages de bits ou inversement? "

Nan, je veux dire que sauf si tu es sur et certain d'avoir une puissance de 2, laisser le compilateur se debrouiller est certainement une bonne chose.

"Je fais uniquement du x86, et mon compilateur est le compilateur intégré de code::blocks... minGW, je crois. "

minGW... Ca peut expliquer des choses... Tu as un exemple de code minimal qui presente ce comportement? Tu as essayer avec un autre compilateur?
En passant, c'est quelle version de mingw?

"Nan, je veux dire que sauf si tu es sur et certain d'avoir une puissance de 2, laisser le compilateur se debrouiller est certainement une bonne chose."

c'est ce que je fais, alors, pour les divisions avec des nombres inconnus, je laisse la division telle quelle.

"En passant, c'est quelle version de mingw?"

la version de minGW embarquée avec code::blocks version dite 10.05, la dernière je crois. je n'ai pas pris la peine de mettre minGW à jour car sinon, les exécutables de certains de mes projets dépendent de DLL que les gens n'ont pas.

"Tu as un exemple de code minimal qui presente ce comportement?"

c'est que je n'ai pas de comportement intriguant à proprement parler, je disais que j'ai gagné en vitesse d'exécution en remplacant des divisions par 16000 et 1000 par des divisions par 16384 et 1024, qui ont été au passage remplacées par des décalage de bits. une division par un nombre qui n'est pas une puissance de 2 prend nativement plus de temps qu'une division par une puissance de 2.

" la version de minGW embarquée avec code::blocks version dite 10.05, la dernière je crois. je n'ai pas pris la peine de mettre minGW à jour car sinon, les exécutables de certains de mes projets dépendent de DLL que les gens n'ont pas."

La version (stable) la plus recente de gcc c'est 4.6.. c'est loin de 10.05... quelqu'un sait de quel gcc on parle ? (C'est important parceque les perfs de gcc ont grandement augmenter depuis 4.1.2)

" c'est que je n'ai pas de comportement intriguant à proprement parler, je disais que j'ai gagné en vitesse d'exécution en remplacant des divisions par 16000 et 1000 par des divisions par 16384 et 1024, qui ont été au passage remplacées par des décalage de bits. une division par un nombre qui n'est pas une puissance de 2 prend nativement plus de temps qu'une division par une puissance de 2. "

tell me more! tell me more! Did you get very far?

Tu en fais quoi de ce nombre apres? Tu indexes qqch avec? ou tu calcul plein de truc chelou avec?

"La version (stable) la plus recente de gcc c'est 4.6.. c'est loin de 10.05... "

mais code::blocks est bien, lui, en 10.05, ils ont pompé la nomenclature de ubuntu.

sinon, gcc est en 4.5.2, apparament (merci --version ).

concernant les performances... je n'ai pas réalisé de"vrai" benchmark, il s'agit d'un de mes projets de jeu qui met en jeu un nombre assez important de sprites... les sprites en dehors de l'écran ne sont pas affichés, mais leur position est quand même convertie en coordonnées 2d, pour chacun d'entre eux.

cette fonction de conversion de coordonnées est tellement utilisée qu'elle peut représenter un véritable goulot d'étranglement des performances si elle est faite n'importe comment.

quand tous les sprites en question, il doit y en avoir environ soixante-mille, sont en dehors de l'écran, mon netbook plafonnait à ~45 FPS, et après l'optimisation des divisions, il atteignait presque les soixante. chaque affichage (rejeté) d'un sprite fait appel à la fonction de conversion des coordonnées, elle est donc appelée soixante-mille fois par frame.

33% de performances en plus... ça fait une différence, mais je le redis, ce n'est pas non plus un benchmark fait dans les règles.

NdM: yad-de-lbp2 prends un kick pour pub abusive. Son message a ete supprime.

On dirait un logger qui s'exprime...

je promet, je n'ai pas ecrit un bot de moderation

C'est une idée ça tient

On parlait au debut du blabla de la consommation energetique de google.

La partie interessante (avec edit de contexte):

"The [2009] article [...] said a single Google search generates the same amount of carbon as boiling a kettle of water for tea. Google defended itself [...] that most Google searches produce 35 times less carbon than the report suggested."

http://news.yahoo.com/google-reveals-energy-show-search-green-160247037.html