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?

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?

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.

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)

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?

(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.?

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.

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...

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

@ 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?

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...

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..

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.

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...

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..

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

Besser als normaler Dreickstausch ist das allerdings ebenso nicht.

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.

Ich beschäftige mich mit Grafikprogrammierung und daher auch ein wenig mit der Mathematik dahinter. Wenn ich da irgendwelche Matrizenoperationen oder z.B. nen schnellen Sinus per Polynom oder Taylorreihe annähere, dann lese ich oft auch was über SSE-Optimierungen in Assembler.

Ich habe seit dem C64 und Amiga nix mehr mit Assembler gemacht, aber ich meine gelesen zu haben dass man mit SSE so Rechnungen wie Addition und Multiplikation in einem Rutsch machen kann?

Gruß Chris

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.?

Ich arbeite in einer Anwendung mit Fixed-Point-Arithmetik, und muss dort häufig Float-Werte in Fixed-Werte überführen (runden, nicht abschneiden). Das geht unter POSIX-Systemen wunderbar mit lrint . Unter Windows gibt es leider kein lrint . +0.5 und dann casten ist grausam langsam (die Funktion wird im Code extrem häufig ausgeführt). Daher benutze ich unter Windows folgendes kleines asm dafür:

inline long round(float val)
{
    long result;
    _asm
    {
        fld val
        fistp result
    }
    return result;
}

Das hat ca. 350% Zuwachs (auf einem Pentium M) an Leistung gebracht.

Edit: Wobei ich gerade sehe, dass dies bei MSVC 2008 wohl auch überflüssig ist. Da wird __ftol2_sse für die Konvertierung mittels Cast benutzt..

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));
}

Portabel

# g++ -c tmp.c
tmp.c: In function `void swap(int&, int&)':
tmp.c:3: error: impossible constraint in `asm'

Toll

camper schrieb:

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));
}

Portabel

Jedenfalls funktioniert es ohne Anpassung auf jeder Plattform, die von gcc unterstützt wird, da ja die Anweisung selbst keine Code emittiert.

abc.w schrieb:

# g++ -c tmp.c
tmp.c: In function `void swap(int&, int&)':
tmp.c:3: error: impossible constraint in `asm'

Toll

Falscher Code oder falscher Compiler. gcc-4.5.2 schluckt es und macht auch das Richtige damit. Die Fehlermeldung ist jedenfalls verdächtig unwahrscheinlich.

Mich wundert diese Assembler Interesse etwas - der Compiler macht doch auch nichts anderes als Assembler. Der wird wohl kaum Additionen und so in fünf Schritten machen ... Ich stand bisher auf dem Standpunkt das Assembler nur nützt wenn man Insiderwissen hat oder wirklich auf 99.8% statt 99.437% Performance aus ist? Und wenn man nicht misst oder deassembliert landet man schnell bei 99.02% weil man was weniger schlau macht als der Compiler? _Gerade_ für Grafikzeug, wäre es da nicht vorteilhafter wenn man immer wiederkehrende Rechnungn auf der GPU ausführt statt die CPU mit eigenem Assembler besser auslasten zu wollen?

Das Assemblerinteresse ist halt noch von früher da, dort habe ich so kleine Grafikdemos programmiert und da ging ohne Assembler gar nix. Das war aber auch nicht sonderlich schlimm, man hatte nur mehr Tipparbeit, aber von der Sprache her habe ich die Grundlagen nie wieder zu schnell lernen können, wie die von Assembler

Ne mir ist schon klar, dass man heute das kaum noch braucht, und die Compiler da bestimmt viel besser optimieren wie ich. Bei meinen Recherchen nach Algorithmen und deren Implementierung, bin ich halt immer wieder auf Funktionen mit Inline-Assembler gestoßen, also denke ich mir dass sich da doch noch eine Menge optimieren läßt. Ich glaube bei denen ging es auch nicht um ein paar Prozent, sondern gleich um 30% oder noch mehr.

Da ich einen Software-Renderer unter Windows schreiben will, brauche ich keine programmierbare GPU oder ein GUI-Framework das portabel ist. Da reicht C und WinAPI völlig aus, es dient eh nur meiner eigenen Neugier.

Gruß Chris