Geschwindigkeitsunterschiede Apple Sillicon / Intel Win32 / Win64

[Stevie]

Zitat von jaenicke:

Zitat von Stevie:

Zur Eingangsfrage und den um mehr als Faktor 10 unterscheidenden Ergebnissen kann ich nur sagen: da ist ziemlich sicher irgendwo ein Messfehler oder eine nicht vergleichbare Compilerkonfiguration.

Das hat ja Matthias schon beantwortet.

Hat er? Ich kann diese Messergebnisse mit Int64 unter Win32 nicht reproduzieren, daher liegt es entweder an den Compilersettings des TE oder seiner Hardware.
Der Overhead von Int64 unter 32bit ist messbar aber keineswegs auch nur annäherend in Bereich x10

Zitat von areyoudoneyet:

Gut C ist halt einfach schnell, dachte allerdings aus Erzählungen das Delphi nicht arg weit dahinter ist.

Das hier hatte auch noch niemand kommentiert - gcc optimiert hier schon zur Compiletime und erkennt, dass es eine Schleife mit konstanter Anzahl an Durchläufen ist und generiert einfach schon den Wert für sum, so dass zur Laufzeit überhaupt keine Schleife passiert.
Der Messwert bei swift sieht auch aus, als ob da etwas ähnliches passiert.

[jaenicke]

Zitat von Stevie:

Der Overhead von Int64 unter 32bit ist messbar aber keineswegs auch nur annäherend in Bereich x10

Bei mir liegt der Unterschied bei etwa Faktor 7. Int64 braucht wie geschrieben ca. 1400 Millisekunden, Integer ca. 200. Und dann ist die 64-Bit Variante bei mir auch langsamer.

[mytbo]

Delphi 11.3 Alexandria, Build Release (Standardeinstellungen), Prozessor Intel(R) Core(TM) i5 3.20GHz

Delphi-Quellcode:

uses
  mormot.core.base,
  mormot.core.perf;

const
  RUN_COUNT = 1000000000;
var
  timer: TPrecisionTimer;
begin
  timer.Start;
  var sum: Int64 := 0;
  for var i: Integer := 1 to RUN_COUNT do
    // sum := sum + 1;
    Inc(sum);

  ShowMessage(Format('Laufzeit: %s (%d us), Summe: %d', [timer.Stop, timer.StopInMicroSec, sum]));

Plattform	Laufzeit: Inc(sum)	Laufzeit: sum := sum + 1
32 Bit	1.82s (1822103 us)	1.69s (1693918 us)
64 Bit	294.65ms (294654 us)	294.85ms (294857 us)

Verwende ich sum in der Ausgabe (ShowMessage) nicht, sehen die Ergebnisse für 32-Bit so aus:

Plattform	Laufzeit: Inc(sum)	Laufzeit: sum := sum + 1
32 Bit	294.92ms (294925 us)	1.68s (1688951 us)

Die Werte für 64-Bit ändern sich nicht.

Alle Messwerte in mehreren Durchläufen verifiziert.

Bis bald...
Thomas

[MEissing]

Zitat von Stevie:

Zitat von jaenicke:

Zitat von Stevie:

Zur Eingangsfrage und den um mehr als Faktor 10 unterscheidenden Ergebnissen kann ich nur sagen: da ist ziemlich sicher irgendwo ein Messfehler oder eine nicht vergleichbare Compilerkonfiguration.

Das hat ja Matthias schon beantwortet.

Hat er?

Ja. Vor allem auf M1 Max getestet. Wo hast du getestet?

[Stevie]

Zitat von MEissing:

Zitat von Stevie:

Zitat von jaenicke:

Zitat von Stevie:

Zur Eingangsfrage und den um mehr als Faktor 10 unterscheidenden Ergebnissen kann ich nur sagen: da ist ziemlich sicher irgendwo ein Messfehler oder eine nicht vergleichbare Compilerkonfiguration.

Das hat ja Matthias schon beantwortet.

Hat er?

Ja. Vor allem auf M1 Max getestet. Wo hast du getestet?

Auf einem i7-12700 - wenn du auf ner ARM CPU x86(-64) Kompilate testest, dann möchte ich behaupten, dass das durch irgendeine Emulationsschicht läuft und da könnte es durchaus sein, dass die 32bit Executable einen hohen Overhead verursacht.

Zitat von mytbo:

Plattform	Laufzeit: Inc(sum)	Laufzeit: sum := sum + 1
32 Bit	1.82s (1822103 us)	1.69s (1693918 us)
64 Bit	294.65ms (294654 us)	294.85ms (294857 us)

Verwende ich sum in der Ausgabe (ShowMessage) nicht, sehen die Ergebnisse für 32-Bit so aus:

Plattform	Laufzeit: Inc(sum)	Laufzeit: sum := sum + 1
32 Bit	294.92ms (294925 us)	1.68s (1688951 us)

