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.

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

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 :gruebel: , aber ich bekomme gerade Lust auf Obst :wink: .

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:

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:

Zitat von Mein Bauch

Mir sind Sprachen suspekt, deren Sprachkonstrukte aus Sonderzeichen bestehen :mrgreen:

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:

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'? :zwinker:

[Bernhard Geyer]

Zitat:

Zitat von alzaimar

Zitat:

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'? :zwinker:

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:

Zitat von xaromz

Hallo,

Zitat:

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:

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:

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:

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 :zwinker: .

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

[alzaimar]

Zitat:

Zitat von Olli

Mehr Code bedeutet auch, daß es länger dauert ihn auszuführen (es sei denn irgendwelche Schleifen wurden linearisiert, was durchaus vorkommen kann).

:shock:
Nee.

Gegenbeispiel:
Boyer-Moore Pattern Matching (ca. 30 Zeilen) vs. naives Suchen (3 Zeilen)... Boyer-Moore ist viel viel schneller.

[Olli]

Zitat:

Zitat von alzaimar

Gegenbeispiel:
Boyer-Moore Pattern Matching (ca. 30 Zeilen) vs. naives Suchen (3 Zeilen)... Boyer-Moore ist viel viel schneller.

Wie funzt denn "naives Suchen" nach alzaimar in 3 Zeilen? Lasse mich ja gern belehren, aber ich habe ja nicht ohne Grund Schleifen ausgeklammert. Und der Umkehrschluß ist natürlich augenfällig. Wenn innerhalb einer Schleife eine Anweisung steht und die Schleife aber eine Million Male aufgerufen wird, ist die Schleife logischerweise langsamer als eine Schleife mit 10 Anweisungen die nur 1000mal ausgeführt wird (unter der Annahme alle Anweisungen kosten gleichviel Zeit). Also bitte mehr Details. Ausnahmsweise bezog sich meine Angabe nämlich nicht auf "mehr" im Sinne von Dateigröße ;)

Achso: "Zeilen" in HLLs zu vergleichen und daraus die Codelänge welche ausgeführt wird abzuleiten ist etwas gewagt ;)

Nachtrag: Hah, ich glaube ich weiß woher das Mißverständnis rührt. Vermutlich wegen meiner Erwähnung der Linearisierung, richtig? Das ist natürlich ein Feature des Binärcodes und beeinflußt damit die Größe der Datei. Aber das "mehr" war wirklich auf die Ausführung gemünzt.

[alzaimar]

Zitat:

Zitat von Olli

Zitat:

Zitat von alzaimar

Gegenbeispiel:
Boyer-Moore Pattern Matching (ca. 30 Zeilen) vs. naives Suchen (3 Zeilen)... Boyer-Moore ist viel viel schneller.

Wie funzt denn "naives Suchen" nach alzaimar in 3 Zeilen?

Z.B. so (Suche die 'Needle' im 'Haystack'):

Delphi-Quellcode:

For i:=1 to length (Haystack)-Length(Needle)+1 do
  For j:=1 to Length (Needle) do
    If Haystack[i+j-1] = Needle[j] Then 
      Found := True;

Entschuldigung, sind 4 Zeilen. In C, Fortran, ASM etc. ist der Code nicht wesentlich komplexer.

"Naives Suchen" (oder Brute Force) ist eine gängige Bezeichung für dieses Verfahren. Ein Weiteres nennt sich übrigens "Not so naive".

Hier z.B. ein Pattern-Matching ("Reverse-Factor") der einem die Kinnlade runterklappen lässt , die Implementierung einer Graph-Klasse ist noch nichtmal dabei)... Aber schnell ist er trotzdem:
(Aus "Charras & Lecroq, Exact String Matching Algorithms")

Code:

