Delphi Performance Vergleich zu C#

[Stevie]

Zitat von 4dk2:

Also bei C# wurd das vorher denke ich auch wegoptimiert

In meinem Test nicht. netcore 3.0 mit oder ohne Ausgabe von x war von Anfang an so schnell wie die Variante in Delphi, die in der Schleife das Register nutzt.

[4dk2]

Zitat von Stevie:

Zitat von 4dk2:

Also bei C# wurd das vorher denke ich auch wegoptimiert

In meinem Test nicht. netcore 3.0 mit oder ohne Ausgabe von x war von Anfang an so schnell wie die Variante in Delphi, die in der Schleife das Register nutzt.

ok, ich hab bei mir auch nochmal core im vergleich zu Standard laufen lassen,
beide ungefähr gleichschnell und egal ob mit oder ohne Ausgabe.
0,41 sek~ in beiden Fällen

[Stevie]

Ach, noch was - solang du nichts daran geändert hast, wird dein .net Projekt mit Any CPU gebaut und läuft somit vermutlich als 64bit. Wenn ich das explizit auf x86 umstelle wirds auch langsam.

Hingegen wird es auf der Delphi Seite noch gruseliger, wenn ich auf Win64 umstelle. Da wird sogar ein explizites x:=x*3 direkt in der Schleife zu einem dämlichen

Delphi-Quellcode:

Project351.dpr.40: x := x*3;
000000000055A67B 8B0DCB770300     mov ecx,[rel $000377cb]
000000000055A681 488D0C49         lea rcx,[rcx+rcx*2]
000000000055A685 890DC1770300     mov [rel $000377c1],ecx

Von den Ergebnissen auf Linux, mit dem ach so tollen LLVM Backend, wo die Hälfte der wichtigen Optimierungen hardcoded ausgeschaltet wurden, fang ich gar nicht erst an... yay native compiled...

[4dk2]

Neee hab die schon explizit alle auf x86 gestellt. Um das "irgendwie" gleich zu halten.
Aber 64bit bringt bei mir zum vergleich, keinen Gewinn/Verlangsamung. (bei Core und Standard)
Das wäre aber auch merkwürdig wenn doch.
Kp was der im CLR macht, aber X ist ja ne 32bit var, dürfte also ja auch keine verbesserung in der 64bit cpu bringen.

[DieDolly]

---

[Stevie]

Zitat von DieDolly:

Ab wann lohnt es sich, eine Funktion mit inline zu deklarieren?

Können wir das in einem neuen Thread diskutieren bitte?

[Stevie]

Zitat von 4dk2:

Neee hab die schon explizit alle auf x86 gestellt. Um das "irgendwie" gleich zu halten.
Aber 64bit bringt bei mir zum vergleich, keinen Gewinn/Verlangsamung. (bei Core und Standard)
Das wäre aber auch merkwürdig wenn doch.

Keineswegs merkwürdig - x86 hat im Vergleich zu x64 eine sehr limitierte Anzahl an verfügbaren Registern, daher kommt es da eher zu Register pressure.

Edit: Ich hab übrigens herausgefunden, was hier dafür sorgt, dass es in meinem Fall langsamer wurde. Ich habe timeges als long deklariert, da ich mir dachte, nuja Stopwatch.ElapsedMilliseconds ist ja auch long, also machts da keinen Sinn, das in double umzuwandeln. Allerdings sorgt das wohl bei x86 dafür dass er vermutlich ähnlich wie bei Delphi die Schleife nicht gut optimiert. Wenn timeges double ist, dann ist's auch unter x86 schnell.

Hach ja, Microbenchmarks sind toll...

[Luckie]

Müsste man nicht auch Taskswitches verhindern, um vergleichbare Ergebnisse zu erhalten?

[Stevie]

Zitat von Luckie:

Müsste man nicht auch Taskswitches verhindern, um vergleichbare Ergebnisse zu erhalten?

Solang man eine singlethreaded Benchmark hat, reicht es in der Regel, sicher zu stellen, dass die Maschine auf der sie läuft nicht gerade viele Resourcen verbraucht und somit die Benchmark ohne Beeinträchtigung läuft.

[p80286]

Zitat von Stevie:

fang ich gar nicht erst an... yay native compiled...

Ach komm, nur weil die theoretischen Vorteile nicht genutzt werden...
Solange die meisten meiner Programme von Platte und/oder DB ausgebremst werden, mach ich mir um 10 Sekunden keine Gedanken.

Gruß
K-H