<span class="gmail_quote">On 6/17/06, <b class="gmail_sendername">Cyril Dupuit</b> <<a href="mailto:cyrildupuit@hotmail.com">cyrildupuit@hotmail.com</a>> wrote:</span><br>
<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Si ça t'intéresse, tu regarderas le code assembleur généré par la fonction<br>memcpy() (dans sos par exemple) sur IA32 et tu regarderas du coté de
<br>l'instruction «movb, movsw, movsd» (rep + movsX). Tu verras que le nombre<br>des accès mémoire est nettement réduit par ce couple d'instructions.</blockquote><div><br>
<span style="font-family: georgia;">Dans certains cas, il est en effet
possible que le compilateur ne sorte pas le code assembleur ultime,
encore qu'avec les optimisations adéquates, cela est quand même rare.
Je ne suis pas un très grand connaisseurs de GCC mais en fouillant un
peu dans les options, j'ai assez souvent trouvé une génération de code
assembleur qui me paraissait difficilement optimisable à la main.</span><br style="font-family: georgia;">
<span style="font-family: georgia;">Malgré tout, l'optimisation "à la
main" doit, dans certains cas, plus approprié (je pense notamment à du
code qui doit faire dialoguer le processeur avec un autre
périphérique). Le compilateur n'est pas forcément censé connaître
l'algorithme le plus efficace. Toujours est-il que malgré tout, je
reste convaincu que les efforts fournis à propos des optimisations du
code en assembleur devrait plutôt être faites du côté du compilateur
plutôt que du code lui-même.</span><br style="font-family: georgia;">
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Je suis tout de même d'accord pour dire que ce n'est que par souci de<br>performances.
</blockquote><div><br>
<span style="font-family: georgia;">Comme je dit toujours : pour que le programme fonctionne "vite" bah... il faut déjà qu'il fonctionne ^^</span><br>
</div></div>