Warum delphi lahmer als c++?

[mkinzler]

Und dieser fiktive Prozessor ist die Virtuelle Maschine. Der Bytecode ist objektorientiert und unterscheiset sich doch von den realen Prozessoren. MS nennt das .Net Gegenstück CLR ( Common Langauge Runtime)

[xaromz]

Hallo,

Zitat von Elvis:

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.

Ist ja auch richtig so. Bei einem Java-Interpreter wird ja auch der nächste Bytecode-Befehl genommen, übersetzt und ausgeführt [1]. Beim JIT hingegen wird ein ganzer Anweisungsblock übersetzt und dann ausgeführt [2]. Etwas anderes sagt der Wikipedia-Artikel nicht. Insbesondere sehe ich keine Äpfel oder Birnen , aber ich bekomme gerade Lust auf Obst .

Gruß
xaromz (der auch mal Fußnoten verwendet)

[1] So gesehen ist natürlich auch eine CPU nur ein Maschinencode-Interpreter.
[2] wobei der Block auch das ganze Programm sein kann.

[Robert Marquardt]

Delphi leidet ein bischen darunter das der Codegenerator nicht so weiterentwickelt wurde wie es beim Visual Studio und dem GNU Compiler der Fall ist. Zusaetzlich wurden auch die Basisfunktionen (siehe System und SysUtils) nicht weiterentwickelt. Das ist zum Teil der Grund warum DelphiSpeedUp die IDE so beschleunigen kann.
Insgesamt bedeutet das aber nicht das man mit Delphi nicht Programme schreiben kann die so schnell wie C++ Programme sind. Es ist dafuer sowieso auf beiden Seiten sorgfaeltigste Optimierung noetig und da gibt es kaum einen Unterschied in den Schwierigkeiten.

[Bernhard Geyer]

Zitat von Robert Marquardt:

Zusaetzlich wurden auch die Basisfunktionen (siehe System und SysUtils) nicht weiterentwickelt. Das ist zum Teil der Grund warum DelphiSpeedUp die IDE so beschleunigen kann.

Für Delphi gibt es auch noch das FastCode-Project. Also falls man hier auch noch ein paar Prozent Geschwindigkeit benötigt und ein paar ruhige Stunden zu integration zur verfügung hat ....

[alzaimar]

Wie schon oft wiederholt, zählt in erster Linie das Verfahren, also der Algorithmus.

Ich beschäftige mich gerade mit String-Matching-Algorithmen, und hier scheint es hingegen so zu sein, das C(++) die generischen Schleifen und Vergleiche vielleicht doch besser in Maschinencode abbilden kann.

Es ist nämlich so, das sich die offensichtlich besten Algorithmen nicht als Ebensolche in Delphi umsetzen lassen.

Hier hat bisher (bei meinen Ansätzen), ein sehr kompakter Algorithmus (QS) die Nase bei weitem vorn. Vermutlich vor Allem deshalb, weil die zentrale Funktion (vergleich von zwei Teilstrings) als 'CompareMem' abgebildet ist.

Bei dem Algorithmus, der derzeit die Nase vorn hat (FJS), wird der Vergleich über eine generische C-Schleife abgebildet. Wenn ich diesen FJS in Delphi übersetze, ist er um ein vielfaches langsamer als der QS-Algorithmus. Und ich glaube, es liegt an der Verwendung des CompareMem im QS-Algorithmus. Von der Komplexität ('Big Oh') ist der FJS einfach besser. Nebenbei: Auch Boyer-Moore, Horspool etc. können dem QS (QuickSearch von Daniel Sunday) unter Delphi nicht das Wasser reichen.

Ich meine, bei diesen generischen Schleifen und Vergleichen dürften die hier beschriebenen CPU-abhängigen Optimierungsmöglichkeiten in den C-Kompilern greifen.

Auf Applikationsebene entscheidet jedoch fast ausschließlich das verwendete Verfahren.

Nach meiner Einschätzung ist C für die Implementierung generischer Algorithmen (String-Matching, Hash, Listen, etc.) besser geeignet.

Auf OOP-Ebene sollte man imho auf C++ verzichten.

Zitat von Mein Bauch:

Mir sind Sprachen suspekt, deren Sprachkonstrukte aus Sonderzeichen bestehen

Abschließend sei noch eins erwähnt: Schnelle Programme schreibt man auch in VB, PHP oder JavaScript, solange das gewählte Verfahren optimal ist.

Zitat von Bernhard Geyer:

Für Delphi gibt es auch noch das FastCode-Project. Also falls man hier auch noch ein paar Prozent Geschwindigkeit benötigt und ein paar ruhige Stunden zu integration zur verfügung hat ....

Findest du Steigerungen um den Faktor 3 'ein paar Prozent'?

[Bernhard Geyer]

Zitat von alzaimar:

Zitat von Bernhard Geyer:

Für Delphi gibt es auch noch das FastCode-Project. Also falls man hier auch noch ein paar Prozent Geschwindigkeit benötigt und ein paar ruhige Stunden zu integration zur verfügung hat ....

Findest du Steigerungen um den Faktor 3 'ein paar Prozent'?

Damit wahr eher gemeint das in einem gesamten Programm/Algorithmus der Faktor 3 einer einzelnen Funktion niemals komplett durchschlagen wird. Außgenommen die Algorithmen die nur von solchen Funktionen abhängen.

[bigg]

