Was bringt Assembler so?

[Lin728]

Hallo!

Ich wollte fragen, ob jemand ungefähr weiß, was assembler noch geschwindigkeitsmäßig so bringt verglichen mit gutem C-Code?

Also ganz fair guter C-Code gegen guten Assembler.

Natürlich gibts Spezialfälle wo Assembler 100x schneller sein kann, einfach weil man in C Sachen durch Algorythmen implementieren muss, was die CPU manchmal mit ein paar Befehlen wegschaufelt.

[SeeksTheMoon]

Ich frage mich ob Kompressionsalgorithmen "normal" sind...
Wenn es richtig um die Wurst geht, dann wählt man in der Regel Assembler, weil der Programmierer da maximale Kontrolle hat.

Das kenne ich hier aus einem Institut: Codecs (und andere, besonders mathematiklastige Algorithmen)
Dort wird um jedes Bit und jedes Register gekämpft um maximale Effizienz zu bekommen.
Sowas kann man dann nicht mehr dem C-Compiler zur Optimierung überlassen, das schreibt man dann direkt in Assembler.

Bei manchen Bibliotheken, die besonders effizient/hardwarenah sein wollen/müssen, nimmt man natürlich auch Assembler, was aber nicht immer aus Gründen der Geschwindigkeit passieren muss.

[Pingu]

Du müßtest zuerst einmal definieren was "guter" Code heißt.

Assembler wird im Wesentlichen wegen zwei Gründen gegenüber jeder Hochsprache vorgezogen: 1. wegen der Schnelligkeit (wie schon angesprochen). Die geschieht dadurch, daß man in einer Hochsprache keine Kontrolle hat wor die Daten zwischen gespeichert werden (Stack oder Register). Da die Datenübergabe über Register gegenüber der Stackablage schneller ist, kann man in Assembler auch Programme schreiben, die etwas schneller sind, als wenn sie in einer Hochsprache programmiert sind. Wie dies auch noch in eine Schleife ist, die entsprechend häufig ausgeführt wird, kann sie der Geschwindigkeitsgewinn entsprechend potenzieren. Weitere Geschwindigkeitsvorteile ergeben sich daraus, daß bei Funktionsaufrufen in Hochsprachen meistens der komplette Registersatz auf dem Stack gesichert wird und beim Rücksprung wieder zurück geschrieben wird. Die ist vielleicht aber nicht immer notwendig.
2. wegen des Resourcenverbrauchs. Denn gerade in Microcontrollern ist der verfügbare ROM (bis 256 KiB) und der verfügbare RAM (bis 8 KiB) sehr beschränkt, daher muß entsprechend Resourcenschonend programmiert werden. Leider sind die Hochsprachencompiler nicht unbedingt sehr Resourcensparend.

Übrigens diese beiden Ziele widersprechen sich gegenseitig. Deswegen die Frage: Was ist guter Code?

Pingu:

PS: Algorithmus wird immernoch mit i geschrieben und nicht mit y.

[Lin728]

Das kenne ich hier aus einem Institut: Codecs (und andere, besonders mathematiklastige Algorithmen)
Dort wird um jedes Bit und jedes Register gekämpft um maximale Effizienz zu bekommen.
Sowas kann man dann nicht mehr dem C-Compiler zur Optimierung überlassen, das schreibt man dann direkt in Assembler.

Was kann man da ungefähr mehr raushohlen. Mein Beispiel würde ziemlich genau eine derartige Anwendung betreffen (2D software-rendering).
Dabei werden allerdings (leider) auch viel RAM/IO gemacht, naja ist aber alles linear und sollte so gut in den cache passen...



Assembler wird im Wesentlichen wegen zwei Gründen gegenüber jeder Hochsprache vorgezogen: 1. wegen der Schnelligkeit (wie schon angesprochen). Die geschieht dadurch, daß man in einer Hochsprache keine Kontrolle hat wor die Daten zwischen gespeichert werden (Stack oder Register). Da die Datenübergabe über Register gegenüber der Stackablage schneller ist, kann man in Assembler auch Programme schreiben, die etwas schneller sind, als wenn sie in einer Hochsprache programmiert sind. Wie dies auch noch in eine Schleife ist, die entsprechend häufig ausgeführt wird, kann sie der Geschwindigkeitsgewinn entsprechend potenzieren. Weitere Geschwindigkeitsvorteile ergeben sich daraus, daß bei Funktionsaufrufen in Hochsprachen meistens der komplette Registersatz auf dem Stack gesichert wird und beim Rücksprung wieder zurück geschrieben wird. Die ist vielleicht aber nicht immer notwendig.

