Troufnu si tvrdit, ze GCC to umi lip nez to zvladnete rucne ;-) Nebo budete pocitat i s takovymi detaily, jestli je vyhodnejsi udelat "push %eax" nebo radeji "mov %eax, (%esp); sub %esp, 4"? GCC tohle vsechno vi a umi zohlednit.
Ale nechci se vas dotknout, mozna to skutecne GCC trumfnete :-)
Gcc generuje ne uplne dobry kod. Typicky pripad, ktery gcc nezvladne zoptimalizovat je, kdyz mate ve funkci rychlou casto pouzivanou cestu, ktere staci k vykonani registry, ktere neni treba ukladat (eax, ecx, edx) a druhou pomalou malo pouzivanou cestu, ktera potrebuje spoustu mista na zasobniku a vsechny registry. Gcc da alokaci mista zasobniku a ukladani registru na zacatek funkce pred obe cesty, ne jen do te pomale, jak by to bylo lepsi.
Quake se zrychlil pry 2x, kdyz se prepsaly nejdulezitejsi funkce v assembleru.
Rucne schedulovat instrukce neni problem --- pro Pentium a Pentium 2 jsou ta pravidla jednoducha. Pro Pentium 4 trochu slozitejsi (a ne tak ucinna), ale ne o moc.
Ja jsem zase psal smycku co prepocitava alfa kanaly pri generovani pismenek v Linksu.
Delilo se tam obrovske mnozstvi cisel (cele pole) 255. A protoze vstupni hodnota mohla byt max. 255*255=65025, tak se mi podarilo kod deleni vymyslet o takt rychleji, nez to dokaze GCC. GCC predpoklada, ze vstupni hodnota je az 65535, a tak generuje o takt pomalejsi kod, nez by mohlo.
Vzhledem k tomu, ze v jazyce C se neda nijak nadeklarovat short a rict, ze jeho maximalni hodnota bude 65025, nemuze GCC z principu generovat optimalni kod.
Detaily pouziti MMX a SSE se celkem dost lisi procesor od procesoru, pokud vas tahle problematika zajima, stahnete si ze stranek Intelu a AMD dokumenty popisujici optimalizaci pro jejich procesory - aspon AMD tam ma spoustu prikladu, jak efektivne pocitat napr. 3d transformace, porovnani jak funguji ruzne implementace memcpy - rep movsb pocinaje a mmx+prefetch konce atd.