Discussion :

[LeGreg]

memcpy fait une copy bit a bit, or la representation binaire de 3.760000 en char* ou en float n'a RIEN a voir. Yabo, est-ce que tu as ne serait-ce qu'essaye d'afficher le resultat de ton float via "cout" apres avoir fait une telle copie pour voir ce que ca donne...

A mon avis c'est un troll ca peut pas etre aussi gros..

LeGreg

[Xiao-An]

Et le conseil le plus utile :

Avant de programmer, ecrire l'algorithme en utilisant une analyse methodologique appropriee !

Mais la on sort du forum C++...

[rolkA]

J'ai quand même une petite remarque: en dehors de la recherche du meilleur algorithme et de remarques évidentes comme éviter l'écriture sur disque, etc., il est inutile de se creuser la tête puisque les meilleurs compilateurs font tout tout seul (inline, déroulage de boucles, optimisation des opérations, etc...).

[LeGreg]

J'ai quand même une petite remarque: en dehors de la recherche du meilleur algorithme et de remarques évidentes comme éviter l'écriture sur disque, etc., il est inutile de se creuser la tête puisque les meilleurs compilateurs font tout tout seul (inline, déroulage de boucles, optimisation des opérations, etc...).

malheureusement non un compilateur ne fait pas tout
et un programme mal écrit restera lent meme avec un bon compilateur.

Evidemment tous les programmes n'ont a priori pas besoin de cette rapidité, de ce coté la je suis bien d'accord.

LeGreg

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