void buildSuffixAutomaton(char *x, int m, Graph aut) {
   int i, art, init, last, p, q, r;
   char c;
  
   init = getInitial(aut);
   art = newVertex(aut);
   setSuffixLink(aut, init, art);
   last = init;
   for (i = 0; i < m; ++i) {
      c = x[i];
      p = last;
      q = newVertex(aut);
      setLength(aut, q, getLength(aut, p) + 1);
      setPosition(aut, q, getPosition(aut, p) + 1);
      while (p != init &&
             getTarget(aut, p, c) == UNDEFINED) {
         setTarget(aut, p, c, q);
         setShift(aut, p, c, getPosition(aut, q) -
                             getPosition(aut, p) - 1);
         p = getSuffixLink(aut, p);
      }
      if (getTarget(aut, p, c) == UNDEFINED) {
         setTarget(aut, init, c, q);
         setShift(aut, init, c,
                  getPosition(aut, q) -
                  getPosition(aut, init) - 1);
         setSuffixLink(aut, q, init);
      }
      else
         if (getLength(aut, p) + 1 ==
             getLength(aut, getTarget(aut, p, c)))
            setSuffixLink(aut, q, getTarget(aut, p, c));
         else {
            r = newVertex(aut);
            copyVertex(aut, r, getTarget(aut, p, c));
            setLength(aut, r, getLength(aut, p) + 1);
            setSuffixLink(aut, getTarget(aut, p, c), r);
            setSuffixLink(aut, q, r);
            while (p != art &&
                   getLength(aut, getTarget(aut, p, c)) >=
                   getLength(aut, r)) {
               setShift(aut, p, c,
                        getPosition(aut,
                                    getTarget(aut, p, c)) -
                        getPosition(aut, p) - 1);
               setTarget(aut, p, c, r);
               p = getSuffixLink(aut, p);
            }
         }
      last = q;
   }
   setTerminal(aut, last);
   while (last != init) {
      last = getSuffixLink(aut, last);
      setTerminal(aut, last);
   }
}


char *reverse(char *x, int m) {
   char *xR;
   int i;
 
   xR = (char *)malloc((m + 1)*sizeof(char));
   for (i = 0; i < m; ++i)
      xR[i] = x[m - 1 - i];
   xR[m] = '\0';
   return(xR);
}
 
 
int RF(char *x, int m, char *y, int n) {
   int i, j, shift, period, init, state;
   Graph aut;
   char *xR;
 
   /* Preprocessing */
   aut = newSuffixAutomaton(2*(m + 2), 2*(m + 2)*ASIZE);
   xR = reverse(x, m);
   buildSuffixAutomaton(xR, m, aut);
   init = getInitial(aut);
   period = m;
 
   /* Searching */
   j = 0;
   while (j <= n - m) {
      i = m - 1;
      state = init;
      shift = m;
      while (i + j >= 0 &&
             getTarget(aut, state, y[i + j]) !=
             UNDEFINED) {
         state = getTarget(aut, state, y[i + j]);
         if (isTerminal(aut, state)) {
            period = shift;
            shift = i;
         }
         --i;
      }
      if (i < 0) {
         OUTPUT(j);
         shift = period;
      }
      j += shift;
   }
}

Ich habe tatsächlich überlesen, das Du Schleifen explizit ausklammerst...

Egal: Natürlich benötigen 10000 Op-codes i.R. länger als 3

[Der_Unwissende]

Zitat:

Zitat von Olli

...(unter der Annahme alle Anweisungen kosten gleichviel Zeit).

Was ja an sich schon eine viel zu allgemeine Annahme ist. Einfaches Beispiel das mir einfallen würde wäre die Multiplikation von Matrizen. Hat man mehrere Matrizen, die miteinander multipliziert werden, so würde man naiv einfach die in der Reihenfolge Multiplizieren, in der sie übergeben werden. Jetzt ist die Multiplikation aber Assoziativ, man kann also hier (bei geeigneten Matrizen) die Reihenfolge der Multiplikation verändern, also einfach einzelne Produkte vor anderen bilden. Das möchte ich jetzt gar nicht weiter ausführen, denke alzaimar und Olli kennen die unterschiedliche Laufzeit (andere natürlich auch!, die die sie nicht kennen finden sicher schnell was in der Theoretischen Informatik dazu). Jedenfalls wird hier vor sortiert, indem die Dimensionen der Matrizen verglichen wird (mehr Anweisungen als die naive Multiplikation), da sich aber die Anzahl von Multiplikationen und Additionen verändert, kann somit eine Optimierung vom Programmierer erreicht werden.

