De la rapidité du code

il ne faut pas etre totalement stupide non plus
<< pour multiplier un float par deux ne fonctionne pas non plus
c'est une grande nouvelle..

Il y a bien adequation entre le but (multiplier par deux)
et la methode (decaler les bits)
parce que l'operateur << utilisé sur des nombres entiers
est documenté comme décalant un nombre de bits sur la gauche
(representation binaire classique d'un nombre entier par un processeur usuel) et que ce décalage correspond effectivement a multiplier par la puissance correspondante de deux.

Vous pouvez decaler les bits d'une banane aussi
mais le resultat ne sera pas garanti..

LeGreg

Je sais tres bien que ca ne fonctionne pas avec les float, il n'y a pas de souci.

Musaran donnait les conditions a respecter pour pouvoir utiliser le decalage pour realiser des multiplications ou des divisions.

J'ai juste apporte une petite precision sur la remarque :

Citation:

---

les operateurs binaires operent sur les representations binaires des nombres. Point.

---

Sache que tout les type numerique (int, float, ...) quelque soit la representation (BCD, ...) ont une representation binaire mais sur tous les types le resultat n'est pas le meme, il faut en etre conscient, ce qui est apparement ton cas, mais pas forcement celui de tout le monde. Dans ce sens je troucve que le commentaire de Musaran est le bienvenu.

Je ne sais pas trop quoi dire sans me répéter...

Il n'y a pas grand mal à utiliser les décalages, il faut juste bien comprendre que ce sont des opérations sur les bits.
Et comme toutes les opération de bits, leur sens sur la valeur arithmétique représentée dépends justement de ce mode de représentation.

Dans cette façon de compter (dont j'ai oublié le nom), le décalage ne vaut pas multiplication/division:

Code:

---

1 2 3 4 5 6 7 8 9 10

Dec Bin 0 000 1 001 2 011 3 010 4 110 5 111 6 101 7 100

---

Le bit de poids fort peut être à gauche ou à droite. C'est le "boutisme" ou endianness de bits.
Si jamais j'ai une précision sur le sens standard de <</>> en C++, j'en parlerai ici.

C'est ça que je voulais dire.


Quant au const...
Je parle des constantes vraies, connues à la compilation, et pas des const extern, membres, ou paramètres de fonctions.

Quand le compilateur sait qu'une valeur ne varies pas, il peut l'incorporer directement dans le code, plutôt que de mettre une adresse pour aller la chercher.

Aussi, elles sont placées dans une page de données read-only, qui n'a pas besoin d'être ré-écrite sur disque en cas de swap de mémoire virtuelle.

Citation:

---

Envoyé par Musaran

Dans cette façon de compter (dont j'ai oublié le nom), le décalage ne vaut pas multiplication/division:

Code:

---

1 2 3 4 5 6 7 8 9 10

Dec Bin 0 000 1 001 2 011 3 010 4 110 5 111 6 101 7 100

---

---

Ca s'apelle le binaire reflechi.

La propriete principal est que lors d'une incrementation un seul bit est modifie. Il est surtout utilise en electronique logique car cette incrementation particuliere permet de compenser dans certains cas la difference de temps de reponse entre deux composants.

là , je viens de relire tout ce sujet et je vous dirais d'arreter avec vos considérations sur la représentation des nombres , ca a plus rien à voir !
surtout que lorsque , en C j'entends , on écrit tartenbouille<<n , eh ben tartenbouille est pris sous sa forme binaire évidement , et les ops << >> sont des ops dits binaires parce qu'ils agissent sur le binaire et un point c'est tout !!!
si vous voulez d'autres representations que celle ci d'ailleurs , il va faloir le coder vous meme ( ou ajouter une lib qqconque ) , donc toute cette discussion , ben , je la trouve inutile de ce point de vue !

Quand, pour optimiser, on remplace un opérateur arithmétique par un de bits, on dépend de la façon dont la machine utilises les bits pour représenter les nombres.

On n'a pas forçément le poids faible à droite (même au niveau des bits), et on n'est pas forçément en complément à 2.

Aller vite, c'est bien.
Être incompatible, c'est pas bien.

Je vais essayer de ne pas revenir là-dessus.

-utiliser des tables plûtot qu'une suite de comparaison.
Les fonctions isspace &co. utilisent le char comme indice pour trouver la réponse dans un tableau.

-utiliser des tables de pointeurs de fonction plutôt que des switch/case:

Code:

---

1 2 3 4 5 6

//Lent switch(n){ case 1: fonc1(); break; case 2: fonc2(); break; case 3: fonc3(); break; ...

---

Code:

---

1 2 3 4 5

//Rapide typedef void (*pf)(); //pointeur de fonction pf tabfonc[]= {fonc1, fonc2, fonc3}; ... tabfonc[n]();

---

Citation:

---

Envoyé par RegBas

surtout que lorsque , en C j'entends , on écrit tartenbouille<<n , eh ben tartenbouille est pris sous sa forme binaire évidement , et les ops << >> sont des ops dits binaires parce qu'ils agissent sur le binaire et un point c'est tout !!!!

---

Mais toutes ces representations sont des formes binaires

non , mais j'veux dire que , en C , la representation utilisée est toujours :
001
010
011
100
101
...
(je parle de BASE , ce ke je voulais dire , c ke qqsoit la representation , l'opération a<<1 DOIT correspondre à a*=2 !! le code de l'operateur est peut etre different suivant la rep , mais pas le résultat ! sinon , y'aurait pas de maths possibles ! )

Citation:

---

Envoyé par RegBas

ce ke je voulais dire , c ke qqsoit la representation , l'opération a<<1 DOIT correspondre à a*=2 !! le code de l'operateur est peut etre different suivant la rep , mais pas le résultat ! sinon , y'aurait pas de maths possibles ! )

---

Non l'operateur <<1 ou >>1 correspond a un decalage de bits, et non a une multiplcation/division par 2, la representation classique des entiers fait que ca correspond a une telle multiplication dans ce cas particulier, mais ce n'est pas une obligation. Essaie avec un float et tu verras que ce n'est pas le cas.

oui , c'est vrai pour les float ... et surement pour d'autres aussi , en fait ce ke j'ai dit n'est valable que pour tres peu de types et de rep ..

par contre en parlant d'optimisation , j'ai eu un ptit prob :
j'ai programmé une petite démo en opengl , et bien sur , en passant d'une machine à l'autre , il y a des écarts de vitesse hallucinant ( la faute aux drivers ? )
mais il y a aussi le fait de passer la souris au dessus de la fenetre de l'application et là , ca ralentit l'exécution de ma démo !
pourtant , ( j'ai utilisé glut ) , je ne me sers d'aucun call back sur la souris
à quoi c'est dû et comment résoudre le pb ?

Je suis desole, je suis bien incapable de resoudre ton probleme. Mais je te conseillerais de plutot poster cette question sur le forum opengl ou tu trouveras plus facilement des gens capables de t'aider.

Le standard ISO/ANSI définit très clairement qu'il ne définit aucune représentation standard des nombres.

Les chars dépendent des pages de codes. Ils peuvent être signés ou pas, et n'ont pas forcément 8 bits.
Les flottants ne sont pas forcément des IEEE-je-sais-plus-quoi.
Les entiers peuvent être autrement qu'en système de base et/ou complément à 2.

Pour être plus rapide et adaptatif, le C/C++ utilise ce que la machine sait faire.
Si un jour on invente des circuits logiques à trois états, << pourrait multiplier par 3.

Ne pas faire de supositions si ce n'est pas indispensable.

Caclculer tout ce qui peut etre calculé c'est pas indispensable. Ectrivez l'instruction :

Code:

---

a = b + (3000 * 200);

---

sera remplacé a la compilation par

Code:

---

1 2 3 4 5

mov eax, 600000 add b, eax   mov eax, b mov a, eax

---

(En version non optimisée par le compilateur)

Ce qui veut dire que le compilatuer calcul ce qui est constant. Verifiez de même si vous tapez :

Code:

---

const int c = 3000;

---

200 * 3000 sera egalement precalculé. Toutes les variables constantes donnent exactement le même effet que les #define puisque le compilateur les remplaces par leur valeur. Juste une difference, si je me souviens bien, les #define sont interpretes par le preprocesseur donc avant la compilation réele. Par contre il faut faire attention :

Code:

---

1 2	a = b * 300 * 200; //Attention a = 300 * b * 200; //Aussi ici

---

dans ces deux cas 300 * 200 ne seront pas (toujours) calculé a la compilation, du dans le premier cas au fait que la multiplication s'effectue de gauche a droite donc b * 300 est d'abord calculé et etant non constant, l'instruction resultat * 200 ne peut pas etre calculé a la compilation.


Optimisation aussi mais dans la manière dont vous concevez certaines choses. Vous avez vu que l'operateur >> permet des division par deux et que << permet des mulmtiplications par 2. Il faut en tenir compte mais en voyant un peu plus loin. Par exemple si vous programmez un jeu avec des cartes, prevoyez une largeur de carte de 256 par exemple pour que dans vos calculs vosu ppuissiez facilement integrer les decalages. Il y a des milliers de cas ou en choississant des bonnes limites ou un bon systeme de coordonnees, on peut simplifier (mais plus tard) les calculs.

Cet operateur << peut etre utilisé aussi dans des cas plus large. par ex :

Code:

---

1 2	a = b * 40; //Equ a : a = (b << 5) + ( b << 4);

---

Ca ce voit très bien si on decompose 40 en binaire : 40 = 000110000b ou on s'apercoit que 000110000 = (1 << 4) + (1 << 5). Donc on peut décomposer un facteur constant de la multiplication en une somme de puissance de 2. On peut decomposer en deux trois nombres voire plus sachant qu'une multiplication orend (a verifier) 40 cycles pour des 32 bits et une addition ou un decalage prend (a verifier aussi) seulement un cycle.


Faire un tableau de sin est vraiment bcp mieux que utiliser la fonction sin. Après tests, le calcul est au moins 1000 fois plus rapide. (je peux même vous passer le proghramme de tests si vous voulez verifier.)

Je comprends pas pourquoi << fonctionne pas pour les negatifs. Le compilateur est bien cencé savoir que le nombre est signé et remplacer par l'instruction assembleur corespondante :

Code:

---

1 2 3 4 5

int a; unsigned int b;   a >>= 4; b >>= 4;

---

devrait etre en toute logique remplacé par :

Code:

---

1 2	sar a, 4 shr a, 4

---

On trouve même dans la doc assembleur

Citation:

---

sar r/m, 1 : signed divided by 2
shr r/m, 1 : unsigned divide by 2

---

Donc je comprends pas. C'est tous les compilos qui ne permettent pas la division signée ? (Dès que je rentre chez moi je met le miens a l'epreuve)


Il existe encore d'autres optimisations encore mais plus sensibles.

Blustuff.

Je pense que tout le monde est d'accord pour dire que dans 95% des projets il vaut mieux passer du temps à faire un code lisible et à optimiser ses algorithmes.

Le temps passé à faire du code C C++( ou autre ) qui utilise au mieux les possibilités du compilateur n'est que rarement rentable... Celà dit pour des programmes tres diffusés et soumis à concurence, comme les jeux, ça peut valoir le coup... (si je ne m'abuse QUAKe comporte pas mal de code assembleur... et aucun malloc)

Mais je serais curieux de connaitre les temps de calcul (en unité arbitraire) de différentes opérations tel que

• - Affectation (=)
  - test == , <, <= , ...
  - ouveture d'un fichier.
  - ecriture/lecture/parcourt de fichier
  - Multiplication/division
  - etc.

tout ça en fonction du type évidemment...

J'ai déjà eu un document de ce type entre les mains mais je ne l'ai pas retrouvé par google...

Pour un développeur, la "performance" d'un logiciel doit être le cadet
de ses soucis dans la mesure où l'utilisateur constate aucune "lenteur"

C'est le travail d'un bon compilateur des faire toutes les optimisations
qu'il juge nécessaires selon le contexte

Ainsi le développeur peut se consacrer à ses vrais priorités :

faire du code correct, simple et lisible

et donc réaliser des applications plus élaborées

Citation:

---

Envoyé par Blustuff

Je comprends pas pourquoi << fonctionne pas pour les negatifs. Le compilateur est bien cencé savoir que le nombre est signé et remplacer par l'instruction assembleur corespondante :

Code:

---

1 2 3 4 5

int a; unsigned int b;   a >>= 4; b >>= 4;

---

devrait etre en toute logique remplacé par :

Code:

---

1 2	sar a, 4 shr a, 4

---

On trouve même dans la doc assembleur

Citation:

---

sar r/m, 1 : signed divided by 2
shr r/m, 1 : unsigned divide by 2

---

---

Si >> et << marche tres bien sur les nombres negatifs. Le but de ces instructions est de decaler les bits et non de faire une multiplication ou une division. Le fait que ca effectue sur des entiers non signe une multiplication ou une division est seulement une consequence de l'operation (du a la representation des entiers)

La premiere regle devrait etre de ne pas optimiser pour le plaisir mais par nessessitée.

commencer par faire un bench avant optimlisation, puis de profiler l'application pour trouver les quelques lignes de codes qui ont besoin d'etre optimisée...

Ensuite optimiser peut etre fait en tenant compte de la(des) plateforme(s)... c'est a dire en evaluant l'effet de chaque optimisation.

ex : les decalages de bits peuvent etre plus lent qu'une division par deux (cas du Pentium 4) le decalage de bit retrouvant une meilleur efficacité à partir de 4 (division par 16) environ

les inlines peuvent alourdir une fonction qui du coup depasser du cache instructions alors que sinon la fct en non-inline aurrait pu s'y trouver...

Les regles ne sont pas valables sur toutes les architectures, par contre le resultat en perte de lisibilité est souvent garanti...

Et pour le coup c'est la maintenance qui n'est pas optimisée...

Citation:

---

Envoyé par Gandalf

La premiere regle devrait etre de ne pas optimiser pour le plaisir mais par nessessitée.

commencer par faire un bench avant optimlisation, puis de profiler l'application pour trouver les quelques lignes de codes qui ont besoin d'etre optimisée...

Ensuite optimiser peut etre fait en tenant compte de la(des) plateforme(s)... c'est a dire en evaluant l'effet de chaque optimisation.

ex : les decalages de bits peuvent etre plus lent qu'une division par deux (cas du Pentium 4) le decalage de bit retrouvant une meilleur efficacité à partir de 4 (division par 16) environ

les inlines peuvent alourdir une fonction qui du coup depasser du cache instructions alors que sinon la fct en non-inline aurrait pu s'y trouver...

Les regles ne sont pas valables sur toutes les architectures, par contre le resultat en perte de lisibilité est souvent garanti...

Et pour le coup c'est la maintenance qui n'est pas optimisée...

---

En résumé : Laisser faire le compilo. Il s'occupera trés bien bien. S'il faut commencer à connaitre tout les processeurs et optimiser pour chacun d'eux tu n'es pas sorti de l'auberge. Le compilo s'occupera de faire les optimisations selon le proc. Commencer à faire : heu atta il est de combien mon cache de niveau 1 et 2. ma pipeline gére combien d'instructions en méme temps. heu, j ai une pipeline specifique pour les nombres à virgules....

franchement on n'a fait des compilo, des langages évolué exprés pour éviter de se faire chier avec ce genre de choses. Simplement pour ce fixer un objectif : son programme et son algo.

M'ettonerai bien moi que le pentium 4 fasse les divisions par deux plus vite que un "shr eax, 1" !!! (qui est "pariable" donc qui peut prendre qu'un demi cycle)

Citation:

---

Si >> et <<7 marche tres bien sur les nombres negatifs. Le but de ces instructions est de decaler les bits et non de faire une multiplication ou une division. Le fait que ca effectue sur des entiers non signe une multiplication ou une division est seulement une consequence de l'operation (du a la representation des entiers)

---

oui m'enfin ce que j'ai ecrit c'est que je vois pas pourquoi ca n'effectuerait pas une division par deux pour les nombres negatifs. (du au fait que les operations sur les decalage de bit marchent aussi bien en signé qu'en non signé et on tout les deux comme consequencecs la division par deux, que le nombre soit positif ou negatif. Seulement le C++ doit effectuer toujours une division signée que le noimbre soit signed ou unsigned)


Blustuff.