Delphi Performance Vergleich zu C#

[4dk2]

Moin zusammen,
Hauptsächlich programmier ich zwar nur noch mit C#,
Aber weil ich dort wegen nem Performance-Problem, einige Basic Tests gemacht habe,
hat mich auch interessiert, wie die Performance im Vergleich zu Delphi aussieht.
Und es hat mich doch sehr verwundert :shock::shock::shock:

Vorne Weg:
Für den Test bei C# hab ich die neueste(last patch) VS2019 Ide genommen,
Target App: Standard 4.7.2, Konsole, x86, Release (kein debugging...)
(Zeit messen per Stopwatch)

Für den Test unter Delphi:
XE10.1(Berlin) Konsole, X86, Kein Debugging, Optimierung Aktiv
(Zeit messen per JclCounter)

Zusatzttest:
Auch unter Delphi7 gemacht.


Der Test der mich interessiert hat, ist anfür sich recht simple:

Delphi-Quellcode:

// JCL_DEBUG_EXPERT_GENERATEJDBG OFF
// JCL_DEBUG_EXPERT_INSERTJDBG OFF
// JCL_DEBUG_EXPERT_DELETEMAPFILE OFF
program BenchmarkCallSpeed;

{$APPTYPE CONSOLE}

{$R *.res}

uses

  System.SysUtils,  JclCounter;

var
  s:string;
  tc:TJclCounter;
  i:integer;
  itotal:integer;
  x:integer;
  totalSecs:double;
  const Iterations=1000000000;
  const TestTarget=100;

function foo(x:integer):integer;
begin
  result:=x*3;
end;

function fooInline(x:integer):integer;inline;
begin
  result:=x*3;
end;

begin
  try
    totalSecs:=0;

    tc:=TJclCounter.Create(true);
    Writeln('Start');
    for itotal := 1 to TestTarget do
    begin
      x:=3;

      tc.Stop;
      tc.Start;
      for i := 0 to Iterations-1 do
      begin
        x:=foo(x);
        //x:=fooInline(x);
      end;
      tc.Stop;
      totalSecs:=totalSecs+tc.ElapsedTime;
      Writeln('Step: '+itotal.ToString()+' = '+tc.ElapsedTime.ToString()+ ' sec X: '+IntToStr(x));
    end;
    Writeln('TOTAL~: '+(totalSecs/TestTarget).ToString());

    tc.Free;

    Writeln('ENDE');
    Readln(s);


  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

Ich glaub das ganze ist ja so simpel, dass es jeder verstehen sollte :lol:
Ergebnis ist jetzt folgendes:


EDIT!!!!! Die Zeiten angepasst, nachdem X auch noch benutzt wird!

DELPHI XE10.1:
100 Tests
Durchschnitt : 2,360 sekunden
CPU auslastung : 35%~

DELPHI 7:
100 Tests
Durchschnitt : (neuer kommt noch) sekunden
CPU auslastung : 35%~

C#
100 Tests
Durchschnitt : 0,7227 sekunden
CPU auslastung : 35-50%~

C# .Net Core 3.0
100 Tests :
Durchschnitt : (neuer kommt noch) sekunden
CPU auslastung : 35-50%~




Ich finde das extrem krass!
Ich hätte ja gesagt, wegen JIT Code vs Native, wäre da Delphi wahrscheinlich schneller, bzw gleichauf.
aber 4x langsamer?
Was meint ihr dazu?


EDIT:
Falls es jemand selber mit C# vergleichen will...
Wichtig ist aber! Auf Release Testen! das macht nen gewaltigen Unterschied aus.

Code:

public static int Foo(int x)
        {
            return x * 3;
        }

        static void Main(string[] args)
        {

            //Dauertest von Normal

            const int Iterations = 1000000000;
            int x = 0;
            int testtarget = 100;
            double timeges = 0;
            System.Diagnostics.Stopwatch sw;

            Console.WriteLine($"Start:");
            Console.WriteLine($"init: {Foo(3)}"); //JIT init, erste ergebnis sonst evtl verfälscht

            for (int itotal = 1; itotal <= testtarget; itotal++)
            {
                x = 3;
                sw = System.Diagnostics.Stopwatch.StartNew();
                for (int i = 0; i < Iterations; i++)
                {
                    x = Foo(x);
                }
                sw.Stop();
                timeges = timeges + sw.ElapsedMilliseconds;
                Console.WriteLine($"Step: {itotal} = {sw.ElapsedMilliseconds/1000d} X: {x}" );
            }
            Console.WriteLine($"TOTAL: {timeges / testtarget/1000d} ms~");

        }

