Wieso ist eine Programmiersprache schneller als eine andre

Ganze einfach. Ein guter Assemblerprogrammierer, der nachdenkt über seinen Code und die schnellste Möglichkeit nimmt, ist besser, als die Optimierung der Compiler.

Ich wage zu behaupten, dass man wahnsinnig gut in Assembler sein muss um einen guten C/C++ Compiler zu übertreffen.
Natürlich vorausgesetzt, der Algorithmus ist der gleiche - schliesslich schreibt ja der Compiler / Assembler nicht das Programm.
Wer von euch kann (in Assembler) MMX / SSE Befehle nutzen ? Noch schlimmer: wer kann die GPU nutzen (CUDA/ATI Stream/OpenCL, nicht zu verwechseln mit OpenGL) ?
Da steckt heutzutage das meiste Potential drin. (hey, meine Grafikkarte macht 1.2 TeraFLOPS - und ich bin zu doof, um das auszunutzen).

Zitat von Bakku

Warum ist Basic nicht so schnell wie C/C++ ?

Eigentlich könnte ein guter BASIC-Compiler genauso schnelle .exe-Dateien bauen wie ein C/C++ Compiler.
Wahrscheinlich gibts keinen so guten BASIC-Compiler, weil kein Profi BASIC für seine Projekte nutzt.
(Das ist gelogen, tatsächlich wird oft Visual BASIC für ernsthafte Arbeit benutzt - mit verheerenden Folgen)

Zitat von Bakku

Heißt das also, würde man für jede Programmiersprache (mal Interpretersprachen o.ä. ausgenommen) eine guten Compiler schreiben, dann könnte jede Sprache genauso schnell sein wie die andren ?

Zum Teil. Würde man z.B. für AutoIt einen Compiler schreiben, würde es durch den fehlenden Unterschied zwischen Variablentypen Leistungsverluste geben. Schließlich müssten ja noch weitere Daten übergeben und ausgewerter werden um herauszufinden, welcher Typ das ist.

Klar, erstmal gibt es die vier Stufen Assembler, Compilersprache, Bytecodesprache (Java), Interpretersprache.
Tatsächlich muss man ziemlich gut sein, um bei Assembler heutzutage noch einen Geschwindigkeitsvorteil rauszuholen, die heutigen (bspw. C++-) Compiler sind da sschon ziemlich nah dran.
Dann hängt es von der Sprachstruktur ab (wie Marthog schon sagte) : Wenn Variablentypen nicht erst noch erkannt werden müssen, läuft das schon schneller..
Den allergrößten Unterschied macht allerdings der Programmierstil. Wenn ein Anfänger ein etwas komplexeres Programm in C++ schreibt, kann ein von einem Profi geschriebenes AutoIt-Skript dennoch schneller sein.

Zitat

Den allergrößten Unterschied macht allerdings der Programmierstil. Wenn ein Anfänger ein etwas komplexeres Programm in C++ schreibt, kann ein von einem Profi geschriebenes AutoIt-Skript dennoch schneller sein.

Genau DAS ist der eigendliche Haken an der Sache....
Ein langsames Programm bleibt ein langsames Programm, auch wenn es vom schnellsten Compiler übersetzt wurde! Denn auch der kann aus Sch*** kein Gold machen!

@Topic
Kaum jemand schreibt heutzutage noch Programme "selbst". Ich gehe davon aus, dass die Lösung sämtlicher programmiertechnischer Probleme und auch Algorithmen schon in irgendeiner Funktion vorliegen. Im Prinzip ist Programmieren nur noch das Suchen und die Aneinanderhängung dieser Funktionen.
Ein Compiler macht nichts anderes.
Zur Frage Basic schneller/langsamer als C++, das liegt einfach daran, dass C++-Funktionen sehr häufig (häufiger als Basic) verwendet werden. Somit ist auch der Anteil an Programmierern höher, welche aus einer "langsamen" Funktion Stück für Stück Speed herauskitzeln. Dies wiederum fliesst in dann in "Standard"-Bibliotheken ein, und somit werden Funktionen von Generation zu Generation zwangsläufig "besser" (oder schneller)
Da es auch in Assembler kein Problem ist, C-Funktionen zu benutzen bzw. dazuzulinken, sieht der Weg des Optimierens eigendlich umgekehrt aus.
Schreib ein C++-Programm, guck in einem Profiler nach, was im Code "langsam" ist, schau dir den entsprechenden Assemblercode im C-Compiler an, entdecke warum der Compiler "langsamen" Code bastelt und schreib eine Mail an die Compilerbauer mit entsprechenden Hinweisen.....die nehmen diese Infos idR dankbar auf!

