Hallo,

in der vergangenheit wurde auch hier oft die Frage gestellt, ob Delhi langsamer sei als andere Sprachen. Die ct hat jetzt die eindeutige antwort gefunden.
Leider lautet sie Ja. Ich dachte mir, das das auch den einen oder anderen von euch interessieren könnte (die ct-Ausgabe müsste bis zum ende dieser Woche noch am Kiosk sein).
Eigentlich ging es im Artikel "Daniel Düsentrieb", von Arne Schäpers & Rudolf Huttary, welcher auf den Seiten 204ff der ct 19.03 veröffendlicht wurde darum, wie Schnell C# bzw. .NET Anwendungen sind. Hierzu wurden ein paar Tests in Konkurren zu M$-C++, Java und Delphi gefahren.

In einigen Anwendungsgebieten mus Delphi sogar hinter Java anstehen. Mehr als einen 2 Platz ereicht Delphi in keinem Test aber diser ist sehr selten.

Hier ein paar Beispiele aus den Abbildungen auf den Seiten 206 & 207 (angaben jeweils für den Relase Mode in Sekunden auf einem Athlon mit 1GHz):

ct hat folgendes geschrieben:

Einfache Schleifen Empty Loops: C#: 3,0s C++: 0,0s Java: 5,0s Delphi: 2,0s Calc Loops: C#: 2,0s C++: 0,0s Java: 4,0s Delphi: 2,0s Real Calc Loops: C#: 6,0s C++: 5,0s Java: 7,1s Delphi: 6,0s Integer-Arithmetik RSABrute: C#: 20,0s C++: 12,0s Java: 19,0s Delphi: 57,0s RSARekursiv: C#: 77,7s C++: 49,0s Java: 54,2s Delphi: 74,4s

Die verwendeten Quelltexte könnt ihr hier runterladen.

Hierbei ist zu beachten, das bei Java und C# die Zeitmessung auch erst nach der (JIT) Compilierung beginnt. Dennoch finde ich, das Borland sich dabei nciht mit Ruhm bekleckert hat (was aber wenn ich mich recht entsinne auch bei Turbo Pascal schon so war. Compiliergeschwindigkeit hevoragend, Laufgeschwindigkeit Mäßig).

Gruß
Klabautermann

Ich denke, dass Geschwindigkeit alleine nicht dass ausschlaggebende sein kann und auch nicht ist - denn die meiste Zeit wartet der Puter sowieso auf die Eingaben des davorstehenden-sitzenden meist organisch aufgebauten Individuum.

Ich hab schon alles probiert, C, C++, Java, ASM und bin bei D geblieben. Warum ? Alleine die Zeigerarithmetik unter C ist grausam. Delphi erkauft sich vielleicht 0.000.. Promille Geschwindigkeitsbremse durch etwas "Benutzerfreundlichkeit" in einigen Dingen.

Die wichtigste Frage ist doch, welches Programm besteht aus solch komplexen Rechenoperationen? Realtimeanwendungen werden imho doch sowieso nicht mit D entwickelt.

grez
msch

hauptsache schneller als der C# Müll von M$ !

Zitat:

hauptsache schneller als der C# Müll von M$ !

Könntest du bitte erklären, warum C# Müll sein soll? Ich finde diesen Sprachen-"Krieg" so lächerlich. Warum immer auf eine Sprache setzen. Warum denn nicht einfach die Vorzüge der jeweiligen Sprachen für seine Probleme benutzen und einfach diese Vorzüge anerkennen, anstatt dauern zu sagen "Delphi ist aber besser!!!". Ich will damit jetzt keinen direkt ansprechen, aber in IRC-Channels artet das wirklich auch schon aus. Einer kommt in den Channel, fragt nach einer Lösung für Delphi und prompt kommt dann einer und sagt "vergiss das scheiß Delphi, nimm C". Dann kommt der nächste etc...

Hab den Artikel gerade auch gelesen, aber ich muss sagen, dass man daraus nicht unbedingt schließen kann, dass Delphi langsamer ist als andere. Es hat (wie auch in dem Artikel erwähnt wurde) nur 2 Probleme:

1. Ist die Optimierung nicht so sehr auf den Code selber eingestellt. VC kürzte ja die leeren Schleifen ersatzlos weg, deshalb dieses Ergebnis, sonst war es nicht viel langsamer als C++
2. Ist die Implementierung des Int64 nicht gut gelungen, sagen wir es richtig: Sie ist Mist. Aber wer braucht für normale Anwendungen im Moment den 64-Bit-Int? Ich habe ihn einmal gebraucht, mehr nicht. Und bis dahin, hat Borland das Problem auch in den Griff gekriegt

