Delphi vs. C# vs C++

[Bernhard Geyer]

Zitat von luisk:

Zitat von Bernhard Geyer:

Das Ergebnis ist das bei blödsinniger permanenten GUI-Aktualisierung (welche die Funktionzeit eh vervielfacht) Delphi schneller diese blödsinnige Permanete GUI-Aktualsierung durchführen kann. Weiter Aussagen zu Performancevergleich Delphi <-> C# lassen sich nicht ableiten.

Wohl übersehen, was dieses li mod 1000 bewirkt?

Delphi-Quellcode:

if (li mod 1000=0) then begin
                   button1.caption := inttostr(li);
                   button1.Update();
       end;

Nein, habe ich nicht! Genau so eine Logik haben/hatten wir hier auch in unserer Anwendung drin.
Wenn aber so ein Mod-Vergleich alle 1 ms kommt ist trotzdem die GUI-Aktualiserung das bremsende Element.
Haben mittlerweile ein Basisklass/Codefragement/Methode das eine "if DelayToLastUpdate > 300ms"-Abfrage drin hat.
Damit wird die GUI nur alle 300 ms aktualisiert (Und erst nach Aktualisierung wird die Vergleichszeit neu gestartet)
Damit habe ich Zeiten für länger andauernde Aktionen teilweise auf 1/5 der ursprünglichen Zeit verkürzen können.

[stahli]

Zitat von luisk:

Wohl übersehen, was dieses li mod 1000 bewirkt

Ich hab Dich ja oben noch in Schutz genommen.
Aber andererseits haben die Kollegen natürlich Recht, dass das Testbeispiel nicht wirklich taugt.
Wenn es auf Performance ankommt, sollte man kein GUI-Refresh dazwischen schieben.
Wenn man dies macht, kann einem die Performance nicht so wichtig sein.

Also Deine Anforderungen sind da nicht wirklich klar.
Was willst Du denn eigentlich erreichen?

[Bernhard Geyer]

Zitat von stahli:

Also Deine Anforderungen sind da nicht wirklich klar.
Was willst Du denn eigentlich erreichen?

Gute Frage. Solche Aufgaben/Anforderungen kommt mir verdächtig nach
"Wir haben schon immer mit Delph/C/Java/..." gemacht und jetzt sollen wir was anders machen. Schnell mal schauen ob wir Killerargumente finden".

[Bernhard Geyer]

Vor einiger Zeit (mehrer Jahre) gabs mal 2-3 Artikel bezüglich Performancevergleich C/C++/Java/C# und Delphi.

Ergebnis war:

Im "Number-Crunshing" ist C/C++ vorne
In "normalen" Entwickeralttag (Objektorientierte Programmierung, Ableitung, Überladen von Methoden, ...) sind Delphi/Java/C# ähnlich schnell.
C++ war hier der "einsame" Verlierer.

[BUG]

Zitat von Bernhard Geyer:

C++ war hier der "einsame" Verlierer.

Hu, wirklich? Da würde ich gerne mal was genaueres drüber lesen.

Zitat von Bernhard Geyer:

Damit habe ich Zeiten für länger andauernde Aktionen teilweise auf 1/5 der ursprünglichen Zeit verkürzen können.

Da gab es mal was schönes in Gamasutra: Don't Sync and Load.

[Bernhard Geyer]

Zitat von BUG:

Zitat von Bernhard Geyer:

C++ war hier der "einsame" Verlierer.

Hu, wirklich? Da würde ich gerne mal was genaueres drüber lesen.

http://www.heise.de/artikel-archiv/c...el-Duesentrieb
http://www.heise.de/artikel-archiv/c...el-Duesentrieb

[BUG]

Zitat von Bernhard Geyer:

http://www.heise.de/artikel-archiv/c...el-Duesentrieb
http://www.heise.de/artikel-archiv/c...el-Duesentrieb

Vielen Dank fürs Raussuchen, so weit reicht mein Archiv leider noch nicht zurück. Werde mir noch überlegen, ob ich für nen 12 Jahre alten Artikel 3,50€ ausgeben möchte
Irgendwann muss ich mir mal das komplett-Archiv holen ...

[MichaelT]

Der Faktor 10 ... Nein. Tut mir leid . Deckt sich nicht mit der Erfahrung. Möglw. hast du den Code ob der Größe zufällig in einem Cache im Prozessor. Du kannst wenn du willst den generierten Code vergleich was vermutlich bei einem Vergleich mit .net schwer wird. Delphi 64bit ist sicher nicht langsam und Delphi 32bit eigentlich auch nicht.