Die Werte für 64-Bit ändern sich nicht.

Alle Messwerte in mehreren Durchläufen verifiziert.

Inc für Int64 ist scheinbar leider etwas unglücklich implementiert unter 32bit und sorgt nicht für denselben Code.

Mit + bekomm ich diese Ergebnisse:

Win32: ca 290ms
Win64: ca 220ms

Außerdem ist es immer gefährlich den Zeitmessungscode und die Ausgabe, welche fast immer strings beinhaltet mit in dieselbe Routine zu packen, wie den Code, den man messen möchte. Das kann u.U. katastrophale (im Sinne der gemessenen Zeit) haben, da der Compiler für strings und andere gemanagte Typen ein implizites try/finally erzeugt und dieses besonders unter 32bit dafür sorgt, dass der Compiler jegliche werte immer über den Stack bezieht anstatt sie in Registern zu behalten.

Zurück zum Inc auf 32bit:

Erzeugt diesen code:

Code:

add dword ptr [ebp-$18],$01
adc dword ptr [ebp-$14],$00

sum := sum + 1; erzeugt diesen:

Code:

mov eax,[ebp-$18]
mov edx,[ebp-$14]
add eax,$01
adc edx,$00
mov [ebp-$18],eax
mov [ebp-$14],edx

"Aber Stevie, das ist doch mehr Code, warum läuft der langsamer?"
Dafür müssen wir uns mal anschauen, wie die Timings dieser Befehle sind und dazu kann man dieses Dokument zurate ziehen.

Genauer gesagt, schauen wir uns add und adc mit den Operanden m,r/i an (das, was Inc erzeugt) - ich nehme dafür die Timings von Icelake auf Seite 349. Wenn wir in die Spalte Latency gehen, sehen wir dort eine für die Performance vernichtende 7. Der Code, welcher für die Addition genutzt wird nutzt add und adc mit den Operanden r,r/i, die eine Latenz von 1 haben. Die zusätzlichen mov Befehle werden hier vermutlich durch die sogenannte "mov elimination" von der CPU entfernt, da sie erkennt, dass man immer nur denselben Wert schreibt und liest (das ist aber unbestätigt und nur eine Vermutung meinerseits, dafür müsste ich den Code genauer profilen).

[MEissing]

Ja. Sicherlich.

Aber darum geht/ging es doch (siehe Betreff)

[Stevie]

Zitat von MEissing:

Ja. Sicherlich.

Aber darum geht/ging es doch (siehe Betreff)

Ich lese aus dem Betreff "Geschwindigkeitsunterschiede Apple Sillicon / Intel Win32 / Win64" nicht, dass es um den Vergleich zwischen nativ für ARM kompiliert und Win32 und Win64 kompilate in ner Windows VM laufen lassen geht

[Rollo62]

Wäre es denkbar dass solche krassen Unterschiede x10 auch durch Intel vs.AMD kommen könnten?
Hier wird wohl Intel favorisiert, aber ich vermute AMD liegt da gleichauf.
Oder ist das eine falsche Annahme ?

[Blup]

Zitat von mytbo:

Verwende ich sum in der Ausgabe (ShowMessage) nicht, sehen die Ergebnisse für 32-Bit so aus:

Da sollte man sich wirklich den erzeugten Code genauer anschauen.
Sicher das der Compiler das Inc(Sum) nicht einfach wegoptimiert?
Ein schlauer Compiler könnte sogar die Schleife wegoptimieren Inc(Sum, RUN_COUNT) .

Wichtig ist sicher, ob der erzeugte Code für die Schleife vollständig in die Befehlswarteschlange des Prozessorkerns passt und die Sprungvorhersage richtig liegt.

[Stevie]

Zitat von Rollo62:

Wäre es denkbar dass solche krassen Unterschiede x10 auch durch Intel vs.AMD kommen könnten?
Hier wird wohl Intel favorisiert, aber ich vermute AMD liegt da gleichauf.
Oder ist das eine falsche Annahme ?

Es gibt sicherlich vereinzelt Unterschiede bei den Timings zwischen den Herstellern und auch zwischen den verschiedenen Generationen aber speziell bei dem hier besprochenen Code sehe ich diesen nicht.
Solang nicht detailiertere Information vorliegen vermute ich entweder die Virtualisierungs-/Emulationssschicht oder das Benutzen von Inc anstatt +1 als Ursache.
In dem zuvor verlinkten Dokument stehen auch die Instructiontimings von AMD einschließlich Zen 4.

Zitat von Blup:

Wichtig ist sicher, ob der erzeugte Code für die Schleife vollständig in die Befehlswarteschlange des Prozessorkerns passt und die Sprungvorhersage richtig liegt.

Die Schleife ist so klein, die passt in eine cacheline. Und die Sprungvorhersage ist ziemlich sicher 999999999 mal richtig und nur das letzte mal falsch.