Discussion :

[Blustuff]

Quand j'ai commencé l'asm, je me suis rendu compte que le compilateur fesait tout mieux que moi. Mais après quelque experience, en fait, j'arrivais a ecrire certaine partie parfois plus de deux fois plus rapide d'execution que ce que pouvait faire le compilateur. L'optimisation devient parfois tellement complexe, qu'il est impossible de créer une methode systématique d'optimisation.

[LeGreg]

Quand j'ai commencé l'asm, je me suis rendu compte que le compilateur fesait tout mieux que moi. Mais après quelque experience, en fait, j'arrivais a ecrire certaine partie parfois plus de deux fois plus rapide d'execution que ce que pouvait faire le compilateur. L'optimisation devient parfois tellement complexe, qu'il est impossible de créer une methode systématique d'optimisation.

je ne parlais pas d'assembleur..

Tu sais l'algo ?? ces trucs qu'on apprend a l'ecole ? Plus d'autres trucs qu'on apprend sur le tas..

LeGreg

[LeGreg]

Quand j'ai commencé l'asm, je me suis rendu compte que le compilateur fesait tout mieux que moi. Mais après quelque experience, en fait, j'arrivais a ecrire certaine partie parfois plus de deux fois plus rapide d'execution que ce que pouvait faire le compilateur. L'optimisation devient parfois tellement complexe, qu'il est impossible de créer une methode systématique d'optimisation.

Il existe des methodes systematiques
l'optimisation ce n'est pas encore de la magie noire..

LeGreg

[Xiao-An]

Bonne analyse -> Bonne conception -> Bonne algorithme -> Bon codage = Rapidite du code

D'ailleurs n'oublions pas qu'un algorithme doit pouvoir s'appliquer a n'importe quel language de programmation.
Bien sur a chaque language ses performances dans un domaine d'application....

[Blustuff]

Je n'ai d'une part jamais dit qu'il n'y avait aucune methode systématique. J'ai simplement dit que beacoup d'optimisations du code au niveau de l'asm ne sont pas effectuées par le compilateur.

