| Zeile 3: | Zeile 3: | ||
== Allgemeines == | == Allgemeines == | ||
=== Datengrößen === | === Datengrößen === | ||
| − | *Die Wortgröße des Prozessors zu verwenden ist meist vorteilhaft. ( | + | *Die Wortgröße des Prozessors zu verwenden ist meist vorteilhaft. (32 Bit bei i386, 64 Bit bei x86-64). |
=== Alignment === | === Alignment === | ||
| Zeile 9: | Zeile 9: | ||
* Wenn man aber gezwungen ist, Code und Daten zu mischen, dann sollte man die Daten so legen, dass Sprünge nicht darüber hinweg springen müssen. | * Wenn man aber gezwungen ist, Code und Daten zu mischen, dann sollte man die Daten so legen, dass Sprünge nicht darüber hinweg springen müssen. | ||
* Selbst modifizierender Code widerspricht diesem Prinzip. | * Selbst modifizierender Code widerspricht diesem Prinzip. | ||
| − | * Sprungziele sollten am Anfang eines Paragrafs ( | + | * Sprungziele sollten am Anfang eines Paragrafs (16 Byte) stehen. |
| + | |||
| + | * Die CPU hat einen internen Datencache von 64 KiB. | ||
| + | Daten, die über eine 64 KiB Grenze verteilt sind, müssen dann zweimal gecacht werden, was die Performance mindert. Somit sollten Daten ihrer Größe entsprechen ausgerichtet werden, also z. B. DWORDs auch nur am Anfang der 4 Byte Grenzen. | ||
| − | + | * Ebenso sollte der [[Stack]] 64 KiB aligned sein, und die Größe seiner Elemente gleich bleiben. | |
| − | |||
| − | |||
| − | * Ebenso sollte der [[Stack]] | ||
=== Sprünge und Schleifen === | === Sprünge und Schleifen === | ||
| Zeile 30: | Zeile 30: | ||
* Je weniger Sprünge, desto effektiver kann der Code gecacht werden. | * Je weniger Sprünge, desto effektiver kann der Code gecacht werden. | ||
* Die CPU kann bis zu 16 verschachtelte Funktionsaufrufe cachen, mehr als 16 Verschachtelungen verringern die Performance. | * Die CPU kann bis zu 16 verschachtelte Funktionsaufrufe cachen, mehr als 16 Verschachtelungen verringern die Performance. | ||
| − | * Die CPU kann Befehle am besten cachen, die weniger als | + | * Die CPU kann Befehle am besten cachen, die weniger als 8 Byte lang sind. Außerdem sollten dabei WORD-Konstanten vermieden werden. Komplexe Befehle wie sysenter oder leave |
* Alignments sollten immer eingehalten werden! | * Alignments sollten immer eingehalten werden! | ||
| Zeile 89: | Zeile 89: | ||
* -Os (s ist keine Variable, sondern wird genau so gesetzt!) | * -Os (s ist keine Variable, sondern wird genau so gesetzt!) | ||
| − | '-Os' veranlasst den Compiler, nicht unbedingt performanten Code, aber auf jeden Fall kleine Programme zu erzeugen („size optimisation“). 'Ox' dagegen führt dazu, dass verschiedene Optimierungen zur Geschwindigkeitsverbesserung eingeschaltet werden. '-O3' ist die höchste Stufe, führt aber bei einigen Programmen zu Problemen (z. | + | '-Os' veranlasst den Compiler, nicht unbedingt performanten Code, aber auf jeden Fall kleine Programme zu erzeugen („size optimisation“). 'Ox' dagegen führt dazu, dass verschiedene Optimierungen zur Geschwindigkeitsverbesserung eingeschaltet werden. '-O3' ist die höchste Stufe, führt aber bei einigen Programmen zu Problemen (z. B. empfiehlt Gentoo, -O2 und nicht -O3 zum Kompilieren des Systems zu nutzen). Das sollte jeder für seine Software selbst ausprobieren. |
Übrigens kann man mit NASM die Codeoptimierung mit '-Ox' (hier ist x keine Variable!) einschalten. Dies ist jedoch nicht nötig, da das Flag standardmäßig aktiviert ist. Jedoch bleibt NASM ein Assembler, und so ist es dennoch sehr wichtig, die oben beschriebenen Optimierungsvorschläge auch zu nutzen. | Übrigens kann man mit NASM die Codeoptimierung mit '-Ox' (hier ist x keine Variable!) einschalten. Dies ist jedoch nicht nötig, da das Flag standardmäßig aktiviert ist. Jedoch bleibt NASM ein Assembler, und so ist es dennoch sehr wichtig, die oben beschriebenen Optimierungsvorschläge auch zu nutzen. | ||
| Zeile 98: | Zeile 98: | ||
=== Hinweise === | === Hinweise === | ||
| − | Oftmals gibt es unter anderem im Lowlevel-Forum, aber auch an anderen feinen Orten hitzige Diskussionen darüber, ob man selber Code optimieren sollte oder dies dem Compiler überlassen sollte. Generell gilt: Man muss nicht stundenlang über dem vom GCC generierten Code hängen und diesen bis zum Geht-nicht-mehr optimieren. Moderne Compiler wie der GCC optimieren sehr gut, der Programmierer kann da wenig noch von Hand optimieren. Es gibt natürlich auch Ausnahmen, wo eigene Optimierungen besser sind als die vom Compiler generierten. Diese Thematik tritt sehr oft bei String-Funktionen auf, wo viele Enthusiasten gerne eine handgeschriebene und hand"optimierte" Assembler-Version der Funktionen dem z. | + | Oftmals gibt es unter anderem im Lowlevel-Forum, aber auch an anderen feinen Orten hitzige Diskussionen darüber, ob man selber Code optimieren sollte oder dies dem Compiler überlassen sollte. Generell gilt: Man muss nicht stundenlang über dem vom GCC generierten Code hängen und diesen bis zum Geht-nicht-mehr optimieren. Moderne Compiler wie der GCC optimieren sehr gut, der Programmierer kann da wenig noch von Hand optimieren. Es gibt natürlich auch Ausnahmen, wo eigene Optimierungen besser sind als die vom Compiler generierten. Diese Thematik tritt sehr oft bei String-Funktionen auf, wo viele Enthusiasten gerne eine handgeschriebene und hand"optimierte" Assembler-Version der Funktionen dem z. B. C-Äquivalent vorziehen. Hier hat sich oft gezeigt, dass der vom GCC optimierte Assembler-Code gleich oder sogar schneller ist als der händisch geschriebene und optimierte Assembler-Code. |
== siehe auch == | == siehe auch == | ||
| Zeile 107: | Zeile 107: | ||
*[http://support.amd.com/us/Processor_TechDocs/25112.PDF AMD - Software Optimierung für AMD64] | *[http://support.amd.com/us/Processor_TechDocs/25112.PDF AMD - Software Optimierung für AMD64] | ||
| − | |||
[[Kategorie:x86]] | [[Kategorie:x86]] | ||
[[en:Optimizing]] | [[en:Optimizing]] | ||