Alles in allem würde ich sagen, dass der Test in Richtung Delphi etwas unfair war, aber das war ja eigentlich auch nicht das Thema. Warten wir erstmal den 2. Teil mit der Objekt-Orientierung ab und dann können wir weiterdiskutieren

Hallo,

UGrohne hat folgendes geschrieben:

Hab den Artikel gerade auch gelesen, aber ich muss sagen, dass man daraus nicht unbedingt schließen kann, dass Delphi langsamer ist als andere.

die ctler räumen ja auch ein, das ihre Programme keine "echten" Benshmarks sind, aber wenn etwas wie:

nicht als nutzlos erkannt und wegoptimiert wird ist das schon Peinlich (weder x, noch y noch z werden später verwendet).

UGrohne hat folgendes geschrieben:

Es hat (wie auch in dem Artikel erwähnt wurde) nur 2 Probleme: Ist die Optimierung nicht so sehr auf den Code selber eingestellt. VC kürzte ja die leeren Schleifen ersatzlos weg, deshalb dieses Ergebnis, sonst war es nicht viel langsamer als C++

Siehe oben . Bei der CalcLoop finde ich das vorgehen von C++ zwar genial aber überflüssig, bei der leeren ist es aber die einzig wirklich sinvolle Variante.

UGrohne hat folgendes geschrieben:

Ist die Implementierung des Int64 nicht gut gelungen, sagen wir es richtig: Sie ist Mist. Aber wer braucht für normale Anwendungen im Moment den 64-Bit-Int? Ich habe ihn einmal gebraucht, mehr nicht. Und bis dahin, hat Borland das Problem auch in den Griff gekriegt

Ja die ist misst, ich hoffe das Delphi da eine besser spendiert wird wenn es auch 64Bit Windows Systeme losgelassen wird (ist eigentlich sehr warhscheinlich) wenn die Borländer es dann nciht zur reinen .NET Sprache machen.

UGrohne hat folgendes geschrieben:

Alles in allem würde ich sagen, dass der Test in Richtung Delphi etwas unfair war,

Wieso? Was wurde denn da gemacht, das Delphi benachteiligte?

UGrohne hat folgendes geschrieben:

Warten wir erstmal den 2. Teil mit der Objekt-Orientierung ab und dann können wir weiterdiskutieren

Ja, den erwarte ich auch mit Spannung. Aber meine Glaskugel sagt mir, das C# dort am besten abschneiden wird, gefolgt von Java und mit C++ & Delphi auf den Plätzen 3&4. Warum? Weil die Beiden erstgenannten Konzepte als OOP Sprachen gebohen sind, während C++ und Delphi sich erst zu diesen entwickelt haben und deshalb viel ballast von C und Pascal mitschleppen werden, der sie da behindert. Aber vieleicht (hoffendlich) irrd sich meine Glaskugel da ja auch.

Gruß
Klabautermann

Hi!

Bitte schön, wen interessiert denn Geschwindigkeit? Etwa Windows-User?

Spass beiseite:

Zitat:

die ctler räumen ja auch ein, das ihre Programme keine "echten" Benshmarks sind, aber wenn etwas wie: Sourcecode: for x := 1 to 1000 do for y := 1 to 1000 do for z := 1 to 1000 do ; nicht als nutzlos erkannt und wegoptimiert wird ist das schon Peinlich (weder x, noch y noch z werden später verwendet).

Hmmm, ich finde, es ist peinlich, so einen Code in seinem Programm zu hinterlegen.
Die Optimierung findet ja bei der Compilierung statt, und nicht etwa zur Laufzeit, sprich : das Programm erkennt ja nicht, ob irgendeine Schleife gerade in einer gewissen Situation keinen Sinn macht.

Auf den OOP-Teil bin ich auch gespannt. Delphi hat ja dort einen ganz tollen Vorteil gegenüber C++, nämlich Properties. C# hat sie denn dann auch gleich mitimplementiert.

Cu,
Udontknow

Udontknow hat folgendes geschrieben:

Hmmm, ich finde, es ist peinlich, so einen Code in seinem Programm zu hinterlegen.

Sicherlich aber wenn die Optimierung bei solch offensichtlichen Dingen nicht greift, wie soll es denn bei subtieleren Dingen funktionieren?
Nutzlose Variableniitialisierungen entfernet Delphi ja auch.

Udontknow hat folgendes geschrieben:

Die Optimierung findet ja bei der Compilierung statt, und nicht etwa zur Laufzeit, sprich : das Programm erkennt ja nicht, ob irgendeine Schleife gerade in einer gewissen Situation keinen Sinn macht.