Einzig wirklich langsam ist der Extended Datatype in 32bit. Es gibt JVMs die können noch Erfahrung zur Laufzeit mitberücksichten. .net hat das soviel ich weiß nicht. Es haben sich aber auch die Hoffnungen nicht erfüllt mit einer Kombination aus JIT und Vorhersagen einen gewaltigen Speedup zu holen. Das ist allein bei Riesensystemen sinnvoll, wobei weder Java noch .net Assemblies zur Laufzeit können (im Sinne eines Modules in einem Server). JVM kommt schon hin in diese Richtung - das wurde auf der Uni Linz im Oracle Lab entwickelt.

Der mkinzler hat einen recht netten Test gemacht. JVM auf Linux ist so schnell wie .net unter Windows... Allein JVM unter Windows lässt ein wenig aus. Wenn man managed vs. unmanaged vergleicht im Benchmark dann darf man am Ende den Speicher nicht freigeben. Da ging es hart zur Sache mit Vergleichen und Objekte anlegen usw...

Du holst ungemanaged ca. eine Verdopplung raus. Das war eher zu Zeit der Dual Cores.

Der ABAP Prozessor ist bezüglich Floating Point ganz gut drauf, da können sie C# und Java ein Scheibchen abschneiden. Bei Java hängt die Sache wieder auf der JVM die verwendet wird. Alles andere und Floating Point kann man was Scripting angeht vergessen sofern nicht eine Funktion im puren C implementiert wird. GCC unter Linux ist etwas schneller als der MSC++ auf Windows ... Das ist kaum mehr vergleichbar.

Das Java ist ja im Businessbereich einfach beliebt, das es so restriktiv ist und teils sehr expressiv - Beispiel ... der 'Zwang' eine Exception zu handeln usw...

Gemanaged war damals (ist schon ein Weilchen) her halb so schnell. Du holst mit handoptimierten Code je nach Anwendung mit MS C/C++ fast das Optimum, selbst der Einsatz von einem Intel Compiler bringt grad mal 40 Speedup. Ein Freund von mir hat sich mal die Mühe gemacht und das war damals notwendig für eine Optimierung sich in Managed C++ multidimensionale Collections zu bauen. Der Grund warum er C++ brauchte war, da er die Antwortzeit unter den Bereich des Merkbaren wollte absenken. 2 Sekunden pro Planungslauf vs. 0.8 sec. Aber der Unterschied zur Optimierung die beim Kunden zuvor Nächte lief war, das Eliminieren von vermeintlichen Einflussfaktoren. Dann hat man 4 Stunden (Simulationssystem) vs. 20 Sekunden im ersten Schritt (C#), Optimierung von C# Code und Neustrukturierung (2-3 Sekunden) und am Ende eben den Umbau des Datencashes auf managed C++. Mit der Kürze der der Laufzeiten ändert sich die Architektur.

Erinnert so an ein anderen Bekannten der mal einfach ein File Diff gemacht hat und von 60k Zeilen bei Planungsläufen blieben pro Änderung so ca. 20 bis 200 Zeilen übrig und die wurden ins Data-Warehouse eingebucht.

Ich habe mich mal gespielt mit dem Heap. Eine 8GB Maschine unter Win32 und ein Baum mit 9 mit 9stelliger Knotenanzahl. (Mit dem Patch für Win7/32) damit man 4GB Adressraum schafft und die Maschine den gesamten Speicher kann nutzen, der war auf 8GB begrenzt. Einfach Operationen auf eine balancierten AVL Baum ... . Viel Unterschied ist nicht.

Delphi Floating Point 64bit ist relativ schnell in Kombination mit Schleifen. Memory je nachdem. Das spielt dann alles zusammen. Delphi ist bestimmt nicht langsam. Es kommt halt dann draufan wie man sich den Speicher vom Windows holen lässt ...

Was ist der Grund. Schleifen sind Quantoren und damit lassen sie sich im Regelfall auf geschlossene Formen (Formeln) transformieren. (Paule, Schorns Implementierung des Gosper Algorithmus).
http://www.risc.jku.at/research/comb.../fastZeil.html

Zitat von luisk:

[/CODE]

Ergebnis: Delphi ist 10 mal schneller als C#
Kann jemand Angaben zu C++ machen ?