optimieren: ASM vs. Compiler

[elianda]

Aus gegebenen Anlass, wuerde es mich einmal interessieren, ob man heutzutage in ASM noch sinnvoll gegenueber einem Compiler den Code optimieren kann in Bezug auf Geschwindigkeit.

[Coda]

Kommt drauf an. Bei x87-FPU-Code wirds wirklich schwierig, da du das ganze OOO-Zeug gar nicht mehr durchblicken kannst zusammen mit dem Registerstack.

Wenn man viel Zeit investiert kann man sicher noch was rausholen, aber Kosten/Nutzen seh ich da nicht mehr in Relation.

[Trap]

SIMD-Code in allen Varianten können Compiler noch nicht brauchbar erzeugen, wenn der Algorithmus sich dafür anbietet kann man da durchaus noch viel gegenüber einem Compiler rausholen, allerdings mit recht viel Aufwand. Würde ich aber mit intrinsics machen, nicht mit ASM.

Fließkommaalgorithmen bei denen numerische Stabilität das Hauptkriterium ist. Die meisten Hochsprachen geben einem nicht genug Kontrolle über den genauen Ablauf der Rechnung um solchen Code überhaupt zu schreiben.

Innerste Schleifen in sehr oft genutzem und wichtigem Code wie bignum-libs, fft, blas, lapack.

[zeckensack]

GCC ist erstaunlich blöd auf ARM-Prozessoren ... auf einem ARM kann man alles deutlich besser machen, indem man in Assembler schreibt. C sollte man da eher als "rapid prototyping"-Krücke verstehen :|

Auf ausgewachsenen Prozessoren mit OOOE und guten Caches ist's meist eine blöde Idee mit einem modernen Compiler konkurrieren zu wollen. Wobei automatische SIMD-Optimierungen noch in den Kinderschuhen stecken, ja.

edit: Auszug aus einem real existierenden ARM-Projekt.
(Ist allerdings nur ein plumper Text-Renderer für Bitmap-Fonts)
u32
some_thing(const u8* t)
{
u32 len=0;
while(t[len]!=0)
{
<...>
}
}Scannt vorwärts durch einen String. Wollen wir mal schauen was GCC aus der Schleifenbedingung macht?
ldrb r3, [r1, r0] @ * len
add r2, r3, #0
lsl r3, r2, #24
cmp r3, #0
bne .L6Mal ganz davon abgesehen dass t nun in r1 ist statt in r0 (nach calling convention), weil GCC überflüssige Registerumverteilungen geradezu liebt.
Warum zur Hölle muss man einen Wert den man als Byte gelesen hat mit Null aufaddieren, und dann (merke: ein Byte besteht aus 8 Bits) die nicht vorhandenen oberen 24 Bit abschneiden? Und warum muss man nach zwei sinnlosen Instruktionen die beide als Seiteneffekt Flags setzen nochmal eine Vergleichsinstruktion einbauen?

[micki]

GCC ist erstaunlich blöd auf ARM-Prozessoren ... auf einem ARM kann man alles deutlich besser machen, indem man in Assembler schreibt. C sollte man da eher als "rapid prototyping"-Krücke verstehen :|
an manchen stellen ist gcc sehr smart bei arm. aber größtenteils ist es wirklich sucky. z.b. mußte ich mir öfter so bloppte dinge antun wie

u32 a;
for(a=0;a<32;a+=2)
*((u16*)&(((u8*)pBuffer)[a]))=u16data;

weil der sonst in jeder runde *2 rechnete bei

u32 a;
for(a=0;a<16;++a)
pBuffer[a]=u16data;



Auf ausgewachsenen Prozessoren mit OOOE und guten Caches ist's meist eine blöde Idee mit einem modernen Compiler konkurrieren zu wollen. Wobei automatische SIMD-Optimierungen noch in den Kinderschuhen stecken, ja.
moderne compiler sind öfters extrem dämlich, man sollte sich performancekritische stellen zumindestens in assembler ansehen um rauszufinden, ob dabei wirklich das optimale rauskommt. das VS05 hat in nem source bei mir, gegenüber dem VS03 folgendes eingebaut

00404998 jmp CBSPNode::Trace+20h (4049A0h)
0040499A lea ebx,[ebx]
004049A0 ...
40499a wird nie angesprungen/durchlaufen und da es eine sehr wichtige stelle ist, ist das programm ca 10% langsammer geworden. (siehe dazu meine signatur ;) )

der cg hat bis zur letzten version auch sehr sehr unoptimalen code generiert.

aber wenn man eine sinnvolle optimierung erreichen möchte, sind templates oft die bessere wahl gegenüber assembler, weil sie generisch an vielen stellen angewand werden können, statt dem assembler mit dem man nur eine stelle optimiert.

[ollix]

aber wenn man eine sinnvolle optimierung erreichen möchte, sind templates oft die bessere wahl gegenüber assembler, weil sie generisch an vielen stellen angewand werden können, statt dem assembler mit dem man nur eine stelle optimiert. Wie löst man denn mit Templates ein Assembler Problem?

[Coda]

http://www.flipcode.com/cgi-bin/fcarticles.cgi?show=63820

[micki]

Wie löst man denn mit Templates ein Assembler Problem?
ein gutes tut dazu ist:
http://www.flipcode.com/articles/article_fastervectormath.shtml

[Coda]

Warum zur Hölle muss man einen Wert den man als Byte gelesen hat mit Null aufaddieren, und dann (merke: ein Byte besteht aus 8 Bits) die nicht vorhandenen oberen 24 Bit abschneiden? Und warum muss man nach zwei sinnlosen Instruktionen die beide als Seiteneffekt Flags setzen nochmal eine Vergleichsinstruktion einbauen?
Einfach köstlich ;D
Habs jetzt erst gelesen ;)

[micki]

@zeckensack
sicher dass -O3 drinne ist? soviel schwachsinn hat der gcc bei mir sonst nicht produziert, eher im gegenteil, wenn es ums optimieren von while-konstrukten und um shiften geht war der sehr smart... wobei es sein kann dass dein thumb code anders gehandhabt wird als der echte arm-assembler.