Delphi vs. C# vs C++

[Daniel]

Zitat von luisk:

Wenn C# inzwischen genauso schnell oder schneller als Delphi ist ?

Die überwiegende Menge an Performance-Problemen, die ich bei Kunden-Projekten bisher finden konnte, war nicht auf die Sprache bzw. deren Compiler zurück zu führen. Ich denke, dass das, was hier "gemessen" wurde für viele (viele != alle) Anwendungen irrelevant ist, weil das schlichtweg nicht der Bereich ist, in dem sie für den Anwender spürbar ausgebremst werden.

[luisk]

Zitat von Daniel:

Zitat von luisk:

Wenn C# inzwischen genauso schnell oder schneller als Delphi ist ?

Die überwiegende Menge an Performance-Problemen, die ich bei Kunden-Projekten bisher finden konnte, war nicht auf die Sprache bzw. deren Compiler zurück zu führen. Ich denke, dass das, was hier "gemessen" wurde für viele (viele != alle) Anwendungen irrelevant ist, weil das schlichtweg nicht der Bereich ist, in dem sie für den Anwender spürbar ausgebremst werden.

Die Frage ist, was spricht noch für Delphi im Vergleich zu C# ?

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

[Mavarik]

Zitat von luisk:

Die Frage ist, was spricht noch für Delphi im Vergleich zu C# ?

34 Jahr Erfahrung mit Pascal/Delphi.
Ein Sourcecode für iOS, Android, Mac, Windows.
Millionen Zeilen Sourcecode der seit Jahrzehnten problemlos funktioniert.
Jegliche innerbetriebliche Software und alle aktiven Projekt in Delphi erstellt...

Die Frage ist... Was hat je für C# gesprochen? Das ständig wechselnde Framework?

[nuclearping]

Zitat von luisk:

Programmiert überhaupt noch jemand Delphi,
oder sind alle zu Microsoft gewechselt ?

Wenn C# inzwischen genauso schnell oder schneller als Delphi ist ?

Deine Frage liest sich wie: Isst hier überhaupt noch jemand Pflaumen, wenn man aus Birnen keinen Apfelmus machen kann?

Andernfalls kann ich mich den Aussagen der meisten hier nur anschliessen: Dein "Vergleich" hat keinerlei Bezug zur Realität oder Praxis. Ich habe Entwickler kennengelernt, die mit Delphi lückenlose Aufzeichnungen und Messungen im Gigabyte- und Nanosekundenbereich durchführen (müssen).

Und in unseren Projekten streamen wir Hardwaredaten über USB, um Messungen und Analysen für >100.000-1.000.000 Proben im Sekundenbereich durchzuführen. Und die Geschwindigkeit des durch den Delphi-Compiler erzeugten Codes war bis dato noch nie ein Problem.

Wer X Millionen Mal einen Button aktualisiert und dann daraus Schlussfolgerungen für das ganze Entwicklungssystem zieht, hat irgendwas nicht richtig verstanden.

Auch wenn die IDE von Embarcaderro nervig ist, ist die Programmiersprache Delphi nach wie vor immernoch mit eine der besten, performantesten und leserlichsten Sprachen auf dem Markt und mit eine der besten RAD-Lösungen.

[mensch72]

Delphi für Windows läuft & läuft.

Delphi(FMX) für CrossPlattform lebt vom Gedanken, das man sich als Entwickler eben möglichst nicht oder eben nur kaum um die System-GUI und die SystemStorage Gedanken machen soll.

C# für Crossplattform gibt es auch einige, nur da muss ich selbst im Design unten die StorageLogic absplitten, dann die "universelle" BusinessLogic portabel programmieren und darüber dann wieder eine Systemspezifische GUI setzen. Das Resultat ist sicher sehr effektiv und sehr nah an nativ, aber nicht das was ich "will". Bei FMX mit UniDac als StorageFramwork geht ~80% portabel, der Rest ist "basteln"... ich kann so damit leben.

Geschwindigkeit... nun ja wer einen "Mod" schnell will, der sollte es binär und in 2er Potenzen machen, also statt Mod 1000 eventuell besser genähert "&0x3ff" oder "and $3ff".

In "DelphiVCL" und "C++" kommt mann wenn es sein muss auch bit basiert noch sehr nah an Hardware heran. In C# oder DelphiFMX sollte man sich nicht primär mit "BitSchubsen" abgeben wollen.

"Geschwindigkeit","Optimieren"...
PC Programmierer sollten lieber "schönen" Code schreiben. Technik wird immer schneller und Speicherplatz kostet quasi nix.
Zufällig programmiere ich auch heute noch 8-Bit MicroControler mit 4KB-RAM und 64KB-Flash/ROM in C und vermeide ASM wo es geht. Der Programmstil ist dort automatisch etwas anders. (Viele Globale Variablen/Buffer zur Vermeidung wiederholter Übergabeparameter, statt for(...) lieber ein do{...}while(--xx) weil es einen 1:1 ASM Ersatz für while(--xx) gibt(DecrementJumpNotZero). Aber am PC mit Delphi oder was weiß ich ist mit sowas egal. Erst ab Giga- oder Terra-Bytes an Daten denke ich da an Speicher/Geschwindigkeit... bis Mega(bytes) ist das heute völlig wurscht.

[redox]

Ohne (wirklich) interessiert mitgelesen/verstanden zu haben:

Weshalb soll Delphi 6 (letztes Jahrtausend) eigentlich mit C# Express 2015 oder C++ (welche Version eigentlich) verglichen werden?

Warum nicht ein aktuelles FPC mit einem aktuellen GnU-C-sonstwas vergleichen?

Und seit wann ist es heute denn nicht mehr kälter als draußen?

Sorry, will nur den Thread noch etwas mehr aufblähen

[luisk]

So, und jetzt noch die ganz gro0e Überraschung,
hab das ursprüngliche Testprogramm jetzt mal mit C# 2008 Express
laufen lassen. Die Release startet dort ganz einfach über "Start ohne Debugging"
( warum die keinen Release-Button spendieren konnten ??? )
Da ist C#2008 nun in 5 Sec durch, und damit sogar 3 mal schneller als Delphi bzw. C# 2015
(und damit 30mal schneller als die eigene C# Debug-Version).
Ups - jetzt seh ich C# mit etwas anderen Augen ! sorry https://de.wikipedia.org/wiki/Anders_Hejlsberg

Code:

        private void button1_Click(object sender, EventArgs e)
        {
            int li = 0;
            int lj = 0;
            double lw = 0.0f;
            double lc = 0.0f;
            for (li = 0; li < 50000; li++)
            {
                for (lj = 0; lj < 1000000; lj++)
                {
                }
                if (li % 1000 == 0)
                {
                    button1.Text = li.ToString();
                    button1.Update();
                }
            }

        }

von wegen, der Code taugt nicht zum Performance-Test

[Sir Rufo]

Ja, C# kann nutzlosen Bloat-Code viel besser wegoptimieren.

Schade, dass es bei mir so wenig davon gibt. Somit ist das für mich leider nicht das Killer-Feature.

[Bernhard Geyer]

Zitat von luisk:

von wegen, der Code taugt nicht zum Performance-Test

Wie schon gesagt: Wer Mist mist, mist Mist.

Hey, WinForms (ich denke mal du hast WinForms-Anwendungen genommen und nicht die auch unter 2015 verfügbaren anderen GUI-Ansätze) aktualsiert sich in einem blödsinnigen unter älteren C#/.NET-Versionen schneller - Mehr hast du nicht gemessen und mehr geben deine Messungen auch nicht her.