Nur weil etwas in Assembly geschrieben ist, heißt nicht, dass es automatisch auch schneller läuft. Gerade heute wo die Prozessoren extrem komplex sind (z.B. out-of-order execution, register renaming) ist es schwierig sämtliche Befehle so gut im Kopf zu haben, dass der Assemblycode die vorhandenen Resourcen optimal ausnutzt. Gerade moderne Compiler können das aber mittlerweile sehr, sehr gut und optimieren den Code sehr viel besser als die meisten Programmierer.



Daneben spricht gegen Assemblysprache, dass das Windows, wie wir es heute kennen (also Windows NT) von Anfang an darauf ausgelegt war auf unterschiedlichen Prozessorarchitekturen zu laufen (neben x86 z.B. auch MIPS, PowerPC und Alpha). Gerade jetzt wo die stromsparenden ARM-Prozessoren sich plötzlich noch weiter verbreiten ist es wieder wichtig Windows auf dieser Plattform zum laufen zu bekommen und das ginge nicht, wenn man alle zich Millionen Codezeilen von Grund auf neu programmieren müsste.



Übrigens ist es ein Irrglaube, wenn du denkst Assembler wäre 1000mal so schnell wie C#. Denn wenn die .NET-VM ein Programm ausführt wird der Bytecode nicht etwa Befehl für Befehl abgearbeitet sondern optimiert und als x86-Maschinencode gespeichert, der dann wiederum ausgeführt wird.

Ich habe das letzte mal Mitte der 1990er in Assembler programmiert. Meine Anwendung waren immer numerische Simulationen in der Akustik.



Einige Randbedingungen begründeten meine Entscheidung für Assembler



1. Ich konnte klar sagen, wo die Rechenzeit verbraucht wird

2. Es gab war mathematischen Koprozessoren, doch deren Ansteuerung doch damals vorhandene Compiler war bescheiden - es wurde mehr Zeit für Zahlenformatumwandlungen, als für die Berechnung gebraucht.

3. Ich konnte die komplette Hardwareumgebung definieren und die Simulation musste nur auf einen Rechner laufen.

4. Die numerischen Probleme waren "gutmütig", sodass keine Fehlerabfragen erforderlich waren und Test sich auf einige Funktionstests beschränken konnten.



Unter diesen Bedingungen entspachen 1-2 Zeilen Hochspache etwa 1 Tag Entwicklung in Assembler. Der Geschwindigkeitsgewinn war etwas ein Faktor 10-100.



Später wurde die Compiler besser und der Zeitgewinn war nur noch ein Faktor 2 oder noch niedriger. Jetzt greifen andere Überlegungen



1. Während der Projektlaufzeit nimmt die Rechnerleistung schneller zu als benutzen von Assembler. Das heisst auch, warten ist effektiver als arbeiten (Assemblerprogrammierung)



2. Man hat heute Multiprozessorenrechner mit Multicores und effektive libs für verteiltes Rechnen (mpich, cuda...). Die Manpower die da drinnen steckt, kann man als kleines Team ökonomisch nicht aufbringen.



3. In Hochsprache geschriebene Programme sind leichter zu warten.



Damals wie heute bleibt aber ein Problem ihm Softwaredesign. Wie definiere und verteile ich meine Prozesse, Funktionen etc. so, dass sie "optimal" ineinander greifen. Eine Optimierung im Design ist oft lohnender als Assemblerentwicklung

Hi Toastbrot,



ich halte die Geschwindigkeitsvergleiche für eher unseriös. Programmabläufe können nicht auf einfache weise verglichen werden.



1.

Programme in Maschienensprache sind - wie C bzw. dessen Ableger - sog. Compiler. Das bedeutet, der menschliche Programmierer bzw. die menschlichen Programmierer schreiben Code mit der vorgegebenen Syntax. Menschen können diesen Code lesen.



Soll das Programm eingesetzt werden, wird es "compiliert". Der Compiler setzt den Code, sofern dieser fehlerfrei ist, in den Binären Steuer- oder Maschienenode um. Hierbei werden z.B. auch alle Anmerkungen, die dem Programmierer helfen, gelöscht.