Wichtig ist es natürlich zu beachten, dass eben nicht jeder Befehl gleich lange dauert (@Olli ich denke das ist Dir schon klar!). Nur kostet jede Division doch immer noch >> mehr als eine einfache Addition.

Aber klar, unter der Einfachen Annahme, dass man eine unterschiedliche Anzahl von gleich teuren Befehlen hat, werden natürlich die geringeren Kosten günstiger sein :wink:

[alzaimar]

Unterm Strich bleibt eine (banale Erkenntnis):

Das Verfahren ist wichtig, nicht die Sprache.

In der untersten Ebene sind die optimierenden Compiler/Sprachen besser eeignet, also Hochsprachen.

Bernhard Geyer hat schon treffend angemerkt, das auch bei hochoptimierten Elops (Pos, StrCopy etc.) eine normale Anwendung nur um ein paar Prozente profitiert.

[Olli]

Zitat:

Zitat von Der_Unwissende

Wichtig ist es natürlich zu beachten, dass eben nicht jeder Befehl gleich lange dauert (@Olli ich denke das ist Dir schon klar!). Nur kostet jede Division doch immer noch >> mehr als eine einfache Addition.

Nunja, da ich beruflich programmiere und Reverse Engineering betreibe ... jupp, ist mir klar. Ich wollte dies nur als theoretische Annahme einführen damit die Komplexität nicht unnötig ansteigt. Das unterscheidet bekanntlich Modelle von der realen Welt ;)

Das Beispiel von überladenen Operatoren und Matrizen (Vektor und/oder Skalarprodukt) ist hier ein gutes Beispiel. Der Code ist intuitiv und supergut lesbar, aber die Operatoren selber sind auch zu implementieren. Sie müssen allerdings nicht für den Programmierer sichtbar sein. Ergo kann eine solche simple Zeile HLL-Code gut und gern ein kleines C-Programm in der Komplexität übertreffen ohne mehr Zeilen zu haben.

Zitat:

Zitat von alzaimar

Delphi-Quellcode:

For i:=1 to length (Haystack)-Length(Needle)+1 do
  For j:=1 to Length (Needle) do
    If Haystack[i+j-1] = Needle[j] Then 
      Found := True;

Wo ist die Abbruchbedingung? :-P :lol: (Scherz!)

Zitat:

Zitat von alzaimar

Code:

void buildSuffixAutomaton(char *x, int m, Graph aut) {
   int i, art, init, last, p, q, r;
   char c;
  
   init = getInitial(aut);
   art = newVertex(aut);
   setSuffixLink(aut, init, art);
   last = init;
   for (i = 0; i < m; ++i) {
      c = x[i];
      p = last;
      q = newVertex(aut);
      setLength(aut, q, getLength(aut, p) + 1);
      setPosition(aut, q, getPosition(aut, p) + 1);
      while (p != init &amp;&amp;
             getTarget(aut, p, c) == UNDEFINED) {
         setTarget(aut, p, c, q);
         setShift(aut, p, c, getPosition(aut, q) -
                             getPosition(aut, p) - 1);
         p = getSuffixLink(aut, p);
      }
      if (getTarget(aut, p, c) == UNDEFINED) {
         setTarget(aut, init, c, q);
         setShift(aut, init, c,
                  getPosition(aut, q) -
                  getPosition(aut, init) - 1);
         setSuffixLink(aut, q, init);
      }
      else
         if (getLength(aut, p) + 1 ==
             getLength(aut, getTarget(aut, p, c)))
            setSuffixLink(aut, q, getTarget(aut, p, c));
         else {
            r = newVertex(aut);
            copyVertex(aut, r, getTarget(aut, p, c));
            setLength(aut, r, getLength(aut, p) + 1);
            setSuffixLink(aut, getTarget(aut, p, c), r);
            setSuffixLink(aut, q, r);
            while (p != art &amp;&amp;
                   getLength(aut, getTarget(aut, p, c)) >=
                   getLength(aut, r)) {
               setShift(aut, p, c,
                        getPosition(aut,
                                    getTarget(aut, p, c)) -
                        getPosition(aut, p) - 1);
               setTarget(aut, p, c, r);
               p = getSuffixLink(aut, p);
            }
         }
      last = q;
   }
   setTerminal(aut, last);
   while (last != init) {
      last = getSuffixLink(aut, last);
      setTerminal(aut, last);
   }
}