Edits:
-.Net Core 3.0 hinzugefügt
-Stevie hat darauf hingewiesen, das ja wegen optimierung, die X variable wenigstens 1x benutzt werden muss, daher angepasst, fürs archiv XD

[Uwe Raabe]

Ändere mal die Deklaration der Funktion auf inline:

Delphi-Quellcode:

function foo(x:integer):integer; inline;

[Bernhard Geyer]

Mach mal deine funktion inline.

Solche sehr einfachen Tests sind immer mit Vorsicht zu genießen.
I.d.R. sind alle modernen Umgebungen im Alltag gleich schell, da oft eher das "drumherum" wie Framework (VCL gegen - Was ist gerade bei C#/.NET "das Hippe Ding" oder
die Implementierungsalgortihmen der relevantere Teil sind.


Bei C# könnte die "numbercrunshing" Compileroptimierungen für moderne Prozessoren hier eingiges Ausmachen.

[4dk2]

hmmm, okaay, dann ist delphi gleichauf:

DELPHI XE10.1 (inline):
100 Tests
Durchschnitt : 0,3567 sekunden
CPU auslastung : 35%~

[Bernhard Geyer]

Zitat:

Zitat von 4dk2 (Beitrag 1451760)

hmmm, okaay, dann ist delphi gleichauf:

Oft sind es die kleinen Dinge.
Auch eine const-Angabe hilft teilweise.
Oder in diesem Fall ein var-Übergabe damit gar (fast) keine zusätzlichen Variablen/Stack/.... benötigt werden.

Hate "damals" zu D6 Zeiten unsere Anwendung Unicode-Enabled.
Eine ergänzung von const an allen String-Übergabeparametern hatte hier schon auch ind der kompletten Anwendung merklich Geschwindigkeit gebracht.

Für Sowas empfiehlt sich immer eine Performance-Analyse mit AQTime um die relevanten stellen gleich zu finden.

[4dk2]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1451759)

I.d.R. sind alle modernen Umgebungen im Alltag gleich schell, da oft eher das "drumherum" wie Framework (VCL gegen - Was ist gerade bei C#/.NET "das Hippe Ding" oder
die Implementierungsalgortihmen der relevantere Teil sind.

Eigendlich hat Delphi garnix mit meinem Problem zu tun gehabt.
Es ging darum, dass ich Performance Probleme bei Interfaced aufrufen hatte.
Deswegen hab ich unter C# Normal/Interfaced/Delegate/Events verglichen...
Delphi war dann Just4Fun :stupid:

Zitat:

Zitat von Bernhard Geyer (Beitrag 1451759)

Bei C# könnte die "numbercrunshing" Compileroptimierungen für moderne Prozessoren hier eingiges Ausmachen.

Hab mal danach gesucht, aber nix gefunden?

[4dk2]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1451762)

Zitat:

Zitat von 4dk2 (Beitrag 1451760)

hmmm, okaay, dann ist delphi gleichauf:

...
Oder in diesem Fall ein var-Übergabe damit gar (fast) keine zusätzlichen Variablen/Stack/.... benötigt werden.

Delphi-Quellcode:

procedure fooVar(var x:integer);//inline;
begin
  x:=x*3;
end;

procedure fooOut(x:integer;out xout:integer);//inline;
begin
  xout:=x*3;
end;

falls du das so meintest, mit und ohne inline, sind die langsam, langsamer als die normale ohne inline (2,1 sek)

[Stevie]

Halt stop!

Wenn du Foo inline markierst, wird der Code schneller, weil er nix mehr ausführt (siehe H2077 in den Compilermeldungen) außer einer leeren Schleife. Es wird nix mit x gemacht also spart er sich auch die Multiplikation. Ein beherztes Writeln(x) nach der Schleife und der code ist wieder langsam. Das liegt einfach daran, dass der Delphi Compiler schrottigen Code erzeugt und Register nicht optimal nutzt.

Aus dem geinlinetem

Delphi-Quellcode:

x:=Foo(x)

Aufruf wird folgendes:

Delphi-Quellcode:

Project351.dpr.38: x:=foo(x);
004EE8DD 8B155C944F00     mov edx,[$004f945c]
004EE8E3 8D1452           lea edx,[edx+edx*2]
004EE8E6 89155C944F00     mov [$004f945c],edx

