AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Delphi Performance Vergleich zu C#

Ein Thema von 4dk2 · begonnen am 22. Nov 2019 · letzter Beitrag vom 5. Dez 2019
Antwort Antwort
Seite 4 von 5   « Erste     234 5   
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
3.626 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#31

AW: Delphi Performance Vergleich zu C#

  Alt 27. Nov 2019, 11:23
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.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight

Geändert von Stevie (27. Nov 2019 um 11:32 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Sherlock
Sherlock

Registriert seit: 10. Jan 2006
Ort: Offenbach
3.357 Beiträge
 
Delphi 10.3 Rio
 
#32

AW: Delphi Performance Vergleich zu C#

  Alt 27. Nov 2019, 13:17
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
Geändert von Sherlock (Morgen um 16:78 Uhr) Grund: Weil ich es kann
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer
Online

Registriert seit: 13. Aug 2002
Ort: Oberreichenbach
16.537 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#33

AW: Delphi Performance Vergleich zu C#

  Alt 27. Nov 2019, 13:31
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.
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
3.626 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#34

AW: Delphi Performance Vergleich zu C#

  Alt 27. Nov 2019, 14:39
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.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
TiGü

Registriert seit: 6. Apr 2011
Ort: Berlin
2.211 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#35

AW: Delphi Performance Vergleich zu C#

  Alt 28. Nov 2019, 10:14
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".
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
3.626 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#36

AW: Delphi Performance Vergleich zu C#

  Alt 28. Nov 2019, 11:23
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.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
4dk2

Registriert seit: 4. Sep 2007
170 Beiträge
 
#37

AW: Delphi Performance Vergleich zu C#

  Alt 28. Nov 2019, 21:36
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#...
  Mit Zitat antworten Zitat
MichaelT

Registriert seit: 14. Sep 2005
Ort: 4020 Linz
508 Beiträge
 
Delphi 10.3 Rio
 
#38

AW: Delphi Performance Vergleich zu C#

  Alt 29. Nov 2019, 17:46
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.


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?
  Mit Zitat antworten Zitat
ErArz

Registriert seit: 2. Dez 2019
2 Beiträge
 
#39

AW: Delphi Performance Vergleich zu C#

  Alt 2. Dez 2019, 11:28
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.
  Mit Zitat antworten Zitat
ErArz

Registriert seit: 2. Dez 2019
2 Beiträge
 
#40

AW: Delphi Performance Vergleich zu C#

  Alt 2. Dez 2019, 11:30
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.
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 13:38 Uhr.
Powered by vBulletin® Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2019 by Daniel R. Wolf