Delphi Performance Vergleich zu C#

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