Die Variable wird also nicht einfach im Register gehalten sondern unnötigerweise immer zurück geschrieben und gelesen. Den Code und die globalen Variablen in eine Routine zu verlagern hilft übrigens auch nicht. Die Multiplikation direkt durchzuführen hat übrigens denselben ungünstigen Assembly Code zum Ergebnis.

Edit: Wenn

Delphi-Quellcode:

Writeln(x)

direkt vor oder nach dem

Delphi-Quellcode:

sw.Stop

steht, dann ist der Assembly Code optimal, denn dann kann x im Register gehalten werden.

[Uwe Raabe]

Zitat:

Zitat von Stevie (Beitrag 1451774)

Ein beherztes Writeln(x) nach der Schleife und der code ist wieder langsam.

Nicht in 10.3.3 Rio. Da liegen die Werte mit und ohne Writeln(x) annähernd gleichauf.

Übrigens bekomme ich ähnliche Werte, wenn ich den Schleifenbody komplett auskommentiere 8-)

Delphi-Quellcode:

program BenchmarkCallSpeed;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils,
  System.Diagnostics;

function foo(x:integer):integer; inline;
begin
  result:=x*3;
end;

const
  Iterations=1000000000;
  TestTarget=100;

var
  s:string;
  tc:TStopwatch;
  i:integer;
  itotal:integer;
  x:integer;
  totalMSecs:Int64;
begin
  try
    totalMSecs:=0;

    tc:=TStopwatch.Create.Create;
    Writeln('Start');
    for itotal := 1 to TestTarget do
    begin
      x:=3;

      tc.Reset;
      tc.Start;
      for i := 0 to Iterations-1 do
      begin
        x:=foo(x);
      end;
      tc.Stop;
      totalMSecs := totalMSecs + tc.ElapsedMilliseconds;
      Writeln(x);
      Writeln('Step: '+itotal.ToString()+' = '+tc.ElapsedMilliseconds.ToString()+ ' ms');
    end;
    Writeln('TOTAL~: '+(totalMSecs/TestTarget).ToString());

    Writeln('ENDE');
    Readln(s);
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

[Stevie]

Zitat:

Zitat von Uwe Raabe (Beitrag 1451780)

Zitat:

Zitat von Stevie (Beitrag 1451774)

Ein beherztes Writeln(x) nach der Schleife und der code ist wieder langsam.

Nicht in 10.3.3 Rio. Da liegen die Werte mit und ohne Writeln(x) annähernd gleichauf.

Dann schreib doch mal das

Delphi-Quellcode:

Writeln(x)

hinter das

Delphi-Quellcode:

Writeln('Step: '+itotal.ToString()+' = '+tc.ElapsedMilliseconds.ToString()+ ' ms');

:roll:

Der Punkt bleibt: der Delphi Compiler optimiert relevante Stellen nicht, nur weil er später den Wert noch benötigt und ihn bis dahin nicht im Register halten kann.
Er könnte problemlos für die Schleife mit dem Register arbeiten und danach einmal das mov machen.

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

[sakura]

Zitat:

Zitat von Stevie (Beitrag 1451781)

Dann schreib doch mal das

Delphi-Quellcode:

Writeln(x)

hinter das

Delphi-Quellcode:

Writeln('Step: '+itotal.ToString()+' = '+tc.ElapsedMilliseconds.ToString()+ ' ms');

:roll:

Willst Du uns verarschen :pale: Alter Falter...!

...:cat:...

[4dk2]

Also bei C# wurd das vorher denke ich auch wegoptimiert, jetzt liege ich beim functionsaufruf bei
0,7227 sec EDIT! : irgendwie nen messfehler? siehe weiter unten
zum vergleich:
direkte berechnung in der schleife

Code:

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

== 0,444 sec

[DelTurbo]

Hi,
ich habe eine Frage zu dem inline. Das interessiert mich. Wie macht es eigentlich Delphi 2007? Kann man folgenden Artikel auch auf Delphi 2007 beziehen, oder muss man es dort ein bissl anders machen?

http://docwiki.embarcadero.com/RADSt...frufen_(Delphi)

Gruß

[4dk2]

Zitat:

Zitat von sakura (Beitrag 1451783)

Zitat:

Zitat von Stevie (Beitrag 1451781)

Dann schreib doch mal das

Delphi-Quellcode:

Writeln(x)

hinter das

Delphi-Quellcode:

Writeln('Step: '+itotal.ToString()+' = '+tc.ElapsedMilliseconds.ToString()+ ' ms');

:roll:

Willst Du uns verarschen :pale: Alter Falter...!

