Warum kann ich Int64 nicht in einer for-Schleife verwenden?

Der Delphi-Compiler unterstützt die Int64-Schleifenzähler bisher nicht.

Schleifenzähler in for loop müssen Ganzzahlen (oder kleiner) sein.
Dies ist eine Optimierung, um die Ausführung einer for -Schleife zu beschleunigen.

Intern verwendet Delphi immer ein Int32, weil dies auf x86 der schnellste verfügbare Datentyp ist.
Dies ist irgendwo tief im Handbuch dokumentiert, aber ich habe gerade keinen Link zur Hand.

Wenn Sie einen 64-Bit-Schleifenzähler verwenden müssen, verwenden Sie eine while..do - oder repeat..until -Schleife.

Selbst wenn der Compiler in einer Delphi 7 for-Schleife (Delphi 7 ???) "int64" zuließ, würde es wahrscheinlich die Iteration nicht vollständig durchlaufen volle Reichweite bis irgendwann nach dem Hitzetod der Sonne.

Warum können Sie nicht einfach eine "ganze Zahl" verwenden?

Wenn Sie müssen verwenden einen int64 Wert ... dann verwenden Sie einfach eine "while" -Schleife statt.

Problem gelöst:)

Warum ein Int64 in einer For-Schleife verwenden?

Einfach zu beantworten:

• Es gibt keine Notwendigkeit, viele Iterationen zu machen, um ein Int64 zu benötigen, machen Sie einfach eine Schleife von 5E9 bis 5E9 + 2 (insgesamt drei Iterationen).
• Es ist nur so, dass Werte bei der Iteration größer sind als das, was Int32 enthalten kann

Ein Beispiel:

Dieser Code würde überhaupt keine Zeit brauchen, es ist nur so, dass der Indexwert weit über 32 Bit liegen muss.

Die Lösung besteht darin, dies mit einer while-Schleife zu tun:

Warum also der Compiler die foor-Schleife nicht kompiliert, sehe ich keinen wirklichen Grund ... jede for-Schleife kann automatisch in eine while-Schleife übersetzt werden ... und der Pre-Compiler könnte das vor dem Compiler tun (wie andere Optimierungen) das ist getan) ... der einzige Grund, den ich sehe, sind die faulen Leute, die den Compiler erstellen, der nicht darüber nachdachte.

Wenn für "optimiert" und daher nur 32-Bit-Index verwendet werden kann, wenn Code versucht, einen 64-Bit-Index zu verwenden, kann er nicht so optimiert werden. Warum also nicht den Pre-Compiler-Optimierer für uns ändern? .. es gibt nur ein schlechtes Bild für Programmierer !!!

Ich möchte niemanden ungern machen ...

Ich sage nur etwas Offensichtliches ...

Übrigens starten nicht alle Leute eine foor-Schleife auf Null (oder eins) -Werten ... manchmal ist es notwendig, sie auf wirklich großen Werten zu starten.

Es wird immer gesagt, dass, wenn Sie eine bestimmte Anzahl von Malen tun müssen, Sie am besten für die for-Schleife anstelle der while-Schleife verwenden ...

Auch ich kann etwas sagen ... solche zwei Versionen, die for-Schleife und die while-Schleife, die Inc (Index) verwenden, sind gleich schnell ... aber wenn Sie den while-loop-Schritt als Index: = Index setzen +1; es ist langsamer; Es ist wirklich nicht langsamer, weil der Pre-Compiler-Optimierer das sieht und stattdessen Inc (Index) verwendet ... Sie können sehen, ob der nächste kauft:

Der Optimierer kann sehen, dass eine Variable ihren Wert nicht ändert, also kann sie in eine Konstante umgewandelt werden, dann auf der Inkrement-Zuweisung, wenn eine Konstante (Variable: = Variable + Konstante) hinzugefügt wird, wird sie auf Inc (Variable, constant) und in dem Fall, dass es eine solche Konstante 1 ist, wird es auch auf Inc (Variable) optimiert ... und solche Optimierungen in der Computersprache auf niedriger Ebene sind sehr auffällig ...

In der Low-Level-Computersprache: Eine normale Addition (Variable: = Variable1 + Variable2) impliziert zwei Speicherlesevorgänge plus eine Summe plus einen Speicher schreiben ... viel Arbeit Aber wenn a (Variable: = Variable + andere Variable) ist, kann die Variable innerhalb des Prozessor-Cache optimiert werden. Auch wenn es eine (Variable: = Variable1 + Konstante) ist, kann sie auch optimiert werden, indem sie konstant auf dem Prozessor-Cache gehalten wird Und wenn es (Variable: = Variable + Konstante) ist, werden beide im Prozessor-Cache zwischengespeichert, also im Vergleich zu anderen Optionen sehr schnell, es wird kein Zugriff auf RAM benötigt.

Auf diese Weise macht der Pre-Compiler-Optimierer eine weitere wichtige Optimierung ... For-Schleifen-Indexvariablen werden als Prozessorregister gespeichert ... viel schneller als der Prozessor-Cache ...

Die meisten Mother-Prozessoren machen auch eine extra Optimierung (auf Hardware-Ebene, im Prozessor) ... einige Cache-Bereiche (32-Bit-Variablen für uns), die intensiv genutzt werden, werden als spezielle Register gespeichert, um den Zugriff zu erleichtern ... und solche for-loop / while-loop-indices sind eine davon ... aber wie ich schon sagte ... die meisten Mutter-AMD-Prozessoren (diejenigen, die die MP-Technologie verwenden, tun das) ... ich kenne noch keine Intel, die das tun !!! solche Optimierung ist relevanter, wenn Multi-Core und Super-Computing ... also vielleicht ist das der Grund, warum AMD es hat und Intel nicht !!!

Ich möchte nur ein "warum" zeigen, es gibt viel mehr ... ein anderes könnte so einfach sein, wie der Index auf einem Int64 Feldtyp der Datenbank gespeichert wird, usw. ... es gibt viele Gründe, warum ich kenne und viel mehr wusste ich noch nicht ...

Ich hoffe, dass dies hilft, die Notwendigkeit zu verstehen, eine Schleife auf einem Int64-Index zu machen und auch, wie man es macht, ohne die Geschwindigkeit zu verlieren, indem man die Schleife korrekt in eine while-Schleife konvertiert.

Hinweis: Achten Sie bei x86-Kompilierungen (nicht bei der 64-Bit-Kompilierung) darauf, dass Int64 intern als zwei Int32-Teile verwaltet wird ... und beim Ändern von Werten gibt es einen zusätzlichen Code, bei Adds und Subs ist es sehr niedrig, aber eingeschaltet Multiplikationen oder Divisionen solche Extra ist spürbar ... aber wenn Sie Int64 wirklich brauchen Sie brauchen es, also was sonst noch zu tun ... und stellen Sie sich vor, wenn Sie float oder double, etc ... benötigen !!!