RTTI: generische TObjectList erkennen

[Stevie]

Ich sehe bei deinem Win32 Ergebnis nix groß anders - deine Ergebnisse sind ~7% voneinander entfernt - außerdem ist Debug witzlos, um irgendwelche Performancemessungen durchzuführen.
Außerdem habe ich mir schon was dabei gedacht, meine sum Variable als Integer zu deklarieren (die ist nur dafür da, dass der Listenzugriff nicht wegoptimiert wird) und nicht Int64.
Eine Int64 Addition auf Win32 kostet nämlich genug, um in diesem Benchmark einen erheblichen Ausschlag zu geben.

Zitat von jaenicke:

Zitat von TiGü:

Richtig spannend wird's aber mit Release Win64, da muss ich mal in mich gehen und drüber nachdenken warum das sich so eklatant umkehrt.

Das ist bei mir nicht so. Und da der Getter selbst intern eine Vorprüfung macht und dann auch auf List[] zugreift, muss er auch immer langsamer sein, es sei denn das Inlining ginge irgendwo schief.

Du weißt aber schon, wie moderne CPUs funktionieren oder? Das Ergebnis der Überprüfung ist immer gleich - hallo Sprungvorhersage und hallo spekulative Ausführung.
Außer, dass der Delphi Compiler Schrott ist und oftmals viel zu viel register herumgemove produziert, ist es komplett egal, ob da die "Index in Range" Überprüfung ausgeführt wird.

Was außerdem öfters (mal wieder, weil der Compiler dämlich ist) Auswirkung hat, ist die Größe der Integer Variablen.
Bei einem direktzugriff auf ein Array mag der Compiler lieber die native Bittigkeit, wohingegen bei dem Getter Index ja vom Typ Integer ist.
Spiel mal mit dem Typen für i herum und schau, wie sich die Ergebnisse ändern.

[jaenicke]

Zitat von Stevie:

Du weißt aber schon, wie moderne CPUs funktionieren oder? Das Ergebnis der Überprüfung ist immer gleich - hallo Sprungvorhersage und hallo spekulative Ausführung.

Das ist schon klar, allerdings hätte ich gedacht, dass auch dann Code mit zusätzlicher Umleitung wie hier nur vergleichbar schnell (weil das Ergebnis schon da ist, obwohl es länger gebraucht hat), aber kaum schneller werden kann.

[Stevie]

Zitat von jaenicke:

Zitat von Stevie:

Du weißt aber schon, wie moderne CPUs funktionieren oder? Das Ergebnis der Überprüfung ist immer gleich - hallo Sprungvorhersage und hallo spekulative Ausführung.

Das ist schon klar, allerdings hätte ich gedacht, dass auch dann Code mit zusätzlicher Umleitung wie hier nur vergleichbar schnell (weil das Ergebnis schon da ist, obwohl es länger gebraucht hat), aber kaum schneller werden kann.

Ja, das fällt dann eher in diese Kategorie:

Zitat von jaenicke:

das Inlining ginge irgendwo schief.

Und das geht beim Delphi Compiler oftmals schief in dem Sinne, dass zu viele Instructions gebaut und oftmals Register durch die Gegend auf den Stack und herunter spazieren gefahren werden.

In diesem speziellen Fall kann es außerdem sein, dass man Microbenchmarkabweichungen zwischen den beiden Methoden haben kann, die die Unterschiede erklären. Hierzu empfehle ich dieses Video: https://www.youtube.com/watch?v=koTf7u0v41o
Es kommt außerdem oftmals auch auf die CPU an, denn die machen inzwischen so fancy sachen wie "move elimination", bei denen manchmal das vom Compiler generierte Rumgegurke einfach wegfliegt, da die CPU sieht, dass es nur Hin- und Hergeschiebe ist.