Inline-Assembler

NEO.PIXEL

Hallo Leute,

ich hab mich in letzter Zeit ein wenig mit Inline-Assembler unter C/C++ beschäftigt und soweit sieht das auch recht simpel aus, sofern man etwas Ahnung von Assembler hat

Ich verstehe aber noch nicht so ganz unter welchen Umständen man nun damit wirklich Code optimieren kann..

Wenn man jetzt z.B. einen Bubblesort-Algorithmus mit Inline-Assembler realisiert,
läuft dieser dann grundsätzlich schneller/speichereffizienter als ein in C++
geschriebener?
Oder ist das wie so oft abhängig Compiler oder so?

theta

Wenn man jetzt z.B. einen Bubblesort-Algorithmus mit Inline-Assembler realisiert,
läuft dieser dann grundsätzlich schneller/speichereffizienter als ein in C++
geschriebener?

Erklär mir mal warum sowas Grundsätzlich schneller/effizienter sein sollte?

NEO.PIXEL

Genau das will ich ja wissen..
Was genau und unter welchen Umständen kann man damit optimieren?

wxSkip

Du kannst das vermutlich nur optimieren, wenn du in deinem inline-Assembler spezielle Befehle verwendest oder spezielle Verläufe optimierst. Grundsätzlich wirst du aber bei Bubblesort keinen Geschwindigkeitsvorteil erwarten können, zumal inline-Assembler nicht standardisiert ist und beim GCC anders aussieht als beim MSVC.

NEO.PIXEL schrieb:

Was genau und unter welchen Umständen kann man damit optimieren?

Wenn du schlauer bist als der Compiler, also zum Beispiel irgendwelche Garantien hast, die du dem Compiler nicht kar machen kannst, aber den Assemlercode optimieren würden.

Lohnen tut sich das alles aber nur bei ganz speziellen Stellen, die im Vergleich zum restlichen Programm sehr sehr oft durchlaufen werden. Also eigentlich nie.

SeppJ

Ein extrem begabter Programmierer kann eventuell einen Algorithmus in Assembler schreiben, der schneller sein kann, als in einer Hochsprache. Dies kann vorkommen, wenn man die Konstrukte der Hochsprache die einen Overhead haben nicht benötigt. In C fällt es mir schwer, dafür ein Beispiel zu finden, da C schon sehr low-level ist.
Es ist auch möglich, gewisse Optimierungen vorzunehmen, weil man eventuell Zusatzinformationen, z.B. über mögliches Pointeraliasing, nutzen kann, die der Compiler nicht zur Verfügung hat.
Und zu guter letzt kann man eventuell maschinenspezifische Befehle und Besonderheiten nutzen, die noch nicht in den Compiler eingebaut wurden.

Aber das alles können nur sehr erfahrene Programmierer besser als ein Compiler und der Einsatz von Inlineassembler zur Optimierung ist eine aussterbende Kunst.

(Dir ist hoffentlich bewusst, dass dies nicht der einzige Einsatzzweck von Inlineassembler ist. Inlineassembler an sich ist schon noch äußerst wichtig)

NEO.PIXEL

Also kann man sagen, dass es sich nur bei Compilern lohnt, die nicht selbst
"gut" optimieren, weil zu alt oder so oder wenn man ein Codesegment hat, welches
sehr oft wiederholt wird..:

inline void swap(unsigned int& a, unsigned int& b)
{
  _asm
  {
    mov ax, a
    xchg ax, b
    mov a, ax
  }
}

/* Bubblesort
 *
 */
swap(a, b);
/*
 *
 */

Würde so etwas dann Sinn machen oder würde ein moderner Compiler selbst so etwas
weg optimieren?

NEO.PIXEL

SeppJ schrieb:

(Dir ist hoffentlich bewusst, dass dies nicht der einzige Einsatzzweck von Inlineassembler ist. Inlineassembler an sich ist schon noch äußerst wichtig)

Was denn z.B.?

Frezee

Ich benutze Inline Assembler eigentlich nur um z.B. einen KeyGen zu programmieren.
Die Algorithmen des Originalprogramms muss ich dann nur kopieren und kleinere Änderungen vornehmen. Dann muss ich nicht alles neu schreiben.

SeppJ

NEO.PIXEL schrieb:

Würde so etwas dann Sinn machen oder würde ein moderner Compiler selbst so etwas
weg optimieren?

