vous pouvez toujours utiliser la méthode coué (je ne sais pas comment cela s'écrit), cela ne change rien à l'affaire, ni à l'indirection additionnelle, ni au résultât des mesures précédentes ;)
Version imprimable
vous pouvez toujours utiliser la méthode coué (je ne sais pas comment cela s'écrit), cela ne change rien à l'affaire, ni à l'indirection additionnelle, ni au résultât des mesures précédentes ;)
Avec ton code de la page précédente j'obtiens avec vs2010 : 8.346s pour le tableau dynamique et 8.346s pour le std::vector (ça fluctue un peu dans les deux cas à plus ou moins 10ms). C'est bizarre, comment peut-on obtenir le même temps alors qu'il y a pourtant une "'indirection supplémentaire au minimum deux fois plus chère." !?Citation:
Envoyé par bruno_pages
Citation:
for (n = size; n; n -= 1)
0119109D mov eax,540BE400h
011910A2 mov ecx,2
f(v1, 0, 0);
011910A7 xor ebx,ebx
011910A9 add eax,0FFFFFFFFh
011910AC adc ecx,0FFFFFFFFh
011910AF mov edx,eax
011910B1 or edx,ecx
011910B3 jne main+67h (11910A7h)
for (n = size; n; n -= 1)
011910B5 mov edx,dword ptr [esp+14h]
011910B9 mov dword ptr [esi],ebx
011910BB mov eax,540BE400h
011910C0 mov ecx,2
f(v2, 0, 0);
011910C5 xor ebx,ebx
011910C7 add eax,0FFFFFFFFh
011910CA adc ecx,0FFFFFFFFh
011910CD mov esi,eax
011910CF or esi,ecx
011910D1 jne main+85h (11910C5h)
l'indirection supplémentaire est là : 011910B9 mov dword ptr [esi],ebx
belle optimisation dans le code générée car elle est faite une fois pour les deux accès dans le vecteur (via recherche de code commun et détection de registres inchangés)
maintenant le programme ne fait pas que des accès, je n'ai jamais dis que l'utilisation d'un vector doublais le temps total d'exécution, seulement la partie liée au vector lui même, et si il n'y a une seule lecture traversant le vector à la recherche du 'vrai' vecteur interne c'est parce le code faisait 'suffisamment rien' pour laisser les registres disponibles.
[edit]on remarque aussi que les deux fonctions on été inliné[/edit]
Alors sans vouloir être méchant, entre toi, Stepanov et mes propres mesures, j'ai vite fait le choix, et mauvaise nouvelle, c'est pas toi qui gagne.Citation:
Envoyé par bruno_pages
Et ca fait pas mal de temps que lire l'assembleur lineairement n'apporte rien au vu des multiples pipeline internes.
l'exécution dans un proc est effectivement quelque chose de compliqué avec du parallélisme, sans compter ce qui peux se passer dans les caches, je me souviens avoir été ébahi par les prodiges des 68xxx il y a pas mal de temps déjà.Citation:
Envoyé par Joel F
a noté que j'ai dis une bêtise dans ma réponse précédente, si l'écriture est (heureusement) bien effectué les lectures liées au return sont passées à la trappe, les fonctions ayant été inliné le compilateur à pu voir que le résultât n'était pas utilisé
Je crois que vous pouvez quand même tomber d'accord sur le fait que le temps d'accès à un vecteur est supérieur ou égal à celui d'un tableau, mais jamais inférieur ;).