Moin!
Der Sinn liegt im Endeffekt wirklich darin, das der Code schneller abgearbeitet wird von den CPU's. Da kommt es dann darauf an, das nicht so viele Speicherzugriffe auf einmal auf unterschiedliche Stellen vorkommen, das Schleifen schnell abgearbeitet werden können ohne gross noch dort auf Speicher zu zu greifen, es kommt darauf an, das der Code bestenfalls parallel in den Pipelines des Prozessors verarbeitet werden kann, dass die Sprungvorhersage (Jump Prediction) des Prozessors eine hohe Trefferquote hat, das das Data Prefetching eine hohe Trefferquote hat und frühzeitig Daten holen kann, das es meist die gleichen Speicherstellen sind auf die zugegriffen wird, damit der Cache seine Wirkung hat, etc.
Deshalb die Optimierung. Es ändert sich doch vom reinen Code nix - es ist doch nix gross anders. Auch wenn intern mit 7 bis 1 gezählt wird greift er ordentlich auf das Array zu - dafür sorgt er schon. Ich könnte mir in deinem Fall auch sowas vorstellen, dass er einfach eine Adresse auf das erste Element im Array hat und bei jedem Zugriff entweder automatisch (lodsd) oder selber die Adresse erhöht um auf das nächste Element zu zu greifen mit dem nächsten Durchlauf. Und dadurch wird die Schleifenvariable nur noch für die Anzahl der Durchläufe benötigt und nicht mehr zum Zugriff. Genausogut ist es bei Assembler günstiger ein
dec ecx und ein jz @@ zu machen als ein Loop Befehl, etc. Das geht aber nun auch zu sehr ins Detail - zumindest kann ich nix sehen was gegen diese Optimierung spricht. Hier äussert sich das durch die falsche Zählweise, beim anderen male ist mal wieder eine Variable nicht debugbar, weil sie weg-optimiert wurde. Letzteres stört hier die wenigstens noch, aber bei einer Schleife haben alle Angst das der Compiler Müll macht (mein Gefühl hier nach den Postings).
MfG
Muetze1