Als Ergebnis spricht eine kleinere Binärdatei die Hardware direkt an undsetzt die logischen Befehle um, die entsprechend durch die logischen Bausteine in den Prozessoren umgesetzt werden.



2.

Geschwindigkeitsbestimmend ist die Laufzeitumgebung, d.h., welche Einbindungen in Hard- und Software bestehen.



3.

Dabei ist v.a.auch der Speicher bzw. die entspr. Adressierung geschwindigkeitsbestimmend, die solange rasch abläuft, wie das schnelle RAM genutzt werden kann. Auch die Speichergröße der CPUs ist entscheidend.



4.

Welche Möglichkeiten bietet eine Programmiersprache. C bzw. C++ wurden und werden permanent weiterentwickelt und um neue Befehlssätze, beispielsweise bei der Grafischen Ausgabe, erweitert. Diese Befehlsbibliotheken werden in jedem C++ 0rogramm im Programmheader mit "include" eingebunden. Das stellt aber auch sicher, dass immer nur der bzw. die benötigten Befehlssätze in den Speicher geladen werden. Somit kann hier bei eleganter Programmierung ebenfalls ein Geschwindigkeitsvorteil erreicht werden.



5.

C++ ist sehr portabel: Sämtliche Windowversionen, DOS-Versionen, BIOS-Steuerprogramme, alle Linuxvarianten sowie auch die Mac-OS laufen auf Grundlage von C++ (Mac Betriebssysteme sind eigentlich geschickt auf die Hardware zugeschnittene Linux-Derivate).



6.

Assembler ist eine wenig weiterentwickelte Programmiersprache. Folglich sind die Möglichkeiten auch geringer. Wenn diese zur Lösung eines Problems ausreichen sind, mag durchaus ein rascher Programmablauf gewähleistet sein. Allerdings würde heute ein Assemblerprogramm wohl in der Umgebung eines der oben genannten Betriebssysteme emuliert werden, was auch zeigt, wie leistungsfähig die C-Umgebungen anpassbar sind.



7.

Mit der Änderung der Hardware, v.a. der Entwicklung von Mehrkernprozessoren und Bit-Architektur könnenn lediglich entsprechend weiterentwickelte Programme diese Möglichkeite ausschöpfen.



8.

Je portabler eine Programmiersprache ist, desto weniger Geschwindigkeitsoptimiert dürfte diese ablaufen, aber wer möchte heute noch für jede neue Hardware lediglich mit einem einzigen, vorgegebenen Programm arbeiten(?).



javaScript von Oracle ist sehr eng an C++ angelehnt, stellt jedoch Programme nicht nur für PCs, sondern auch für Handies, Flatscreens oder die KFZ-Elektronik bereit.



9.

Am schnellsten ist hardwarebezogene Programmierung. Theoretisch lässt sich ein Betriebssystem komplett und fest auf Chips programmieren. Das würde sehr schnell ablaufen, sich jedoch nur bedingt oder gar nicht mehr anpassen oder aktualisieren lassen. Ein einfaches Beispiel hierfür ist ein Taschenrechner - schaue einmal auf wikipedia unter "Halbaddierer" oder "Volladdierer" oder "logische Bausteine". Der Aufwand hierfür wäre jedoch immens und teuer und wird zumeist nur in Bereichen wie z.B. der Erstellung von speziellen Programmen in der Avionik, der Raumfahrt oder Steuerung komplexer Waffensysteme eingesetzt; teilweise erfolgt die aber auch bei Komponenten wie Grafikkarten oder Steuerungschips auf Motherboards - die CPUs oder GPUs sind hingegen programmierbar.

C# und C++ --- kein Wunder, daß das langsam ist. C ist wesentlich besser. Maschinensprache ist der Code, sowie es die Maschine ausführt, aber es ist Folter darin zu programmieren. Ich habe nur mal nichtdokumentierte Z80 Befehle in Maschinensprache eingegeben, allerdings in Assemblercode als Datenbytes. Assembler ist eigentlich nur eine 1:1 Umsetzung von Namen für Maschinensprachebefehle in Maschinensprache (mit einigen kleinen Erweiterungen).