hoho,

[ot]

Zitat von xaromz:

Hallo,

Zitat von bigg:

Ist dann die Aussage des Wikipedia falsch?

Was soll daran falsch sein?

Gruß
xaromz

Nichts. Aber vielleicht ist die Aussage von Bernhard nicht ganz richtig.

Zitat von Bernhard Geyer:

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.

Der erzeugte Bytecode wird zum Übersetzen nicht interpretiert? Die Frage müsste dann allerdings lauten, wie erzeugt der JIT-Compiler daraus wiederrum native Code, der dann wiederrum ausgeführt wird? Eigentlich doch nichts neues, außer das die Interpretation nur ein einziges mal statt findet.

[/ot]

[Der_Unwissende]

Hi,
erstmal zu der eigentlichen Frage, man sollte immer die Quellen hinterfragen. Pauschale Aussagen wie X ist immer besser/schneller/schöner als Y sind im Prinzip nie richtig. 99% davon sind Anssichtssache. Gerade was die Geschwindigkeit angeht, so mag es hier durchaus mal stimmen, dass eine Sprache schnelleren Code erzeugt als eine andere. Aber man sollte sich a) darüber im klaren sein, dass eine fempto-Sekunde mehr oder weniger bei gleichem Code kaum ins Gewicht fällt. Kommen genügend solcher f Sek. zusammen, so wird jeder Zugriff auf die Festplatte immer noch deutlich mehr ausmachen, auch wenn das eine Programm schneller ist.
Wichtiger ist heute eher, wie leicht du was in der Sprache umsetzen kannst. Ein paar Dinge (insbesondere Benutzereingaben) lassen sich nicht beliebig beschleunigen. Natürlich gibt es gebiete, in denen dürfte die reine Perfomance wichtig sein, in anderen ist es eher die Sicherheit oder Robustheit. Man sollte hier eine Sprache nie nach nur einer Aussage beurteilen.
Wenn es rein um die Perfomance geht, dann ist rein imperativer C Code wohl wieder schneller als Objekt Orientierter C++ Code, da einfach schon die Möglichkeit der Indirektion fehlt (dürfte auch für Pascal vs. ObjectPascal/Delphi) gelten.
Hinzu kommt auch noch, dass man mit Makros oder den Verzicht auf Funktionen den Overhead erspart, der nun mal mit jedem Funktionsaufruf statt findet. Allerdings dürfte kaum ein sinnvolles Projekt entstehen, wenn man hier einfach mal den ganzen Code in eine einzelne Anweisung schreibt. Da wird die Fehleranfälligkeit und die fehlende Wartbarkeit bei weitem den vermeintlichen Geschwindigkeitsvorteil überwiegen.
Ja, dann ist auch objektiv die Geschwindigkeit sehr viel leichter zu messen, als es subjektiv der Fall ist. Nimm einfach zwei Anwendungen, die beiden 1 min lang irgendwas berechnen. Hat nur eine davon eine Fortschrittsanzeige, würde ich sagen, werden viele Leute die als schneller arbeitend empfinden (einfach weil etwas passiert!). Je nachdem wie du dann noch den Fortschritt anzeigst kann das für solche Projekte zu einer gefühlten Steigerung (unabhängig von der Berechnung und Sprache) führen. Natürlich wird sowas in einem DBMS wohl kaum benötigt, aber wie gesagt, man muss schon differenzieren, worin etwas schneller ist oder eben nicht.

[OT]

Zitat von bigg:

[ot]
Der erzeugte Bytecode wird zum Übersetzen nicht interpretiert? Die Frage müsste dann allerdings lauten, wie erzeugt der JIT-Compiler daraus wiederrum native Code, der dann wiederrum ausgeführt wird? Eigentlich doch nichts neues, außer das die Interpretation nur ein einziges mal statt findet.
[/ot]

Wenn es danach geht, muss man doch schon zwischen reinen RISC und eben auch CISC Architekturen unterscheiden. Denke nicht, dass man in heutigen x86 CPUs ganz ohne Interpretation auskommt, Teile des Codes können da (auf den meisten gängigen CPUs) sicherlich interpretiert werden.
Ich denke, dass man bei einem JIT nicht mehr von Interpreation sprechen kann, da hier Optmierungen statt finden. Genau das passiert halt dadurch, dass gleich ganze Codeblöcke eingelesen werden. Ein reiner (einfacher) Interpreter würde einfach dumm Zeile für Zeile in eine fremde Umgebung überführen.
Natürlich ist und bleibt Objekt Code und seine Übersetzung/Ausführung eine Sache, die man nicht so einfach als einordnen kann, aber der reine Interpreter kommt wohl so wenig zum Einsatz wie die native Ausführung (die aber auf einer Java-CPU/Architektur ohne weiteres möglich ist). Zudem gibt es auch immer mehr CPUs (nicht alle müssen ja in einem normalen PC stecken!) mit eigenen Java-Co-Prozessoren, die wirklich nativ Java Code ausführen.
[/OT]

[phXql]

Zitat von mkinzler:

...Der Bytecode ist objektorientiert und unterscheiset sich doch von den realen Prozessoren. MS nennt das .Net Gegenstück CLR ( Common Langauge Runtime)

Der Bytecode heisst bei .NET MSIL . Die Virtual Machine heisst CLR.

[Khabarakh]

Nope, heißt durch die Standardisierung nun CIL .