Aber es sollte erkennen, wen es keine Situation gibt in der die Konstruktion Sinn macht, in diesem Fall einfach aufgrung der Tatsache, das die Zählvariablen nirgendwo anders verwendet werden und die innere Schleife völlig leer ist.

Naja, ich finde das ganze auch nicht so dramatisch wie es sich vieleicht anhört. Denn die geschwindigkeit (besonders die schlechte ) kommt durch den Code, den der Programmier erzeugt, die Optimierung kann ohnehin nichts retten wenn der Programmierer murks macht, aber wenn er gute Arbeit leistet, sollte sie noch für das Sahnehäubchen liefern.

Gruß
Klabautermann

Moin erstmal!

Klabautermann hat folgendes geschrieben:

Compiliergeschwindigkeit hevoragend, Laufgeschwindigkeit Mäßig).

Also mich als Entwickler interessieren vor allem die Compilergeschwindigkeiten sowie eine gute GUI

Gruß Renegade

Klabautermann hat folgendes geschrieben:

Udontknow hat folgendes geschrieben: Hmmm, ich finde, es ist peinlich, so einen Code in seinem Programm zu hinterlegen. Sicherlich aber wenn die Optimierung bei solch offensichtlichen Dingen nicht greift, wie soll es denn bei subtieleren Dingen funktionieren? Nutzlose Variableniitialisierungen entfernet Delphi ja auch. Gruß Klabautermann

Hmm, wobei hier ein grosser Unterschied besteht !

Eine leere Schleife muss nicht nutzlos sein, sondern kann für einfach verzögerungseffekte herhalten. Was erlaubt sich ein Compiler diese weg zu optimieren ? Dies ist für mich keine optimierung sondern eine Veränderung denn der Compiler kann wirklich nicht wissen ob die Schleife 'vergessen' wurde oder ob sie bewusst da ist. Wenn schon dann bitte eine Compilerwarning und optionale Wegoptimierung, aber dann kann ich den Kram auch einfach aus den Quelltext löschen.

Was 'vergessene' bzw. rudimetäre Variablen angeht sieht die Sache anders aus. Da diese keinerlei auswirkung auf den Code haben können sie einfach gestrichen werden.

Verzögern mit Schleifen? Dann verzögerst du auf einem 386er um ein Vielfaches des Zeitraumes, den ein 3GHz-Rechner braucht.

Verzögert wird mit Delay, Sleep oder sonst irgendeiner Betriebssystem-Funktion, aber nicht mit leeren Schleifen.

Leere Schleifen haben meiner Ansicht nach nirgends etwas zu suchen.

Cu,
Udontknow

Bewerten wir doch mal die Geschwindigkeit mit der man eine Datenbankanwendung mit entsprechnder GUI entwickeln kann. Da ist Delphi wirklich spitze. Es kommt nicht so sehr auf die Sprache an sich an, sondern auf die Komponenten die es dafür gibt. Allein die Borland Delphi Standardkomponenten sind spitze.

Udontknow hat folgendes geschrieben:

Verzögern mit Schleifen? Dann verzögerst du auf einem 386er um ein Vielfaches des Zeitraumes, den ein 3GHz-Rechner braucht.

Darauf kommt es nicht an.Genauso ein Schrott ist es zu sagen C++ ist schneller weil es die Sache wegoptimiert. Damit zerstört es aber auch einfach den Code. Das ist nicht was ein Copiler tun sollte. Hatte einige male Probs mit Delphi 4 und der Codeoptimierung, der hat mir den ganzen Code kaputt gemacht, konnte ich nur dadurch beheben das ich die Codeoptimierung ausgeschaltet habe.

Es ging mir eher ums Pronzip. Die Maschine darf IMHO den Code nicht selbst verändern. Dann werden wir irgendwann nurnoch von Maschinen bestimmt

@ak
Full ACK.

In dem Artikel warnen die Autoren ja ausdrücklich davor, die Ergebnisse zu ernst zu nehmen. Die Vergleiche erlauben denn auch eher Rückschlüsse darauf, wie die jeweiligen Compiler mit dem Code umgehen, als direkte Geschwindigkeitsvergleiche anzustellen. Zu dr Meinung "Sch***-C#" kann ich nur sagen, dass ich das nicht teile. Allein schon der Autor des Sprachkonzeptes von C# sorgte dafür, dass man sich als Delphi-Programmierer hier viel eher heimisch fühlt, als bei C++ .

Und nichts ist nur deswegen schon sch****, weil es von Microsoft stammt - auch wenn die Qualität der Microsoft-Produkte nicht ihrer Marktbedeutung entspricht.

