Warum delphi lahmer als c++?

[phXql]

Zitat:

Zitat von Khabarakh

Nope, heißt durch die Standardisierung nun CIL :zwinker: .

mhm okay. wieder was neues gelernt ;)

[Bernhard Geyer]

Zitat:

Zitat von bigg

Der erzeugte Bytecode wird zum Übersetzen nicht interpretiert?

Um nun die Kleinkarriertheit auf die Spitze zu treiben. Hier spricht man doch eher von Parsen. Ein Compiler parst den Quellcode (Bytecode) und compiliert diesen.

Von Interpretieren spricht man im Normalfall wenn immer wieder interpretiert wird und nicht nur das erste mal.
Pascal war früher auch mal eine entsprechende Sprache (P-Code).

[bigg]

@Bernhard: Jupp, du hast ja so recht. :zwinker:
Wir beide wissen letztendlich worauf es ankommt und müssen uns keine Märchen erzählen. :wink:

PS: Na, ob sich der Thread-Ersteller hier nochmal blicken lässt? :stupid:

[Bernhard Geyer]

Zitat:

Zitat von bigg

@Bernhard: Jupp, du hast ja so recht. :zwinker:
Wir beide wissen letztendlich worauf es ankommt und müssen uns keine Märchen erzählen. :wink:

Ab und zu muss mal sowas sein :stupid:

Zitat:

Zitat von bigg

PS: Na, ob sich der Thread-Ersteller hier nochmal blicken lässt? :stupid:

Ich glaube wir haben zu arg zugetextet :???:

[Insider2004]

Borland Delphi und Borland C++ sind in etwa gleich schnell, da beide Sprachen den gleichen Codegenerator verwenden. Java ist ca. 15 mal langsamer. .Net dürfte auch in diesem Bereich liegen.

BTW: Die meiste Prozessorzeit wird verschwendet durch "dumme" Programmierer, nicht durch schlechte Compiler.

[mkinzler]

Zitat:

Borland Delphi und Borland C++ sind in etwa gleich schnell, da beide Sprachen den gleichen Codegenerator verwenden. Java ist ca. 15 mal langsamer. .Net dürfte auch in diesem Bereich liegen.

Auf was stuützen sich diese Angaben?

[Insider2004]

Java versus FreePascal:
http://shootout.alioth.debian.org/gp...cal&lang2=java

Java und C#/.net liegen größtenteils gleichauf:
http://shootout.alioth.debian.org/gp...arp&lang2=java

[Olli]

Äpfel und Birnen. Delphi hat einen Single-Pass-Compiler. Die meisten C/C++-Compiler sind Multi-Pass.

Auch wäre die Frage welche Versionen welcher C/C++-Compiler mit welcher Delphi-Version verglichen werden.

Zitat:

Zitat von Nils_13

Für objektorientierte Programmierungs sollte man C++ aber wirklich nicht benutzen, das ist mit Delphi schon einfacher.

Wenn ich sowas lese, kommt mir dasWürgen. Du solltest dann C++ wirklich absolut nicht benutzen. Allerdings kannst du mal gern mit aktuellen Delphi-Sprachfeatures versuchen in Delphi:
- Objekte auf dem Stack zu erzeugen
- Operatoren zu überladen
- Templates zu programmieren
- TMP (Template-Meta-Programming) mit Templates zu machen (Verlagerung auf Compile-Time)
- Präprozessor-Generatormakros zu schreiben

Ich erwarte Beispiele! :wall:

Zitat:

Zitat von Der_Unwissende

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.

Schlechte Idee, denn damit erspart man sich auch gleich die Typensicherheit (mit Makros). Daher wurden Templates und inline-Funktionen/Methoden bereitgestellt die es besser als Makros bringen.

Zitat:

Zitat von Der_Unwissende

Wenn es danach geht, muss man doch schon zwischen reinen RISC und eben auch CISC Architekturen unterscheiden.

Reines CISC gibt es meines Wissens nach nicht mehr bei Intel und AMD. Beide benutzen einen Mix. Wobei AMD eher auf RISC-Elemente setzte.