...:cat:...

Grad getestet, es ist wirklich so :shock::shock::shock::shock:

Delphi-Quellcode:

Writeln('Step: '+itotal.ToString()+' = '+tc.ElapsedTime.ToString());
Writeln(x);
==2,3 sec

Writeln(x);
Writeln('Step: '+itotal.ToString()+' = '+tc.ElapsedTime.ToString());
==1,4 sec

Ist auf Jedenfall seeeehr interessant. :-D

[Stevie]

Zitat:

Zitat von 4dk2 (Beitrag 1451784)

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:

Zitat von Stevie (Beitrag 1451787)

Zitat:

Zitat von 4dk2 (Beitrag 1451784)

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

Delphi-Quellcode:

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... :kotz:

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

Zitat von DieDolly (Beitrag 1451795)

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

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

[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);

[Stevie]

Kann ich aus den Schnipseln bei mir nicht reproduzieren - und ich geh mal davon aus, dass dein Init static ist, ansonsten wirds eh schwierig, sie aus der static void Main aufzurufen.

Edit: Ah, doch jetzt - ich vermute einfach mal, je nach Konstellation wird man hier bei x86 Opfer von Register Pressure - als x64 läufts immernoch schnell.
Meine Aussage steht aber immernoch obwohl es Situationen gibt, wo man .Net langsam bekommt, ist es in vielen Fällen by default schneller, da besser optimiert - und ich red hier vom Binärcode und nicht von Dingen wie Memorymanagement/GC.

[Sherlock]

Ich schieße mal knapp vorbei, und schreibe, worauf es meinen Kunden ankommt: Ich liefere eine Exe aus, fertig. Kein Installer nötig. Ich baue dennoch einen, aber der erkennt halt 32Bit oder 64 Bit und legt die passende Exe ins passende Verzeichnis ab, das ginge auch von Hand. Monolithische Exen ohne Framework-Abhängigkeit bringen die Augen der IT meiner Kundschaft zum Leuchten manchmal auch Tränen der Wehmut und Dankbarkeit. Das geht weder mit Java, noch mit .net noch mit dlls oder sonstigen Sperenzchen. Und das geht derzeit (vernünftig) nur mit Delphi, mMn.

Sherlock

[Bernhard Geyer]

Zitat:

Zitat von Sherlock (Beitrag 1452285)

Das geht weder mit Java

Komisch. Wir können das mit unsere Desktop-Java-Anwendungen.
Ist haber natürlich "richtig fett" gegenüber eine "fetten" Delphi-Anwendung.

[Stevie]

Zitat:

Zitat von Sherlock (Beitrag 1452285)

Ich schieße mal knapp vorbei, und schreibe, worauf es meinen Kunden ankommt: Ich liefere eine Exe aus, fertig. Kein Installer nötig. Ich baue dennoch einen, aber der erkennt halt 32Bit oder 64 Bit und legt die passende Exe ins passende Verzeichnis ab, das ginge auch von Hand. Monolithische Exen ohne Framework-Abhängigkeit bringen die Augen der IT meiner Kundschaft zum Leuchten manchmal auch Tränen der Wehmut und Dankbarkeit. Das geht weder mit Java, noch mit .net noch mit dlls oder sonstigen Sperenzchen. Und das geht derzeit (vernünftig) nur mit Delphi, mMn.

Danke für diesen wertvollen Beitrag. Ich finde auch, dass man mit Delphi mit am besten Windows Desktop Anwendungen erstellen kann.
Das macht aber den erzeugten Code des Delphi Compilers nicht besser, den man nun mal auch für andere Anwendungen benutzen kann, wo es auf optimale Nutzung aktueller Hardware ankommt.

[TiGü]

