Um wieviel ist Assembler schneller als C++?

Das hängt extremst von der Architektur und dem zu implementierenden Algorithmus ab. Und letztendlich von der Erfahrung des Programmierers.

Allgemein kann man aber sagen, dass C++ deutlich mehr Funktionalität als C bietet, mit der man dem - von Natur aus recht "dummen" - Compiler detaillierte Hinweise geben kann, was denn nun eigentlich die Intention des Programmierers ist. Man hat mit C++ also deutlich mehr Möglichkeiten, sich dem Compiler gegenüber vernünftig ausdrücken zu können.

Es gibt auch sehr viele kleine Ausnahmen, in denen C-Code tatsächlich effizienter sein kann, als in C++: Der Umgang mit Pointer-Aliasing mithilfe des "restrict" Schlüsselwortes zum Beispiel. Denn damit ist C so schnell wie Fortran, "restrict" gibt es aber erst seit C99. Trotzdem bieten fast alle Compiler einen herstellerspezifischen Ersatz auch für C++ an ...

... aber da wir sowieso von plattform-abhängigem Assembler reden, macht eine weitere Compiler-Abhängigkeit den Kohl auch nicht fett. (Disclaimer: Es ist das Gemüse gemeint; nicht unser Ex-Bundeskanzler!)

Außerdem muss man wissen, wie gängige Compiler arbeiten.

Wenn ich etwas optimieren muss, schreibe ich oftmals erst eine C++ Version, kompiliere diese mit verschiedenen Optimierungsflags und disassembliere das Ergebnis.

Dabei sieht man dann oft dass der Compiler wirklich clevere Tricks anwendet, auf die man gar nicht so ohne weiteres kommt. Aber ehrlich gesagt trifft man auch manchmal auf Ergebnisse, die offensichtlich ineffizient sind, und die man per Hand bzw. Inline-Assembler besser hinbekommt, was sich dann auch im Profiler bewahrheitet.

Assembler macht großen Spaß und Lesen sollte man es auf jeden Fall können, aber neben minimalen Inline-Spielereien ist Assembler für größere Sachen eigentlich ungeeignet. Zumal man für jede Architektur einen (fast) komplett neuen Algorithmus entwickeln muss. Alleine schon die drei Hauptplattformen ARM, x86 und x64 funktionieren ziemlich anders und bieten teilweise völlig unterschiedliche Befehle an.

Bei embedded Sachen, Mikrocontrollern, zeitkritischen und Echtzeit-Systemen muss man aber oft auf Assembler zurückgreifen, da man wirklich exakt die verbrauchten Takte mitzählen muss. Mit Code, der von einem Compiler erzeugt wird, geht das nicht.

In den allermeisten Fällen ist es wirtschaftlicher, C oder C++ zu verwenden, und dem Compiler zu sagen: "Mach mal!" :)

Trotzdem ist Assembler zu Übungszwecken eine wunderbare Sache und wenn es wirklich auf extreme Effizienz ankommt (Prüfsummenberechnungen in einer Crypto-Lib zum Beispiel) führt kaum ein Weg daran vorbei.

Fazit: Mit Assembler kann man zumindest theoretisch den effizientesten Code erzeugen, aaaaaber die meisten Entwickler sind nicht in der Lage dazu, da sie die feinen Eigenheiten ihrer Zielplattform nicht genau genug kennen. Solche Leute werden fast immer mit C++ den effizienteren Code schreiben können, und das sind mit Sicherheit weit über 99%.

Die restlichen 1% sind rar gesät. Der gemeine Durchschnitts-Programmierer wird mit Assembler mehr "versauen" als die Leistung zu steigern.

PS: Im Gegensatz zur Geschwindigkeitssteigerung kann man die Codegröße mit Assembler relativ leicht reduzieren! Aber auch hier nimmt einem der Compiler i.d.R. die Arbeit mit entsprechenden Flags ab.

Das kleinste "Hallo Welt", dass ich jemals mit einem Standard-Compiler hinbekommen habe, war ca. 350 Byte groß. Die Assembler Variante war knapp 180 Byte groß. Trotzdem war das nur eine Spielerei und für "richtige" Aufgaben würde ich niemals so viel Aufwand investieren um ein paar Byte rauszuquetschen. :)

Habe es im Internet gefunden. Da hat jemand Quicksort verglichen mit Assembler und C. Soweit ich weiß, ist C++ ähnlich schnell wie C. Das Ergebnis ist Faktor: 29!!!