[Der_Unwissende]

Zitat:

Zitat von Olli

Zitat:

Zitat von Der_Unwissende

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.

Schlechte Idee, denn damit erspart man sich auch gleich die Typensicherheit (mit Makros). Daher wurden Templates und inline-Funktionen/Methoden bereitgestellt die es besser als Makros bringen.

Schon klar, aber moderne Compiler entscheiden afaik selbst einige Funktionen einfach inline zu setzen, egal ob dies im Code explizit vorgegeben wurde oder nicht.
Es ging mir eigentlich nur darum zu sagen, dass ein objektives "Ist schneller" auch fempto-Sekungen bezeichnen kann, mekrt keiner, ist aber schneller. Nur zählt beim Code nie alleine die Perfomance. Ist der Code voll von Fehlern, wird der in keinem System eingesetzt (zumindest nicht all zu oft). Da gibt es halt noch andere Punkte, warum Code sauber und lesbar sein sollte und ich glaube niemand sollte sein Sprache rein nach der (vermeindlichen) Perfomance aussuchen. Immerhin bleibt nun mal jede Indirektion ein klarer Perfomance-Killer, erlaubt aber ein paar nette Dinge bei der Programmierung, deren Vorteile vielleicht die eine Indirektion mehr oder weniger locker überwiegen.

Zitat:

Zitat von Olli

Zitat:

Zitat von Der_Unwissende

Wenn es danach geht, muss man doch schon zwischen reinen RISC und eben auch CISC Architekturen unterscheiden.

Reines CISC gibt es meines Wissens nach nicht mehr bei Intel und AMD. Beide benutzen einen Mix. Wobei AMD eher auf RISC-Elemente setzte.

Wiedermal nur afaik sind die Kerne der CPUs natürlich RISC und nur sehr sehr sehr wenige Befehle noch CISC (eh schlechte Benennung CISC), aber trotzdem kann es nunmal schon durch die Archtitektur zur Interpretation kommen (genauso wie Code halt nur schneller sein kann, hat wie ja oft genug gesagt wurde nichts mit der Sprache zu tun).

An sich ist es halt nur immer etwas langweilig die These zu lesen, dass Sprache A noch viel perfomanter ist als Sprache B. Wichtiger ist da doch eh, dass Entwickler C in A und B schnelleren Code erstellt als D, weil D einfach keine effizienten Datenstrukturen kennt...

[Olli]

Zitat:

Zitat von Der_Unwissende

Immerhin bleibt nun mal jede Indirektion ein klarer Perfomance-Killer, erlaubt aber ein paar nette Dinge bei der Programmierung, deren Vorteile vielleicht die eine Indirektion mehr oder weniger locker überwiegen.

Ich würde Killer durch Bremse ersetzen, aber prinzipiell ist das korrekt. Mehr Code bedeutet auch, daß es länger dauert ihn auszuführen (es sei denn irgendwelche Schleifen wurden linearisiert, was durchaus vorkommen kann).

Nachtrag als Erläuterung: es geht um die tatsächlich auszuführenden Anweisungen. Nicht darum wie groß die Binärdatei ist.

Zitat:

Zitat von Der_Unwissende

Wiedermal nur afaik sind die Kerne der CPUs natürlich RISC und nur sehr sehr sehr wenige Befehle noch CISC (eh schlechte Benennung CISC), aber trotzdem kann es nunmal schon durch die Archtitektur zur Interpretation kommen (genauso wie Code halt nur schneller sein kann, hat wie ja oft genug gesagt wurde nichts mit der Sprache zu tun).

Absolut!

Zitat:

Zitat von Der_Unwissende

An sich ist es halt nur immer etwas langweilig die These zu lesen, dass Sprache A noch viel perfomanter ist als Sprache B. Wichtiger ist da doch eh, dass Entwickler C in A und B schnelleren Code erstellt als D, weil D einfach keine effizienten Datenstrukturen kennt...

:lol: Hehe, zumal die Sprache an sich keinen Code erstellt, sondern der Compiler und unter Umständen der Linker im Sinne von Optimierungen.