Je n'ai pas non plus dit qu'il ne fallait pas optimiser l'algorithme. Et le compilateur n'optimise pas les algorithmes. (du moins je ne considère pas ces optimisations comme optimisation d'algorithme)

Le sujet de l'algorithme a été abordé plus avant dans le sujet, et pour vous ressituer, c'est la première chose a faire. Je suis navré que vous n'ayez pas lu ce post en entier. Vous auriez pu y voir que je parle notement sur un exmple de l'optimisation d'algorithme.

[Blustuff]

enfin si, je l'ai dit :)) Mais c'est un peu ambigue, ce que je voulais dire, c'est que beacoup d'optimisations de code ne peuvent pas être faite de manière systématique. Juste considérent "les optimisations" et non pas "l'optimisation". Enfin je me suis mal exprimé. Mais je n'ai jamais fait d'école justement, c'est peut etre pour ca.

[Xiao-An]

A propos meme du codage en C++, une bonne connaissance de son compilateur permet d'optmiser le code qu'il compilera.

En effet, en tenant des regles de priorites, des formats des types, des classes de stockage, des regles de portee en fonction de son compilateur, on peut obtenir de bons resultats en performances.

[Metal Tom]

En parlant de carrence algorithmique, regardez le code que j'ai déjà vu dans un programme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
int i, j;
j=0;
for (i=0 ; i<MAX ; i++)
{
     A[i] = B[j];
     j++;
}

Si y'en a qui arrivent faire des choses comme ça, imaginez quand ça se complique un peu ...

[Argh!]

euh juste pour les copie par memcpy, je suis pas sur quel soit réelement plus rapide sur des petits tableau. je m'explique, kan on debug un memcpy, on trouve plein d'instruction de controle de partouts ki font des trucs ke jai pas cherché a comprendre, donc pour copier un tableaa de 50 char, je pense qu'il vaut mieux faire 50 = q'un memcpy. le mieux ce serait l'asm inline avec un bon

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
mov cx, 50/4
mov si, source
mov di, destination
rep movsd

mais c vrai ke c plus rapide a coder un memcpy et ya moins de chance de se planter.
si je me plante (c probable), merci de me prevenir.

[Metal Tom]

T'inquiète pas le compilateur il optimise bien du moment que ton algo est bien foutu. Dans le cas d'un memcpy si c'est pas bien optimisé je ne vois pas l'intérêt du C. Je crois que ça doit être une des premières instructions qui ont été optimisées à mort.

[Blustuff]

Pour copier un tableau de 550 éléments, il n'y aucunement besoin d'optimisation, une simple boucle for suffira. Pour conscision, memcopy sera amplement suffisant, même si les calculs précedant et succedant la copie sont nombreux, je pense que vous n'aurez jamais a resentir ces effets.

[Argh!]

blustuff, je suis tout a fait d'accord avec toi ca ne sert a rien, mais en fait on parle depuis le début d'optimisation qui n'ont jamais un effet super
(ki peut dire en regardant un programme tourner si les x *= 2^y ont été remplacé par x << y ?), la difference de vitesse est infime, mais elle est la comme même.
d'accord je pinaille mais c le sujet du forum : comment pinailler 3 heures pour gagner 3 millisecondes a l'execution. (mis a part kan on touche aux algorithmes...)

[Blustuff]

Non, non, il y a des optimisations serieuses. Je sais que parfois j'ai réussi a augmenter de plus du double la vitesse d'execution d'un programme. Mais là sur le dernier sujet, c'est une question visiblement superflue.

En fait il n'est pas inutile de jetter un coup d'oeil de temps en temps au code asm que crée le compilateur, pour donner une idée des optimisations qu'il peut faire, et de celles qu'il ne fait pas.

[Metal Tom]

(ki peut dire en regardant un programme tourner si les x *= 2^y ont été remplacé par x << y ?), la difference de vitesse est infime, mais elle est la comme même.

C'est testable. T'en fais 100.000.000 à la suite : tu verras facilement la différence. Surtout en utilisant une machine lente.

[Elrond]

...
(ki peut dire en regardant un programme tourner si les x *= 2^y ont été remplacé par x << y ?), la difference de vitesse est infime, mais elle est la comme même.
...

Un tel changement est sans interet...

Sauf s'il y en a une utilisation massive. Dans ce cas il peut etre utile et eventuellement avoir un effet visible par l'utilisateur.

C'est aussi ca qu'il faut voir. Chaque optimisation peut paraitre infime. Le tout est de savoir quel niveau d'utilisation en est faite, quelle quantite d'optimisations realiser, quel est le gain (temps d'execution/memoire) et la perte (temps d'execution/memoire/temps de developpement/maintenance) de chacune.

[Causa Sui]

Voici un petit résumé de ce qui précéde, fait pas quelqu'un (mais qui?) il y a quelque temps:

Voici quelques conseils pour améliorer la vitesse d'éxécution des programmes et les rendres plus "propres":
1. Bien qu'une légende veuille qu'on utilise des décalages explicitement plutot que de multiplications (dans le cas de multiplication par des multiples de 2); cela est tout a fait inutil avec la plupart des compilateurs, qui ont "l'inteligence" de faire la conversion. En plus les décalages rendent le code plus compliqué à lire, et ne fonctionnent qu'avec des entiers.
2. Utiliser de variables entières (de préférence int).
3. Ne pas prendre des variables trop importantes en taille sans que ce ne soit utile.
4. Quand vous utilisez des constantes, utilser "const", ce qui représente un gain de place et de vitesse.
5. Précalculer ce qui peut l'être. Si vous avez besoin de sinus dans un programme, utilisez un tableau avec les sinus des angles de 0 à 2pi radians (0 à 360 degrés).
6. Ne faites pas des optimisation si votre code est mauvais! Ca ne sert à rien! La base d'un bon code est un bon algorithme. C'est la qu'est le secret d'un code rapide... et puissant.

[ShootDX]

Entièrement d'accord avec le point 6. Je l'aurais même mis en première position.

[hegros]

Optimiser pour gagner 1sec je trouve que c'est du temps perdu surtout si ca doit prendre la journée

Il m'arrive souvent et c normal je pense quand j'ecris une ligne de code ou deux d'essayer de trouver la façon la plus efficace , lisible de le faire
Pourtant je suis sur que j'ai du passer outre et perdre 4-5nanosecondes

Biensur multiplié 1 seconde perdu par instruction surr 1 million l'instruction(rarement vu ça)ca fait beaucoup

Il faut vraiment se pencher sur le probleme de l'optimisation de 1 microseconde si l'application le demande(je pense au temps reel ou 1miiliseconde peut tout faire pencher)

Toutes les applications ne demande pas ce genre d'optimisation que je lis dans vos derniers posts

Développer un logiciel pour la gestion d'une pharmacie par exemple
La meuf qui est au comptoir si elle cherche le prix d'un medicament en ayant saisi le code barre( supposé une grosse bdd) Franchement le temps de reponse n'est pas une contrainte a l'application.Que cela mette 1secondes ou 3 secondes cela convient tout a fait au niveau et a l'environnent de l'utilisateur.

Enfin vous me comprenez....

PS:Je sais plus qui a dit qu'on lui avait demandé d'optimiser une boucle for pour un entretien d'embauche mais le mec devait etre sur les nerfs ce jour la

Mais c'est vrai que c'est interessant de voir cela dans la mesure ou on apprends des choses , on voit mieux ce qu'on programme enfin....

[Blustuff]

Lire tout c'est bien, mais il ne faut pas lire trop vite. L'entretiens, était, et ca a été dit par la personne concernée, pour savoir si on connaissait les optimisations faites par le compilateur. Ce test a pour but de savoir si la personne n'optimise pas pour rien. Quand vous ecrivez :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
n = (((y << 4) + (y << 3) + y) << 5) + x;
n += n <<2;

au lieu de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
n = (y * 800 + x) * 3;

Non seulement vous perdez du temps, mais, en plus, le compilateur fait quelque chose de plus rapide que vous. Le compîlateur, va faire un décalage de bits, et trois lea (pour ceux qui connaissent, lea peut être utilisé pour les multiplications par 2, 3, 4, 5, 8 et 9), ce qui est plus rapide. Et en plus vous auriez tort d'optimiser, parce que la solution la plus rapide, est effectivement de faire la multiplication par 800 explicitement en assembleur. Ce genre d'optimisation est une perte de temps inutile. (Cette expression à néanmoisn besoin d'être optimisée, mais que dans les cas, rarissimes ou vous codez une librairie graphique pour un mode graphique 800*600*24bits)


Comme dit dans le post, il faut bien savoir si le code a besoin d'être optimisé ou non. Ca ne remet pas en cause ce qui a été dit dans ce post, mais, ajoutez tout de même a la liste, tout en haut en premier : "Se demander si il est interessant d'optimiser le code". C'est une optimisation très importante, celle de votre temps. Et il ne s'agit pas là seulement de reagarder si c'est optimisable ou non, mais de savoir combien on doit optimiser. La première optimisation, qui ne figure pas dans la liste, est celle de l'algorithme. Elle est très rapide en général, quand les algorithmes sont simples. C'est moins visibles souvent en POO, mais quand vous n'êtes plus dans le cadre objet, mais que vous faites abstraction du reste, par exemple lorsque vous codez une fonction a part, c'est de réflechir comme si vous êtiez un processeur, et de vous dire, par exemple "Ah, la je fais deux fois la boucle pour rien". Passé cette optimisation qui se fait très bien par tous avec un peu d'experience, les autres optimisation, ne feront jamais, gagner beacoup plus de temps, a moins de vous en faire perdre beacoup a vous, donc, il faut que ca vaille le coups. Donc pour revenir a ce que j'ai dit, il est important de se demander jusqu'a quel point il faille optimiser.

[LeGreg]

Entièrement d'accord avec le point 6. Je l'aurais même mis en première position.

Oui il est surtout plein de vide son point 6:
"Si votre code est mauvais, jetez-le."

Je vais jouer l'avocat du diable et défendre les points un par un.

1- les decalages. Je les utilise tous les jours. Pire je stocke plusieurs flags dans une variable entière et j'y accède par des masks prédéfinis sur certains bits. Pourquoi faire x << n plutot que x * 2 ^n ? Tout simplement parce que x << n est toujours plus rapide et plus simple à écrire qu'une mise à la puissance, fut-elle de deux (d'ailleurs 2^n s'écrit de manière optimale 1 << n, donc on tourne autour du pot).
La raison pour laquelle on utilise les puissances de deux dans certains algorithmes (adressage de textures, fourier transform) est justement pour pouvoir utiliser ce genre d'astuce pour faire du code plus rapide. (que ce soit sur le processeur central ou gravé dans du silicium).

Évidemment, je ne parle pas du boulet qui va aller dans tout son code à la recherche des * 2 pour les remplacer par des << 1. Ca compte pour une "désoptimisation" ça.

2 - utilisez les types dont vous avez besoin. C'est quoi cette histoire de préférer les types entiers. on ne "préfère" pas utiliser tel ou tel type, on a "besoin" d'utiliser un type float plutot qu'un type int. Je ne sais pas qui a pondu cette règle.
Par ailleurs pour parler d'éfficacité il faut juste se rappeler que utiliser des types float sur un processeur moderne est aussi rapide que d'utiliser des int (multiplication addition, je ne parle pas de la multiplication par une puissance de deux dont on a parlé plus haut). il peut être couteux par contre de faire la conversion int/float et vice versa trop souvent par ligne de code...

3- Rien à redire au 3, sauf que je pense que personne ne pensera à prendre de la mémoire dont il n'a pas besoin.
Ah si certains débutants allouent 1 Go sur la pile. Mais c'est définitivement pas bien. (attention on vous regarde !)

4- Const n'a jamais représenté un gain de place et de vitesse.
A moins qu'il n'allie ça avec la règle 2, pour dire que toutes les constantes d'un programme sont des const int ?
Au moins utiliser un #define ne posera jamais de probleme de collision de nom au linkage et utiliser un enum permettrait au moins d'avoir le nom de la constante au deboguage (et la vérification des types)..
Pour ce qui est des const *, const & et const tartempion, il faut les utiliser mais certainement pas pour ces soi-disant gains de place et de vitesse.
C'est une béquille du programmeur, pas un outil d'optimisation !

5 - Il fut un temps ou précalculer les cosinus etait bien vu par toutes les machines. A l'heure actuelles certaines machines sont tellement compliquées que vouloir y appliquer des règles simples ne t'apporteront aucun benefice.
Par exemple les processeurs modernes ont un moyen de calculer les sinus et cosinus d'un angle en une seule instruction au cout d'un nombre consequent de cycles. Et lire depuis un tableau assez important en taille mais qui n'était pas dans le cache lors de la lecture entraine un cout en cycles encore plus important. Choisissez votre camp.

Mon conseil: limitez les calculs de cosinus au strict nécessaire et ne faites le coup du tableau précalculé que si vous avez montré par A+B que cette solution vous apportera le gain nécessaire sans perdre la précision dont vous avez besoin.

Et pour savoir si vous y gagnez réllement une seule solution:
profilez, profilez et profilez encore.

LeGreg