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]