Delphi Performance Vergleich zu C#

[Stevie]

Zitat:

Zitat von 4dk2 (Beitrag 1451792)

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:

Zitat von Luckie (Beitrag 1451803)

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:

Zitat von Stevie (Beitrag 1451790)

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

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:

Zitat von p80286 (Beitrag 1451808)

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:

Zitat von Stevie (Beitrag 1451809)

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.

[hoika]

Hallo,

Zitat:

managed/interpreted/jitted langsam sei.

Das ist jetzt wirklich antiquiert.

[4dk2]

Zitat:

Zitat von p80286 (Beitrag 1451808)

Zitat:

Zitat von Stevie (Beitrag 1451790)

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

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

Also bei mir (Echtzeit-Maschinen-Steuerungen)
Kommt es schon drauf an, ob das fronted hinterher kommt. (Datenerfassung/Auswertung)
Und ich find es trotzdem wichtig und auch interessant mal sowas
Mit so einfachen Tests zu beleuchten!
Das bei 90% der Anwendungen die CPU nicht das bottleneck ist, ist ja klar.

Bei mir war es so, das Event gesteuert, Daten berechnet wurden, und das sich als zu langsam
Herausgestellt hat. Per Interfaced Aufruf wurd es dann schneller aber dann wollte ich es genau wissen.

Falls es jemanden interessiert hier die c# Performance Charts
Um per Parameter ein Ergebnis zu bekommen.
1. normaler (Aufruf wie im Beispiel)
2. delegates (func<int,int>)
3. interfaced (dauert unerwartet lange)
4. Events (ist sogar langsamer als der normale Delphi Aufruf xD )

[generic]

Ich kann mir schon vorstellen, dass der JIT erheblich schneller ist.
Einfach daher, dass er just in time die CPU kennt und somit passend optimieren kann.
Der Delphi-Compiler kann ja nur doof generischen x86 Code erzeugen.

[4dk2]

Zitat:

Zitat von Stevie (Beitrag 1451781)

Erzähl mir nochmal einer, dass nativ kompiliert so viel geiler ist als diese teuflische managed Zeugs! :evil:

Stevie, ich hab da nen .Net Fall, wo der generierte Code ähnlich wie bei Delphi langsam wird!

Also Normale Berechnung in ner Schleife:

Code:

const int Iterations = 1000000000;
int x = 3;
for (int i = 0; i < Iterations; i++)
{
   x = x * 3;
}

Geschwindigkeit bei meiner CPU = ~500 ms.
So wenn ich aber jetzt DAVOR/Danach x per reference/out benutze, wirds höllisch langsam.
Dann fällt der Speed auf ~3000 ms.

Code:

void Init(ref int x)
{
   x = 3;
}
.....

Init(ref x);
for (int i = 0; i < Iterations; i++)
{
  x = x * 3;
}
//Init(ref x);