Oui, c'est vrai, j'ai confondu les deux versions.
Sigma a donc désoptimisé du code:)
Mais, bon, en tout cas je comprends pas cette optimisation, je suis d'accord qu'il est préférable de tomber sur un adresse "ronde" puisque les segments mis en cache par le processeur commencent à des addresses multiples de 2^n, ainsi, toute la boucle peut s'effectuer sans swap de segments de cache. Mais moi j'aurai plus vu un jump inconditionnel vers 1001CB00. Les Nop consomment du temps processeur, donc théoriquement un jump irait plus vite, et s'il est inconditionnel, il n'y aurait pas besoin de vider les pipelines... Mais bon, j'écris pas des codecs divx, moi (sigma non plus, c'est pour ça qu'ils ont pas perçu cette subtilité:).
Bon, bah, la prochaine fois je regarderai un peu mieux avant de poster un commentaire (et je décuverai de la veille aussi :)
[^] # Re: nop, nop, nop, et re-nop
Posté par jgreg . En réponse à la dépêche Arrêt du développement de XviD. Évalué à 7.
Oui, c'est vrai, j'ai confondu les deux versions.
Sigma a donc désoptimisé du code:)
Mais, bon, en tout cas je comprends pas cette optimisation, je suis d'accord qu'il est préférable de tomber sur un adresse "ronde" puisque les segments mis en cache par le processeur commencent à des addresses multiples de 2^n, ainsi, toute la boucle peut s'effectuer sans swap de segments de cache. Mais moi j'aurai plus vu un jump inconditionnel vers 1001CB00. Les Nop consomment du temps processeur, donc théoriquement un jump irait plus vite, et s'il est inconditionnel, il n'y aurait pas besoin de vider les pipelines... Mais bon, j'écris pas des codecs divx, moi (sigma non plus, c'est pour ça qu'ils ont pas perçu cette subtilité:).
Bon, bah, la prochaine fois je regarderai un peu mieux avant de poster un commentaire (et je décuverai de la veille aussi :)