Bzgl. SSE und anderer Prozessor-Erweiterungen, die idR keinen Einzug in heutige Software finden: Ja, das regt mich auch schon auf, seit es diese Möglichkeiten gibt!
Wer kauft sich einen Ferrari und fährt damit ausschliesslich im 1. Gang??? Kein Mensch macht das! Aber jeder kauft einen neuen Rechner und lässt Programme laufen, die für 15 Jahre alte Hardware geschrieben sind....wobei natürlich Ausnahmen die Regel bestätigen
In einer der letzten Linux-Kernel Previews habe ich davon gelesen, dass das Dekodieren von JPG nun auch 4x schneller mittels SSE-Befehlen abgewickelt wird....15 Jahre nachdem die Hardware diese Befehle zur Verfügung stellt. Na klasse, herzlichen Glückwunsch!
Wobei man den Linuxern das auch hoch anrechnen muss, denn in den Windows-Code wird "neue" Technik wohl so schnell nicht Einzug halten!

C++ler sind eigendlich fein raus, für so gut wie sämtliche mathematischen Funktionen gibts auch die schnellen SSE-Funktionen! Für Matrixmultiplikation ist Faktor 4 eine Hausnummer, da würde mancher neue Rechner nicht gekauft, wenn der alte nur durch neukompilieren der Software plötzlich x-mal schneller wäre
Intel ist da immer bissl in der Zwickmühle, die haben einen TOP-Compiler, wollen aber gleichzeitig neue Hardware verkaufen. Aber da sich mit Hardware mehr Geld als mit Software verdienen lässt, bleibt die Software unoptimiert und man empfiehlt, die schnellere Hardware zu kaufen

@progandy,
ja, genau so wird das ja auch gemacht! Da werden Benchmarks vom Compiler auf bestimmte Prozessoren hin "optimiert", damit der Kunde meint, er kauft einen schnellen Prozessor....
Das war besonders heftig beim Umstieg vom P III auf den P IV. Da wurde eine gigantische Marketingmaschine losgetreten, man sprach von "neuen Generationen" und im Endeffekt waren die "neuen" Prozessoren gemessen am Takt 1/3 langsamer als die alten .
Also setzt man den Takt und die Spannung so lange hoch bis das Die glüht, verpasst dem Viech einen Monsterkühler, baut stärkere Netzteile ein und verkauft das Ganze dann als Fortschritt!
Warum der Preskott hierzulande nur als "Fresskopp" bezeichnet wurde, versteht sich da von selbst^^ .
Ach ja, die Compiler wurden natürlich dahingehend angepasst, dass sämtliche Nicht-P4 einige Zwangswarterunden in den Benches drehen mussten. Viel hilft viel...

Also ich würds mir so vorstellen:

Man programmiert einen einfachen Algorithmus nach, zum Beispiel zum Berechnen von Nachkommastellen - jeweils mit (technisch) der exakt gleichen Methode.
Der Compiler übersetzt das jetzt in Binärcode, nach einem bestimmten Weg.

Manche Compiler machen das eben nicht auf die effizienteste Variante, und daher sind diese eben langsamer - aber pauschal sagen, dass eine Programmiersprache langsamer ist, kann man eigentlich nicht.

Ein gutes Beispiel dafür ist Prototype (oder die Arduino-Variante für Mikrocontroller) - diese Sprache wird in Java bzw. C "umgewandelt", und dann kompiliert.

Ich hab mal vor einiger Zeit ein lustiges Experiment zum Thema Dateigrößen gemacht - immer der selbe Zweck, aber eben unterschiedlich interpretiert: http://nerdworld.de/programmierung…lichkeiten.html