Mit solchen Vergleichen, wie sie die "c't" veröffentlicht, kann man aber (manchmal) erkennen, mit welchen Konstruktionen seine Lieblingssprache besser umgehen kann.

Ich muss sagen, dass ich C# sehr elegant und angenehm zu programmieren finde. Besonders das Überladen von Operatoren für eigene Objekte finde ich Klasse. Und auch sonst macht es einfach Spaß, damit zu arbeiten.

Und solche Tests wie die der c't sind zum einen dann sinnvoll, wenn man bei einem Projekt entscheiden will, welche Programmiersprache man verwenden will (bei Datenbanken wahrscheinlich eher Delphi, bei aufwändigen Berechnungen wohl eher C++) und zum anderen für die Entwickler der Programmiersprachen, die sehen, wo sie noch dran arbeiten müssen.

MfG
Peter

Hm. Bei einem Primazahlrechner den wir mal bei einem Delpher_Treffen gemacht haben, war die C++-App eindeutig langsamer fast um 25%. Bei der 3D-Programmierung komme ich auf gleiche Ergebenisse. Werde mal die "Benchmarks" nicht in Frage stellen, aber in der Praxis scheint es keine Bedeutung zu haben...

Phobeus hat folgendes geschrieben:

Hm. Bei einem Primazahlrechner den wir mal bei einem Delpher_Treffen gemacht haben, war die C++-App eindeutig langsamer fast um 25%.

als die Delphi Version?
Kannst du mal die Quelltexte, posten, währe interessant.

Zitat:

Bei der 3D-Programmierung komme ich auf gleiche Ergebenisse. Werde mal die "Benchmarks" nicht in Frage stellen, aber in der Praxis scheint es keine Bedeutung zu haben...

Dafür sind sie auch noch zu Homogen. Leider schein der Artiken in der neuen Ausgabe ncoh nicht fortgesetzt zu werden (oder ich habe ihn übersehen). Daher müssen wir uns wohl noch 2 Wochen gedulden bevor wir die Daten zum OOP Handling bekommen.

Gruß
Klabautermann

Mal eine kurze Zwischenfrage, nicht unbedingt jetzt diese Benchmarks betreffend... anscheinend is das c't ja ganz gut... weiß jemand ob/wo man das in Österreich/Wien bekommt? Hab das noch nie irgendwo gefunden...

Habe mir jetzt auch noch mal den Artikel durchgelesen.

Ich denke nicht, daß man nun sagen sollte, Delphi ist langsamer. Die ersten zwei Tests sind zu ignorieren, da es nicht wirklich die Performance der Compiler, sondern ihre Fähigkeit, sinnlosen Code zu entfernen, darstellt.

Dabei sollte, wie ich schon oben mal bemerkte, jeder halbwegs ordentliche Programmierer solche Situationen nie entstehen lassen (Zitat ct: "Die anderen Sprachen... setzen also eher auf eine gewisse Eigenintelligenz des Programmierers").

Beim Real-Calc-Loop-Test sind sich ja Delphi und C++ fast ebenbürtig, mit 2,3s ist Delphi nur eine Zehntel-Sekunde langsamer.

Gut, die Integer-Arithmetik ist aus den bereits benannten Gründen für Delphi nicht gerade ein Sieg auf ganzer Linie. Aber wann setzt man denn schon Int64 ein? Die Fälle, wo ein Integer nicht mehr ausreicht, sind recht selten...

Für mich stellt sich der gesamte Bericht gar nicht so negativ für Delphi heraus, wie ich es beim ersten Lesen von Klabautermanns Beitrag dachte.

Die Ct-Redakteure schreiben übrigens, daß bei einem ersten Test mit einem kompletten Programm, wo die OOP gefordert wird, C++ stark einbricht( Zitat ct:" Zumindest bei dem ersten bereits fertig gestellten Programm einer, hierarchischen Listenverwaltung, sieht C++ auf einmal ziemlich alt aus - und das nicht etwa, weil wir es drauf angelegt hätten").
Da bin ich auf den Vergleich mit Delphi gespannt.

Cu,
Udontknow

@klabateur: Bezweifele, dass ich den Code noch zu Hause habe. Werde aber gerne mal nachsehen. Interessant dabei fand ich, dass die Geschwindigkeit von einfachen Rechenoperationen scheinbar mit jeder neueren Delphi-Version langsamer wurden. Das schnellste Ergebnis lag damals bei einem D4 vor.
Bevor jemand sowas nachmacht, denkt bitte daran ein OS zu nehmen, dass nicht im Hintergrund arbeitet, sowas kann das eine oder andere Testergebnis gründlich versauen.