Bei so Sprachvergleichen muss man aber auch immer aufpassen, was und wie und womit man vergleicht.
Wenn man ein Konstrukt aus Sprache A nach Sprache B umschreibt und dann den Performance-Vergleich fährt, dann ist das nicht immer die optimale Lösung in Sprache B.
Dieser 10 Jahre alte Artikel zeigt es anhand eines Sortier-Beispiels (C++ vs. C#):
http://journal.stuffwithstuff.com/20...c-performance/

Das kennt doch jeder von euch:
Ihr habt ein Stück Pascal-Quelltext, was jemand mit einem anderen Background (Java, C#, C++) geschrieben hat und ihr denkt euch nur: "Fuck, dass ist aber suboptimal gelöst, dass mach man nach Lehrbuch-Delphi aber besser so und so".

[Stevie]

Zitat:

Zitat von TiGü (Beitrag 1452351)

Bei so Sprachvergleichen muss man aber auch immer aufpassen, was und wie und womit man vergleicht.
Wenn man ein Konstrukt aus Sprache A nach Sprache B umschreibt und dann den Performance-Vergleich fährt, dann ist das nicht immer die optimale Lösung in Sprache B.
Dieser 10 Jahre alte Artikel zeigt es anhand eines Sortier-Beispiels (C++ vs. C#):
http://journal.stuffwithstuff.com/20...c-performance/

Das kennt doch jeder von euch:
Ihr habt ein Stück Pascal-Quelltext, was jemand mit einem anderen Background (Java, C#, C++) geschrieben hat und ihr denkt euch nur: "Fuck, dass ist aber suboptimal gelöst, dass mach man nach Lehrbuch-Delphi aber besser so und so".

Ja, dämliche Benchmarks findet man auch bei Delphi/FreePascal Entwicklern, diese zum Beispiel.

[4dk2]

Zitat:

Zitat von Stevie (Beitrag 1452269)

Kann ich aus den Schnipseln bei mir nicht reproduzieren - und ich geh mal davon aus, dass dein Init static ist, ansonsten wirds eh schwierig, sie aus der static void Main aufzurufen.

Edit: Ah, doch jetzt - ich vermute einfach mal, je nach Konstellation wird man hier bei x86 Opfer von Register Pressure - als x64 läufts immernoch schnell.
Meine Aussage steht aber immernoch obwohl es Situationen gibt, wo man .Net langsam bekommt, ist es in vielen Fällen by default schneller, da besser optimiert - und ich red hier vom Binärcode und nicht von Dingen wie Memorymanagement/GC.

Im test Projekt, für hier, hab ichs auch net mehr hinbekommen, in der main, ist es immer noch reproduzierbar (auszukommentieren).

Und dsmit 32bit/64 bit, sonst heult der kunde, ist nen witz oder?:?::?::?:
es ist aber genauso machbar mit c#...

[MichaelT]

Seit wann war außer Ctrl + F9 Delphi schneller als 3 bis 5 Minuten Compilierung in einer C/C++ IDE. Der Executable Code bei entsprechender Optimierung unter Annahme der Knappheit von Ressurcen gut mithalten. Aber schnell von Geil auf Optimieren war nie.

Das spielt viel eher die Auslastung des L2 Cache mit. Berechnungen habe ich früher auch auf die Oracle geschickt und das Ergebnis zurückgeholt. Das war schon immer schneller als im Executable gerechnet. Ok. Zumindest in einem Teil der Fälle.

-

Warum soll ein JIT Compiler langsamer sein?

Fahre mal im ABAP Floating Point Berechnungen (purstes MS C, wenn überhaupt im Unterbau).

Die Sequenz ist am schnellsten und kann losgelöst vom Kompilat optimiert werden. Finde einen geschlossen Ausdruck zu einem Quantor. Sobald du die Beschränkungen kennst hast du in der Regel gewonnen. Die Laufzeitumgebung muss die Wertebelegung kennen.

Aus der DB Welt ein Vergleich. Wenn man einen Execution Plan einer Query anschaut, könnte man glauben man wüsste was passiert. Seit spätestens 2009 ist besser die Statements auf einer Oracle im Betrieb zu tracen. Die macht schon lange nicht mehr was der Entwickler der Query glaubt und was ihm im Execution Plan angezeigt wird. Man kann eigentlich nurmehr die gröbsten Patzer im Vorfeld vermeiden.

Ein Laufzeitsystem basiert auf brutal optimierten Systemprimitiven.

Einen statischen Compiler nimmt man dann wenn man 100%ig sicher sein will, dass die Ressourcen im Sinne des eigenen Programms verwendet werden und nicht anders. Bei C/C++ Compilern gestaltet sich das dann so, dass bei einer Dissassembly wenig am vermuteten Platz findest.

--

An sich ist in einer (klassischen) prozeduralen Programmiersprache vorzüglich geschlossene Formen zu verwenden (Formeln abzuleiten). Inhalte von Prozeduren sollten komplexer Natur sein und der Ablauf tunlichst starr und im Rahmen vom im Programm definierten explizit definierten Begrenzungen laufen.

Ansonsten musst/kannst du etwas anderes nehmen. Früher als die Compiler aufkamen wurden diese Beschränkung als Segen empfunden, aber mit den Jahrzehnten hat sich das gewandelt. Sinn war die Abbruchstelle genau zu identifizieren. Bei frühen OSen auf einem host ist das Assembler Programm einfach mal mit einem Dumpf geflogen und was das OS (im PC Slang die Anwendung die eigentlich ein ganzer Host Computer im Single User Mode ist) so machte, ...

Die isolierte Runtime welche mit dem OS (Rechenzentrum) die Ressourcen verhandelt liegt auf der Hand.

C#/.net ist in Relation zu anderen Alternativen auch schon auf höchst flexiblem Unternbau mit der Kirche ums Kreuz gelaufen.

Wenn man hingegen bspw. eine Funktion im math. Sinne schreibt, dann können prozedurale Sprachen wieder mithalten. Öffne einen Stream und behandle jeden Wert einzeln. Es handelt sich im Gegensatz zum 'verbreiteten' Wissen um ein wohldefiniertes mathematisches Konstrukt und nicht eine 'hyper' anmutende Form Files einzulesen.

Es macht keinen Sinn mit Bezug auf Prozeduren und Methoden die 'eine' Stelle zu suchen. Eine Objekt ist schon ein instantiiertes Modul. Bei der Vererbung wird genau das eine 'gedanklich' gelandene Modul gesucht und in prozeduralen Sprachen als C gab es nur Files und keine Module usw... Die Notlösung ist inline.

Sobald man sich an das so ca. halt werden bis auf C ohne externe I/O alle Programmiersprachen relativ gleich schnell unter der Annahme, dass die Laufzeitumgebung die Performance zulässt.

Zitat:

Zitat von 4dk2 (Beitrag 1451757)

Moin zusammen,
Hauptsächlich programmier ich zwar nur noch mit C#,
...

Ich finde das extrem krass!
Ich hätte ja gesagt, wegen JIT Code vs Native, wäre da Delphi wahrscheinlich schneller, bzw gleichauf.
aber 4x langsamer?
Was meint ihr dazu?

[ErArz]

Zitat:

Zitat von Sherlock (Beitrag 1452285)

Ich schieße mal knapp vorbei, und schreibe, worauf es meinen Kunden ankommt: Ich liefere eine Exe aus, fertig. Kein Installer nötig. Ich baue dennoch einen, aber der erkennt halt 32Bit oder 64 Bit und legt die passende Exe ins passende Verzeichnis ab, das ginge auch von Hand. Monolithische Exen ohne Framework-Abhängigkeit bringen die Augen der IT meiner Kundschaft zum Leuchten manchmal auch Tränen der Wehmut und Dankbarkeit. Das geht weder mit Java, noch mit .net noch mit dlls oder sonstigen Sperenzchen. Und das geht derzeit (vernünftig) nur mit Delphi, mMn.

Sherlock

Das stimmt schlicht und ergreifend nicht, das geht sowohl mit Java als auch mit .Net! Beide haben die Möglichkeit Self-Contained-Applications zu erstellen bei der die Runtime und alles was das Programm braucht mit in die .exe compiliert wird. Bei .Net hast du sogar mit .Net Native die Möglichkeit direkt Maschinencode zu compilieren.

[ErArz]

Zitat:

Zitat von Stevie (Beitrag 1452290)

Zitat:

Zitat von Sherlock (Beitrag 1452285)

Ich schieße mal knapp vorbei, und schreibe, worauf es meinen Kunden ankommt: Ich liefere eine Exe aus, fertig. Kein Installer nötig. Ich baue dennoch einen, aber der erkennt halt 32Bit oder 64 Bit und legt die passende Exe ins passende Verzeichnis ab, das ginge auch von Hand. Monolithische Exen ohne Framework-Abhängigkeit bringen die Augen der IT meiner Kundschaft zum Leuchten manchmal auch Tränen der Wehmut und Dankbarkeit. Das geht weder mit Java, noch mit .net noch mit dlls oder sonstigen Sperenzchen. Und das geht derzeit (vernünftig) nur mit Delphi, mMn.

Danke für diesen wertvollen Beitrag. Ich finde auch, dass man mit Delphi mit am besten Windows Desktop Anwendungen erstellen kann.
Das macht aber den erzeugten Code des Delphi Compilers nicht besser, den man nun mal auch für andere Anwendungen benutzen kann, wo es auf optimale Nutzung aktueller Hardware ankommt.

Der Beitrag ist weder Wertvoll noch stimmt die Aussage Java / .Net könne keine Monolithische Exen ohne Framework-Abhängigkeit erstellen.