Delphi Performance Vergleich zu C#

[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

[Stevie]

Zitat von p80286:

Ach komm, nur weil die theoretischen Vorteile nicht genutzt werden...

Es soll auch Softwarebereiche geben, die CPU und nicht IO bound sind.
Wenn der Compiler nen besseren Job machen würde, dann bräuchte auch nicht die Hälfte der System.pas in Assembler geschrieben werden, damit sie schnell(er) ist.

Außerdem geht's mir hier primär um die antiquierte Ansicht und Propaganda, die von vielen verbreitet und geglaubt wird, dass nativ kompiliert automatisch schnell und managed/interpreted/jitted langsam sei.

[jobo]

Zitat von Stevie:

Außerdem geht's mir hier primär um die antiquierte Ansicht und Propaganda, die von vielen verbreitet und geglaubt wird, dass nativ kompiliert automatisch schnell und managed/interpreted/jitted langsam sei.

Hatten wir hier grad auf Mips mit Java: sehr langsam, nicht optimiert. Da macht man dann auch erstmal gar nichts, auch nicht Assembler.
Man kann es vielleicht so sagen: Automatisch wird gar nichts optimiert, wenn also überhaupt eine Automatik existiert, dann nur die der Langsamkeit.
Es scheint darauf anzukommen, welche Interessenlage in den jeweiligen Ökosystemen besteht.