Hmm, deine Beschreibung gleicht Compilern aus der Ur-Steinzeit. Ich hab mir den Code mal angeseh den der ICC generiert (Intel C Compiler) und da hab ich derartige unnötige Ineffiziente Sachen eigentlich nie gesehen (wieso register am stack sichern, dass nie verwendet wird?).

[Pingu]

Hmm, deine Beschreibung gleicht Compilern aus der Ur-Steinzeit.
Meinst DU? Dann schau Dir mal den Code an, den die Compiler von Keil oder Altium hervorbringen. Wobei die noch relativ gut sind. Richtig schlecht sind die Compiler direkt von der Chipherstellern, sei es nun Atmel, Renesas,

Ich hab mir den Code mal angeseh den der ICC generiert (Intel C Compiler) und da hab ich derartige unnötige Ineffiziente Sachen eigentlich nie gesehen (wieso register am stack sichern, dass nie verwendet wird?).
Der ICC ist in gewisser Weise eine Ausnahmeerscheinung. Warum? Weil Intel damit die Leistungsfähigkeit seiner Prozessoren darlegen möchte. Deshalb hat Intel einen sehr gut optimierenden Compiler geschrieben.
Unabhängig davon Du hast noch nie die Befehle pusha (http://www.itis.mn.it/linux/quarta/x86/pusha.htm)/popa (http://www.itis.mn.it/linux/quarta/x86/popa.htm) in Verbindung mit Funktionsaufrufen gesehen? Denn was machen die Befehle? Sie sichern alle Register, unabhängig davon ob sie in der Funktion gebraucht werden oder nicht.

Pingu

PS: Wenn Du im verlinkten Manual nachsiehst, siehst Du daß diese Befehle 24 Taktzyklen verbrauchen.

[Lin728]

Microcontroller sind da sowieso anderes Gefielde, da sehr oft die compilerhersteller nur wneig direkte Konkurenz haben und Performance (ausder bei DSP) oft nicht so im Vordergrund steht.

Auch ja, dein popa/pusha hat vieleicht beim 386er 24 Takte gebraucht, aber sogar der Pentium machts schon in 5. Und da überleg ichs mir dann, was ich einzeln wohin schiebe ;-)

[anda_skoa]

Das ist praktisch immer eine Kompromissfrage. Jeweiter man in der Abstraktion runter geht, desto unportabler ist es und desto besser müssen die Entwickler sein.

Bei einem DSP wird ziemlich sicher bald mal in Assembler geschrieben, weil selbst die guten Compiler nur nach Theorien optimieren können, während die Entwickler das Problem ansich besser aufteilen können.

Sobald man in einem Multitasking System ist, wird es weniger sinnvoll, aber natürlich noch nicht sinnlos.
Aber dann hat man meisten die Möglichkeit, zuerst eine Highlevel Implementation zu machen und bei Bedarf später Teile zu optimieren.

Ciao,
_

[Pingu]

Microcontroller sind da sowieso anderes Gefielde, da sehr oft die compilerhersteller nur wneig direkte Konkurenz haben und Performance (ausder bei DSP) oft nicht so im Vordergrund steht.
Wie kommst Du darauf das bei Microcontrollern die Performance nicht im Vordergrund steht. Gerade hier. Denn wenn ich wegen Performance Gründen eine Version größer wählen muß, heißt das auch meisten fast den doppelt Preis. Und Du weißt: Geiz ist Geil. Das gillt in besonderem Maße im Automobilsektor (lieber ein oder zwei 8-bit Mircocontroller als ein 16-bit Microcontroller, weil selbst zwei 8-bitter sind billiger als ein 16-bitter). Aber es gilt auch analog für alle anderen Industrien, z.B. Aufzugstechnik mit Expressaufzügen bis zu 10 m/s und 16-bitter oder DVD-Player.

Pingu

[Lin728]

Wie kommst Du darauf das bei Microcontrollern die Performance nicht im Vordergrund steht. Gerade hier. Denn wenn ich wegen Performance Gründen eine Version größer wählen muß, heißt das auch meisten fast den doppelt Preis.

Und genau das wollen doch die Chip-Hersteller, wieso sollten sie dann selbst einen Compiler bis zum geht nimma optimieren ;-)

Und weil eben die chips alle unterschiedliche befehlssätze haben, gibts zwar pro cpu-generation nicht 20 compiler die um die performance-krone ringen, sondern wenns gut geht 2,3. Ausgenommen sind chip-urgesteine wie 8051 und konsorten...