Für große Projekte ist weder Maschinensprache noch Assembler geeignet. Das hat 2 Gründe:

1) Ein Assemblerprogramierer schafft so ca 150 Befehle pro Tag, wenn der Code ausgetestet sein soll.

2) Die Programme laufen nur auf 1 CPU- Familie --- mit Sonderbefehlen nur auf einer CPU.

Assembler eignet sich nur für kleine Programme. In Microcontrollern mit ihrem begrenzten Speicher wird Assembler gern eingesetzt, also Programme für Waschmaschine, Geschirrspülmaschine etc.



@MeMeMe: Was Geschwindigkeit und Kürze von Assemblerprogammen angeht, die auch nur von einem mäßigen Programmierer programmiert worden sind, dürftest Du in einem schweren Irrtum sein.

Ich habe mich nie für C# interessiert. Da hat Bill Gates das UCSD-Pascalsystem aus den 70gern erneut erfunden. Mein 8080 CP/M 2.2 M-Basic hatte auch solchen Byte-Mode für die Speicherung ... da hat er wohl eingesehen, daß solch Code eine lahme Schnecke ist und hat eine kleine Anleihe bei Forth gemacht.

C++. Ich kann es nur manchmal - hat mich mal interessiert, ABER meine C++ Bemühungen endeten immer in der Frustration.

Also die Story: Ich lerne C++

Versuch Nr. 1: Ich mußte ins Krankenhaus. Hab ich gedacht lern mal C++, dann wirds nicht langweilig. Für 200 Märker 3 dicke Schwaten gekauft und ab ins Krankenbett. Jedes der Werke gab erst mal eine ausführliche Einführung in C --- nur ich bin ein ausgesprochner C-Fan --- ich programmierte schon 15 Jahre in C - das brauchte ich nicht lernen. Es war so langweilig, daß ich nicht vorankam, sondern immer ziemlich schnell einschlief.



Versuch Nr.2: Ich stöber in meinen Howtos und entdecke ein C++ Howto. Da stand drin, daß C++ nur wenig schlechteren Code und nur wenig mehr Speicher gebraucht als C. Und außerdem die pointer. Pointer halte ich für die größte Erungenschat von C. Da habe ich es aufgegeben und mich anderen Howtos zugewandt.



Versuch Nr. 3 Irgendwie hatte ich das Bedürfnis KDE-Funktionen in meine Programme mit einzubinden, also nächster Versuch C++ lernen. Also erst mal den Sinn prüfen. Vergleich dieses süße kleine Programm "hello world" in C und C++. In C übersetzte der Compiler das Programm so schnell, das merkte man gar nicht. Und lang war es etwas über 10 kb. In C++ dauerte es mehrere Minuten und das Programm brauchte Megabyte. Verständlich das man da die Ladezeiten auch merkte. Ich habe mal ein größeres Programmpaket auf einem Z80 geschrieben. Da dauerte das Übersetzen ähnlich lange. Da wollte ich nicht wieder hin. Ich habe es jetzt endgültig aufgegeben, C++ zu lernen.





@Aldarion: Du irrst, Maschinensprache ist kein Compiler!!! Maschinensprache ist eine Zahl, die für den Code steht, die der Prozessor direkt ausführen kann. Du kannst diese Zahl mit Editoren direkt in den Rechner eingeben (die Editoren haben oft die Möglichkeit den eingegebenen Code innerhalb des Editors auszuführen. Beispiel DDT.

Ein Assembler ist eine 1:1 Übersetzung von Mnemonics in Maschinensprache.



Ein Compiler ist ein Tool, das die Befehle nicht 1:1 übersetzt. Bei einem Compilat wird der ausführbare Kode gespeichert. Bei einem Interpreter wird der lesbare Text gespeichert und während der Abarbeitung immer erneut wieder übersetzt (richtig interpretiert). Es gibt eine Zwischenstufe, das ist der sogenannte P-Code Interpreter. Hier wird der Befehl durch eine oder mehrere Zahlen abgespeichert (das nimmt nicht soviel Platz weg) Speicher war früher teuer und stand nicht in ausreichendem Maß zur Verügung. Die 8 Bit Rechner hatten meist einen Adressraum von 64kB.