Warum delphi lahmer als c++?

[jmd anders]

Alle sagen ja, dass c++ schneller sein soll als delphi, dabei frage ich mich, in welchen fällen das zutrifft.
Also bei welchen Schleifen oder sonstigen Anweisungen ist delphi lahmer?

Des weiteren wollte ich wissen, warum dies so ist. Beides wird ja nach asm übersetzt, warum erzeugt der delphi compiler "schlechteren" assembler code?

[mkinzler]

Es gab vor einiger Zeit mal ein Test in der c't. Darin war Delphi teilweise schneller als c++.

[Bernhard Geyer]

Zitat:

Zitat von jmd anders

Alle sagen ja, dass c++ schneller sein soll als delphi, dabei frage ich mich, in welchen fällen das zutrifft.

Alle sagen ja das Java langsam ist aber ich kenne mindestens ein Beispiel indem eine Java-Implementierung viel schneller als eine C/C++-Implementierung ist

Zitat:

Zitat von jmd anders

Also bei welchen Schleifen oder sonstigen Anweisungen ist delphi lahmer?

So einfach kann man einen Vergleich nichts machen.

Zitat:

Zitat von jmd anders

Des weiteren wollte ich wissen, warum dies so ist. Beides wird ja nach asm übersetzt, warum erzeugt der delphi compiler "schlechteren" assembler code?

Schon mal überlegt wieviel unterschiedliche Instruktionserweiterungen und Prozessortypen es gibt. Und jeder will seine Instruktionsreihenfolge haben damits schnell geht. Und für C++ gibt es Hunderte wenn nicht gar tausende Ingenieure die für jeden Prozessortyp einen neuen Compilerschalter erfinden um für den Prozessor xyz das Optimum herauszuholen. Delphi erzeugt dagegen (mit der Codebasis von Borland) "Einheitsbrei" welcher nur für "normale" Pentiums gute Performance erziehlt aber nicht die neuesten Tricks von Core (2) Duo kennt.

Aber diese Optimierungen sind eigentlich vernachlässigbar wenn die Programmlogik nicht passt. Man kann mit hochoptimierten C++-Code langsameren Code erzeugen als z.B. mit VB (noch kein .NET) wenn der Algorithmus und die Programmlogik nicht passt.

In einem Artikel der Zeitschrift c't wurden mal ein Vergleich gemacht:

a, Reines Nummer-Crunshing: Dort ist C++ einsame Spitze. Nirgends kann man (sinnlose) Schleifen so gut optimieren wie unter C/C++

b, Objektorientierte Konzepte wie Vererbung, Methoden-Überladung etc: Hier ist das Sprachkonzept das hinter C/C++ steckt nicht sehr optimal so das sowohl Delphi und C# als auch Java hier die Nase vorne haben.

[Nils_13]

Bernhard Geyer kann ich da nur zustimmen. Man muss aber auch dazusagen, dass wir uns hier in ganz anderen Dimensionen bei diesen Vergleichen bewegen und der Unterschied zwischen Delphi und Cpp nicht gerade groß ist (wir spüren ihn oft garnicht, falls er überhaupt existieren sollte). Ich arbeite mit beiden Sprachen und bin mit beiden zufrieden, weil beide eine gute Geschwindigkeit haben. Für objektorientierte Programmierungs sollte man C++ aber wirklich nicht benutzen, das ist mit Delphi schon einfacher. Ich habe von meinem Bruder gehört (muss wegen Studium Java machen), dass er Java mitlerweile gut findet, weil es garnicht so lahm ist, wie es immer gesagt wird.

Nachtrag: Die Codeoptimierung von Delphi schafft manchmal Codes, die ein Mensch nicht hinbekommen würde :mrgreen: Es hängt also bestimmt nicht mit den Assemblercodes zusammen. Es ist nichts als ein Konkurrenzkampf, bei dem Cpp den Vorteil hat, dass der Compiler (GNU) kostenlos ist.

[bigg]

moin moin,

C++ und Object Pascal sind Programmiersprachen.
Die Sprachen an sich können nicht schneller sein, da "Quellcodes" erst übersetzt werden müssen, in eine Sprache, die ein Prozessor versteht, um diese Befehle dann auszuführen. So gesehen ist deine Frage falsch formuliert.