Das würde dein Compiler(und zwar jeder) mindestens genau so gut oder besser machen. Du musst schon etwas einigermaßen komplexes Handoptimieren, wo die Maschine eventuell irgendwelche Zusammenhänge nicht sehen kann, die einem menschlichen Programmierer bekannt sind.

Was denn z.B.?

Na, für alles was die Sprache nicht hergibt. Was dachtest du denn, wie die ganzen Betriebssystemaufrufe funktionieren oder wie man spezielle Hardware ansteuert? Ohne Assembler wäre C++ nur dazu gut, einen abstrahierten schwarzen Kasten mit einer Ein-/Ausgabe über einen (abstrahierten) Lochstreifen zu programmieren. Mit Assemblerbibliotheken ist es eine Weltsprache.

abc.w

NEO.PIXEL schrieb:

inline void swap(unsigned int& a, unsigned int& b)
{
  _asm
  {
    mov ax, a
    xchg ax, b
    mov a, ax
  }
}
Würde so etwas dann Sinn machen oder würde ein moderner Compiler selbst so etwas
weg optimieren?

Was meinst du mit wegoptimieren... Übrigens, xchg-Befehl ist toll, aber mit Speicheroperanden langsam (ich habe das mal "gemessen": http://www.c-plusplus.net/forum/238127). Dann versuchst du wahrscheinlich 32 Bit Variablen in 16 Bit Register zu laden...

Ethon

Lies dich mal hier durch: http://www.agner.org/optimize/

Als Beispiel könntest du dir die optimierten Versionen von memcpy etc ansehen, die mit den 128bit-Registern kopieren usw.

NEO.PIXEL

@ Ethon:
So was hatte ich gesucht..
Danke

@ abc.w
Also wäre es bei xchg sinnvoll beide Variablen ins Register zu laden und dann
erst zu tauschen?
Und seit wann ist unsigned int == 32bit? Oder was meinst du damit?

abc.w

NEO.PIXEL schrieb:

Also wäre es bei xchg sinnvoll beide Variablen ins Register zu laden und dann erst zu tauschen?

Ob sinvoll ist - weiß ich nicht. Man könnte auch einfach so was machen:

mov ax, a
mov bx, b
mov b, ax
mov a, bx

Am Besten selber messen und vergleichen. Lesen, was andere dazu meinen oder welche Erfahrungen sie damit gemacht haben, bei sich ausprobieren und wieder vergleichen. Das sinnvollste ist auf jeden Fall, mehrere Möglichkeiten implementieren, messen und vergleichen. Dann lässt sich aussagen, ob etwas schneller ist oder nicht.

NEO.PIXEL schrieb:

Und seit wann ist unsigned int == 32bit? Oder was meinst du damit?

Ach so, meinst du sizeof(unsigned int) ist bei deinem Compiler 2 Bytes? Habe ich noch nie gesehen... ich würde sagen, benutze am Besten uint16_t oder füge in deinem Code so was wie:

typedef char check_for_unsigned_int[(sizeof(unsigned int) == 2) ? 1 : -1];

damit der Code nicht baut und man auf diesen Umstand gleich aufmerksam wird, wenn jemand den Code portieren soll... aber andererseits verwendest du Inline-Assembler und damit ist dein Code bereits auf deinen Compiler festgenagelt, also nicht mehr portabel und so gesehen, macht es keinen Sinn, irgendwelche Checks einzubauen oder sich über Datentypen Gedanken zu machen...

NEO.PIXEL

Ok unsigned int ist tatsächlich 4 Byte groß.. Mein Fehler

Hab dann jetzt einfach mal versucht mit den mir bekannten Mitteln selbst nachzumessen:

#include <iostream>
#include <ctime>

inline void swap_cpp(int& a, int& b)
{
  int temp = a;
  a = b;
  b = temp;
}

inline void swap_mov(int& a, int& b)
{
  asm volatile("mov ecx, eax\n\t"
	       "mov eax, ebx\n\t"
	       "mov ebx, ecx"
	       :"=a"(a), "=b"(b)
	       :"a"(a), "b"(b));
}

inline void swap_xchg(int& a, int& b)
{
  asm volatile("xchg eax, ebx" : "=a"(a), "=b"(b) : "a"(a), "b"(b));
}

inline void show(const char* c, clock_t& s, clock_t& e)
{
  std::cout<<c
	   <<":\t\t"
	   <<(e-s)/(0.001*CLOCKS_PER_SEC)
	   <<" ms"
	   <<std::endl;
}

int main(void)
{
  int a = 789, b = -987;
  clock_t start, end;
  const unsigned L = 1e8;

  start = clock();
  for(unsigned i = 0; i < L; i++)	swap_cpp(a, b);
  end = clock();
  show("swap_cpp", start, end);

  start = clock();
  for(unsigned i = 0; i < L; i++)	swap_mov(a, b);
  end = clock();
  show("swap_mov", start, end);

  start = clock();
  for(unsigned i = 0; i < L; i++)	swap_xchg(a, b);
  end = clock();
  show("swap_xchg", start, end);

  return 0;
}

Ergebnis:

swap_cpp: 2210 ms
swap_mov: 2520 ms
swap_xchg: 2490 ms

Womit der Compiler (gcc version 4.5.2, Ubuntu) klar gewonnen hat
Aber xchg scheint, sofern beide Variablen im Register, schneller zu sein als mov..

Pikkolini

Der Compiler ist eigentlich sehr oft besser als der Otto-Normal-Programmierer

void swap(int a, int b) {
	int temp = a;
	a = b;
	b = temp;
}

int main()
{
	int a = 42;
	int b = 23;
	swap(a,b);
	std::cout << a << b << std::endl;
	return 0;
}

Bei diesem Code wird das swap z.B. einfach wegoptimiert und der Compiler macht aus
std::cout << a << b << std::endl;
einfach
std::cout << b << a << std::endl;
Und das schaffste mit Inline-Assembler in dieser Form (mit meinen Kentnissen) nicht.

abc.w

NEO.PIXEL schrieb:

Ergebnis: ...
Womit der Compiler (gcc version 4.5.2, Ubuntu) klar gewonnen hat
Aber xchg scheint, sofern beide Variablen im Register, schneller zu sein als mov..

Ich würde jetzt noch mit ein Paar Compiler-Optionen rumspielen: -Os, -O2, -O3. Dann noch immer schön -g0 verwenden. Dann immer Warnungen einschalten: -Wall -Wextra -Werror -pedantic...

g++ main.cpp -o main -Os -g0 -Wall -Wextra -Werror -pedantic
g++ main.cpp -o main -O2 -g0 -Wall -Wextra -Werror -pedantic
g++ main.cpp -o main -O3 -g0 -Wall -Wextra -Werror -pedantic

Pikkolini schrieb:

void swap(int a, int b) {
	int temp = a;
	a = b;
	b = temp;
}

...

Ih glaube, du hast dich vertippt... Diese swap-Funktion wird natürlich wegoptimiert, weil sie nichts zurückgibt und im Prinzip nichts wirklich verändert...

NEO.PIXEL

Hab mal mit den Compileroptionen rumgespielt..

Ergebnis nach Weiteroptimieren mit -Os, -O2, -O3:

swap_cpp: 250 ms
swap_mov: 270 ms
swap_xchg: 690 ms

Jetzt ist xchg tatsächlich mit Abstand am langsamsten..

camper

Optimierungen dieser Art sind... keine.
Die einzig brauchbare Form von Assembler-swap sieht so aus (ist zudem sehr portabel):

void swap(int& a, int& b)
{
    asm( "" : "=x" (a), "=x" (b) : "1" (a), "0" (b));
}

Besser als normaler Dreickstausch ist das allerdings ebenso nicht.

volkard

NEO.PIXEL schrieb:

inline void swap_mov(int& a, int& b)
{
  asm volatile("mov ecx, eax\n\t"
	       "mov eax, ebx\n\t"
	       "mov ebx, ecx"
	       :"=a"(a), "=b"(b)
	       :"a"(a), "b"(b));
}

Das kettet die drei movs leider direkt aneinander und der Compiler traut sich nicht, über Deinen Code nachzudenken, und ihn mit seinem zu vermischen und vielleicht was dazuwischenzumachen, was gerade vom Pipeline-Füllen oder Sprungzielausrichten oder so ihm gerade am besten passen würde, oder vielleicht braucht er eax und ebx für was besseres und hätte esi und edi gerade frei?

Generell versuche ich, dem Compiler maximale Freiheit zu lassen.