j'ai un tp ou pour mettre en évidence des pb de pagination mémoire et d'optimisation, je calcule la somme de tous les éléments d'un tableau a deux dimensions de deux manières : par colonne , puis par  ligne, et je mesure leur temps d'exécution
 
M=N=2048
 

 
 
lorsque je passe en O3, les deux algos sont prèsques identiques
 

 
 
quelle est donc l'optimisation utilisée qui peut produire un tel résultat ?    

fo comparer l assembleur

-O3 fait de l'inline à gogo

euh je pense pas que ça ait à voir...
 

mais bon tes mesures sont élagement soumises à des alea. fait des calcul qui te permettent d'avoir un temps d'exécution >=10sec

bah ouais, j'ai répondu un peu à coté de la plaque, j'avais pas vraiment lu, et je pensais que tu faisais plusieurs milleirs d'appels à ta fonction pour la tester, mais non, donc l'inline n'influe pas.  
 
1) prends le temps moyen sur un bon millier d'appel
2) fais en sorte que la durée de l'appel ne soit pas infinitésimale

c'est bon pour l'appel, les résultats sont normaux, et j'obtiens le même ordre de grandeur à chaque fois
 
je voudrais juste savoir quelle est l'optimisation de gcc qui rend les deux algos équivalents

 
Tout simplement le fait qu'il se rende compte que l'ordre d'evaluation n'influe pas. IMHO

cad ? c'est à dire qu'il fait justement le raisommement que les accès mémoires pénalisent, et que faire la somme dans l'autre sens fonctionne mieux ?
 
c'est quoi le nom de cette optimisation ( notemment dans les options de gcc ?)
 
sympa

up

 
J'en sais rien. Tu n'as qu'à les essayer une par une pour trouver c'est laquelle qui compte.

mais t'as essayé sur des vrais exemples qui durent plusieurs secondes ?!!!

j'aurais le déroulement de boucle, mais il est anormal qu'au premier jeu, somme 1 < somme 2 et qu'au deuxième somme 2 < somme 1.
 

 
Oui mais le deuxième c'est une difference de 3 ms seulement. Pas vraiment signification quoi.
 
Il suffit que après optim gcc génère le même code exactement et que le deuxième passage profite du fait qu'une partie du tableau est déjà en cache.

a mon avis il est moins gourmand de parcourir le tableau par colonne puis par ligne ke l inverse, il y a plus de calculs je pense

bah c'est pas que ça, de ligne à ligne, tu vas à l'encontre du système de ligne de la mémoire cache, et tu t'as moins chances de faire un cache hit dans le TLB...

oui, le fait de passer de ligne en ligne pour chaque colonne c est n est pas le mecanisme "normal"