Und um's kurz zu machen: Weder noch! Man kann deine Frage weder mit ja noch mit nein beantworten. Die Ausführungsgeschwindigkeit des übersetzten Programms hängen von vielen Faktoren ab.

1. Welche Compiler (Übersetzer) verwendet man, um das fertige Programm zu erstellen?
Unter C++ gibt es massenweise Compiler, Pascal-Compiler gibt es nur wenige.
2. Wie gut optimieren diese Übersetzer?
3. Auf welchem Prozessor läuft die übersetzte Anwendung letztendlich?
4. Benutzt man vorgeschriebene Programmabläufe, die von anderen entwickelt wurden? Klassen, Komponenten, Funktionen?
All das kann eine Ursache dafür sein, das das Programm nicht effizient genug arbeitet.
5. ...

Und bei Java ist es nochmal ganz anders, den dort werden Programme erzeugt, die nicht direkt auf die Hardware zugreifen, sondern über eine Schnittstelle, dem Interpreter.

PS: Wenn du dich wirklich für die Programmierung interessierst, dann lern am besten beide Sprachen entwickel ein paar Projekte und fäll dann dein Urteil.


Gruß Stefan

edit: Das waren vielleicht viele Rechtschreibfehler...

[Bernhard Geyer]

Zitat:

Zitat von bigg

Und bei Java ist es nochmal ganz anders, den dort werden Programme erzeugt, die nicht direkt auf die Hardware zugreifen, sondern über eine Schnittstelle, dem Interpreter.

Interpretiert wird bei Java schon lange nichts mehr. Hier sind JIT-Compiler am Werk die benötigte Programmabschnitte übersetzen und die dann "native" ausgeführt werden. Ähnliches wird auch bei .NET gemacht, wobei AFAIK hier ein Versprechen von MS selbst in der .NET 3.0-Version noch nicht eingelöst wird: Optimiertes Compilieren nach verwendeten Prozessor.

[bigg]

Ist dann die Aussage des Wikipedia falsch?

Zitat:

JIT-Compilierung ist eine Technik aus der Praktischen Informatik, um die Performance von Anwendungssoftware, die als Bytecode vorliegt, zu verbessern. Der JIT-Compiler übersetzt während der Laufzeit bei Bedarf den Bytecode in einen nativen Maschinen-Code (also ein Code, den der Prozessor direkt verarbeiten kann).

Der JIT-Compiler oder Just-in-Time-Compiler ist (neben dem Interpreter) ein Teil einer modernen Virtuellen Maschine (z.B. JVM bei Java oder CLR bei .NET) und beschleunigt die Programmausführung. Just In Time bedeutet "gerade rechtzeitig".

Hochentwickelte JIT-Compiler können speziell für dynamische Sprachen schnelleren Code als herkömmliche Compiler generieren, da sie Closed-World-Annahmen treffen können und Dynamische Optimierungen durchführen.

Typische Beispiele findet man bei Java, .NET, Perl6 sowie in kommerziellen Smalltalk-Versionen.

Im Gegensatz zum Just-In-Time-Compiler werden herkömmliche Compiler auch als AOT-Compiler (Ahead-of-Time-Compiler) bezeichnet, weil sie den Programm-Code vor Ausführung des Programms übersetzen. Ahead of time bedeutet "vorzeitig".

Bytecode, Virtuelle Maschine, Übersetzung während der Laufzeit?

[xaromz]

Hallo,

Zitat:

Zitat von bigg

Ist dann die Aussage des Wikipedia falsch?

Was soll daran falsch sein?

Gruß
xaromz

[Elvis]

Zitat:

Zitat von xaromz

Hallo,

Zitat:

Zitat von bigg

Ist dann die Aussage des Wikipedia falsch?

Was soll daran falsch sein?

Ist halt ein "Äpfel und Birnen" - Vergleich. ;-)
Interpretiren ist halt irgendwo ein fester Begriff und steht für die Art der Übersetzung, die in Skriptsprachen wie PHP, Pearl oder VB Verwendung findet.
Also die zeilen-/statement- weise Übersetzung von Code.

[3_of_8]

Wenn ich mich nicht irre, dann ist Java Bytecode sowas ähnliches wie Maschinencode, nur für einen "fiktiven" Prozessor, sodass man es leicht portieren kann.

Ob da jetzt der Begriff "interpretieren" angebracht ist oder nicht, ist eigentlich Ansichtssache.