Odpovìï : Re: Sou?et v C - neni pro PICjiny kompilator?

[Jakub Slajs]

> To neni tak uplne pravda. Vlastne to neni vubec pravda. Jednak neni
> zadny principialni duvod, proc by melo C generovat rychlejsi kod nez
> ostatni prekladace, naopak "diky" jeho omezene a nejasne syntaxi je
> nekdy problem rozpoznat jak to vlastne programator minil a prislusne
> to optimalizovat.

Neberte to prosim jako flame ale nemate pravdu.
Nechapu co chcete rici omezenou syntaxi ale sila jazyka C je mimo jine
i v tom ze Vam umozni napsat takove "parasarny" ktere Vam rada jinych
jazyku proste nepovoli ;-)
Kolik jinych jazyku Vam napriklad umozni "napovedet" kompilatoru aby
dal nekterou promenou do registru a ne na zasobnik. Kde jinde muzete
delat takove psi kusy s pointerovou aritmetikou. Proste spoustu
optimalizaci si muzete delat rucne a nespolehat se jen na kompilator.

> Ale hlavne rychlost pri programovani v ASM je dana tim, ze clovek voli
> jiz samotny algoritmus (napriklad prohledavani pole) uz primo
> optimalizovany pro ASM, coz zatim ani nejlepsi prekladace vyssich
> jazyku nedokazou.

Volba algoritmu je vzdy dulezita a to bez ohledu na to jestli pisu
v ASM nebo C. Viz napr. ono prohledavani pole (prvni vyskyt daneho
prvku). Vetsina lidi to napise nasledovne (nebo podobne, dulezity je
algoritmus nikoli jazyk!):

int i = 0;
while (i<pole.length) {
    if (pole[i] == hledany_prvek) break;
    i++;
}
if (i == pole.length) => prvek nenalezen
else => i - pozice prvku

Problem je v tom ze v tele cyklu while se provadeji dva testy
kontroluje se rozsah pole (i<pole.length) a soucasne rovnost prvku.

Lepe to lze napsat tak, ze pouzijeme pole o jeden prvek delsi
a hledany prvek umistime na konec. Pak nemusime kontrolovat rozsah
indexovani protoze prvek vzdy najdeme a tim se cyklus ukonci.

while (pole[i] != hledany_prvek) i++;

Pote pouze zkontrolujeme jestli jsme nasli prave ten posledni
prvek protoze pak jsme vlastne nenasli nic ;-)

I kdyz ten prvni priklad napisete superoptimalne v asm a druhy
prelozite napr. v C tak ten druhy bude vzdy rychlejsi (za
predpokladu ze to pole nebude mit extreme malo prvku) ;-))

S pozdravem,

Jakub Slajs