Geschwindigkeitsunterschiede Apple Sillicon / Intel Win32 / Win64

[areyoudoneyet]

das ist bestimmt eine Anfänger Frage und eventuell den meisten Leuten klar weshalb folgendes, das ich gleich beschreibe so ist wie es ist.
Ich habe gestern ein kleines Tutorial Video von DelphiLernen auf Youtube angeschaut. Und das kleine Programm nachgebaut.

Code:

procedure TForm1.Button1Click(Sender: TObject);
var
  i: integer;
  sum: Int64;
  StartTime, EndTime, ElapsedTime: Int64;
begin
  StartTime := MilliSecondOfTheDay(Now);

  sum := 0;
  for i := 1 to 1000000000 do
    sum := sum + 1;

  EndTime := MilliSecondOfTheDay(Now);
  ElapsedTime := EndTime - StartTime;

  ShowMessage('Summe: ' + IntToStr(sum) + ' / Zeit: ' + IntToStr(ElapsedTime) + ' ms');
end;

Nichts großartiges.

Ich habe es für alle mir verfügbaren Plattformen kompiliert.

Win32 = 6063ms
Win64 = 390ms
macOS ARM 64 Bit = 1296 ms
macos 64 Bit ( mit rosetta) = 316 ms

in C für Arm mit gcc -O3

2 ms

Swift
41 ms Sekunden

C#
362 ms

Lazarus fpc für intel

421ms

fpc für arm
1624 ms


Was mich etwas wundert das dies in Windows bei 64 und 32 so ein großer unterschied ist, und das bei macOS die Rosetta Variante auch sehr viel schneller ist als die (Native Arm) Version. Selbe Bild beim FPC.

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

Was mir stark gewundert hat das Swift die Schleife so schnell durchläuft und auch das C# das Schneller durchläuft unter Macos als die Delphi variante.

Den Hacken Optimierungen habe ich angekreuzt in Delphi. Eventuell gibt es da noch etwas das man machen könnte.

Mich interessiert einfach woher diese unterschiede kommen. Vielleicht kann mich da jemand kurz aufklären.

Danke

[himitsu]

* wie optimal erzeugt der Compiler den Code
* wie schnell sind die einzelnen verwendeten CPU-Befehle
* was bietet die jeweilige Platform eigentlich für Befehle
* wie gut läuft der Speicherzugriff
* und wie gut die Abarbeitung dieses Codes



Win32 muß langsamer sein, denn bei 64 Bit rechnet die CPU, mit einem "Assembler"-Befehl,
während es unter 32 Bit eine Funktion macht, also viele Assembler-Befehle.

[edit]
Nee, beim ADD wird es direkt gemacht, aber auch mit mehreren Befehlen, denn die 32 Bit-CPU kann ja nur mit 32 Bit rechnen.
MUL, DIV, MOD waren aber Funktionen. (z.B. siehe __llmul in der System.pas)

Delphi-Quellcode:

// Win32
mov eax,[ebp-$10]
mov edx,[ebp-$0c]
add eax,$7b
adc edx,$00
jno $006663d9
call $00498228
mov [ebp-$10],eax
mov [ebp-$0c],edx

// Win64
add qword ptr [rbp+$28],$7b
jno TForm4.FormCreate + $20
call @IntOver

Und wenn man jetzt noch die Überlauf- und Bereichsprüfung wieder deaktiviert, welche nun seit Kurzem standardmäßig aktiv sind.

Delphi-Quellcode:

mov eax,[ebp-$10]
mov edx,[ebp-$0c]
add eax,$7b
adc edx,$00
mov [ebp-$10],eax
mov [ebp-$0c],edx

versus

add qword ptr [rbp+$08],$7b

PS, bezüglich der Optimierung.
Bei gewissen Rechenoperationen kann es "anders" einfacher gehn.

z.B. aus einem i * 2 kann oft einfach ein i shl 1 werden.
Und ein "einfacher" Bit-Shift geht auch mit weniger CPU-Takten, als ein "aufwendiges" mathematisches Rechnen.

[areyoudoneyet]

Danke für die schöne Erklärung!
6 zu 1 mehr Arbeit in der 32 Bit Version, hätte ich nicht gedacht.

[jaenicke]

Das hängt aber auch sehr vom konkreten System ab. Bei mir (i5-8600k) braucht Win32 ca. 1400 Millisekunden und Win64 ca. 1600 bzw. im Release 1300 vs. 400. Da ist der Unterschied geringer. Generell ist die Optimierung beim 64-Bit Compiler oft besser.

[areyoudoneyet]

Zitat von jaenicke:

Das hängt aber auch sehr vom konkreten System ab. Bei mir (i5-8600k) braucht Win32 ca. 1400 Millisekunden und Win64 ca. 1600 bzw. im Release 1300 vs. 400. Da ist der Unterschied geringer. Generell ist die Optimierung beim 64-Bit Compiler oft besser.

Verstehe

Code:

var
  counter: integer;
  startTime, endTime: TDateTime;
  timeTaken: Double;
begin
  counter := 1;
  startTime := Now; // Startzeit aufzeichnen

  asm
    mov ecx, counter
  @loop_start:
    inc ecx
    cmp ecx, 100000000
    jle @loop_start
    mov counter, ecx
  end;
  endTime := Now; 
  timeTaken := MilliSecondSpan(startTime, endTime); 
  ShowMessage(FloatToStr(timeTaken) + ' ms');
end;

jetzt nur noch ca. 50 ms für win32

Code:

procedure TForm1.Button1Click(Sender: TObject);
var
   counter:integer;
  startTime, endTime: TDateTime;
  timeTaken: Double;
begin
   counter := 0;
  startTime := Now; // Startzeit aufzeichnen
  while counter <= 100000000 do
    inc(counter);
  endTime := Now; // Endzeit aufzeichnen
  timeTaken := MilliSecondSpan(startTime, endTime); // Berechnung der benötigten Zeit in Millisekunden
  ShowMessage(FloatToStr(timeTaken) + ' ms'); // Zeigt die benötigte Zeit in Millisekunden an

end;

Ich habe jetzt mal den inc versucht. ist egal ob auf mac oder win immer bei ca. 30-60 ms.

d.h. für mich falls ich etwas Inkrementieren muss sollte ich "inc" verwenden anstelle "x := x+1;"

ich find das echt Interresant Dachte für mich immer... das ist doch das gleiche...

[jaenicke]

Deine neuen Quelltexte machen aber auch etwas anderes. Anfangs hattest du eine Schleife mit der Änderung der Schleifenvariable und zusätzlich das Inkrementieren eines Wertes. Jetzt hast du nur noch die Schleife. Dass das schneller ist, ist klar.

[areyoudoneyet]

Zitat von jaenicke:

Deine neuen Quelltexte machen aber auch etwas anderes. Anfangs hattest du eine Schleife mit der Änderung der Schleifenvariable und zusätzlich das Inkrementieren eines Wertes. Jetzt hast du nur noch die Schleife. Dass das schneller ist, ist klar.

hm stimmt.

[MEissing]

int64 ist auf Win32 ist "teuer"

Das ursprüngliche

Code:

var
  i: int64;

auf

Code:

var
  i: integer;

bringt für Win32 schon etliches (6044 -> 736ms)

[Stevie]

Zitat von jaenicke:

Generell ist die Optimierung beim 64-Bit Compiler oft besser.

Dem muss ich widersprechen - eher im Gegenteil. Es ist in diesem konkreten Fall so, dass unter 64bit nativ gerechnet werden kann und unter 32bit ein Int64 auf 2 Register aufgeteilt ist.

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.

[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.