Discussion :

[LeGreg]

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

[gl]

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 :

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.

[Musaran]

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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.

[gl]

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

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

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.

[RegBas]

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 !

[Musaran]

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.

[Musaran]

-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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

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

[gl]

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

[RegBas]

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 ! )

[gl]

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.

[RegBas]

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 ?

[gl]

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.

[Musaran]

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.

[Blustuff]

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

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

a = b + (3000 * 200);

sera remplac� a la compilation par

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
int a;
unsigned int b;
 
a >>= 4;
b >>= 4;

devrait etre en toute logique remplac� par :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
sar  a, 4
shr a, 4

On trouve m�me dans la doc assembleur

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.

[goethe]

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...

[HRS]

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

[gl]

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
int a;
unsigned int b;
 
a >>= 4;
b >>= 4;

devrait etre en toute logique remplac� par :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
sar  a, 4
shr a, 4

On trouve m�me dans la doc assembleur

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)

[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...

[nyal]

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.

[Blustuff]

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)

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.