Igittigitt. Variablen nicht initialisiert. Variablen außerhalb des allernötigsten Bereichs deklariert *brrr*

Nee, aber mal ernst, uns ist allen klar warum sowas schneller geht. Und das ist nicht wegen der fehlenden Abbruchbedingung ...

Zitat:

Zitat von alzaimar

Egal: Natürlich benötigen 10000 Op-codes i.R. länger als 3

Jupp, mein Punkt war halt, daß man bei einer Schleife ja die Instruktionen innerhalb der Schleife pro Durchlauf einmal ausführen muß. Ergo dürfte die Binärdatei kleiner sein als bei deinem Algo, jedoch werden netto mehr Instruktionen vom Prozessor ausgeführt.

Ich muß echt an meinem Ausdruck feilen. Zu lange im Ausland :mrgreen: :zwinker:

Gruß aus dem (nicht vom Internet abgeschnittenen) Reykjavik,

[alzaimar]

Zitat:

Zitat von Olli

Zitat:

Zitat von alzaimar

Code:

void buildSuffixAutomaton(char *x, int m, Graph aut) ...

Igittigitt. Variablen nicht initialisiert. Variablen außerhalb des allernötigsten Bereichs deklariert *brrr*

Nicht so schnell schießen (welche Variablen sind denn nicht initialisiert?), lieber nochmals den Code checken oder direkt bei Charras & Lecroq beschweren. :zwinker:

[Olli]

Zitat:

Zitat von alzaimar

Zitat:

Zitat von Olli

Zitat:

Zitat von alzaimar

Code:

void buildSuffixAutomaton(char *x, int m, Graph aut) ...

Igittigitt. Variablen nicht initialisiert. Variablen außerhalb des allernötigsten Bereichs deklariert *brrr*

Nicht so schnell schießen (welche Variablen sind denn nicht initialisiert?), lieber nochmals den Code checken oder direkt bei Charras & Lecroq beschweren. :zwinker:

Also, ich initialisiere Variablen wenn möglich immer direkt bei der Deklaration und deklariere sie so spät wie möglich (i.e. so kurz wie möglich vor der ersten Benutzung). Das wird von C++ und C99 unterstützt.

Diese Methode hat mehrere Vorteile:
1. Wenn es sich bei der Variablen um ein Stackobjekt handelt, hast du den Aufwand des ctor-Aufrufs erst ab der Zeile mit der Deklaration&Initialisierung. Bei komplexen Objekten kann das einen Unterschied machen.
2. Variablen haben immer einen Standardwert.
3. Baut man zuvor eine Verzweigung (manche benutzen gern goto *würg*) ein, kann nicht hinter der Verzweigung die Variable benutzt werden (wenn sie nur im nächstnötigen Scope liegt) oder zumindest nicht uninitialisiert benutzt werden.

Das sind sozusagen kostenlose Codeverbesserungen die als "Stilmittel" automatisch bestimmte durchaus gängige Fehler vermeiden. Aber keine Angst, ich kenne auch Code der sich partout nicht dran hält und Menschen die noch partout C92 programmieren wollen :mrgreen:

War also nicht so ernst gemeint wie du es scheinbar aufgefaßt hast :zwinker:

[alzaimar]

Zitat:

Zitat von Olli

... von C++ und C99 ... die noch partout C92 programmieren wollen ...

Ich kenn nur C64 :stupid:

Ach, und Code auf Seiten von Universitäten sind meist interessant und selten schnell ('Optimizing is beyond the scope of this article'). Die haben's eben nicht drauf.