Ejjj, ez hosszu lesz.

> >> Az 0-val osszehasonlitas gyorsabb mindenfajta
> >> procin, es a forditonak is konnyebb dolga van vele.
> >> Tehat: kevesebb hiba, es az utasitas-atlapolas is jobb > lesz.
> >
> > Ezekben te egeszen biztos vagy??
>
> Igen, a 0 ellenorzese a processzorok 99.9 szazalekan gyorsabb.

Nem ez volt a lenyeg. Az addig ok, hogy 0-val osszehasonlitani gyorsabb, de
ha mast is figyelembe veszel, pl. hogy az osszehasonlitason kivul mit kellene
meg csinalni, egyaltalan nem biztos, hogy benne lesz ez a teszt, effektive nem
nyertel semmit. Persze nem is vesztettel, ha megszokasbol igy irod a
ciklusokat, de hulyeseg atirni a meglevo kodot, meg atszokni is ertelmetlen..

> Az elenyeszo szamu maradekban ugyanolyan, tehat lassabb sohasem lesz.
> Nezd meg mit fordit a fordito, tanulmanyozd a proci utasitaskeszletet.
> Termeszetesen csak nagyon egyszeru ciklusok eseten jelentos a kulonbseg.
> Pl egy sima memoria-masolasnal tobb 10% is lehet, egyebkent joval kisebb.

Persze, ezert szokas ugye a memoria-masolasokat kiteriteni, meg esetleg
SIMD, meg hasonlok.

> (Egyebkent ez baromi alap dolog, minden kezdo C kurzusban emlitik...)
> Ja es sok procinak van specialis ciklusszervezo assembly utasitasa, az
> osszes amit ismerek, MIND lefele szamol.

Igen, es lassabb is, mintha a spec utasitas nelkul irtad volna meg a ciklust :)
Erre mondjuk nem eskudnek meg, az viszont tuti, hogy 486-pentium kornyeken
meg igy volt. Az egyaltalan nem meglepo, hogy lefele szamol. Termeszetesen
egyszerubb flaget ellenorizni, mint egy ertekkel osszehasonlitani, es utana
flagcsekk. Es mielott meg azzal jonnel, hogy deinkonzisztens vagyok: nem,
semmi bajom a 0-val valo osszehasonlitassal. Tenyleg gyorsabb, egy reg nulla
allapotat ellenorizni, mint ket reget osszehasonlitani.

Amire en rakerdeztem, hogy tenyleg jobb kod lesz-e ha te atirod a ciklusod.
Es erre meg mindig azt mondom, hogy ilyen trivialis valtoztatasnak semmi
ertelme, mert vagy igen, vagy nem.

> > A forditonak konnyebb dolga van. Szegeny, nehogy mar elfaradjon. Inakabb ke
zz
> el
> >  mikrooptimalizalok assembly-ben.

Ez itt csepp ironia, csak hogy minden egyertelmu legyen...

> > A 0-val valo osszehasonlitas: hanyszor nezted meg, hogy egy fordito milyen 
ko
> do
> > t general a C forrasodbol? Meg fogsz lepodni. Akarmennyire probalkozol,_nem
_
>  t
> > udod megmondani, hogy milyen kodot fog generalni. Ha epp ugy jon ki a lepes
,
> me
> > g veletlenul sem lesz benne az a teszt, amit te C-ben irtal.
>
> Dehogynem, siman megmondhato. Nem olyan misztikus egy fordito mukodese.
> Ebbol is az latszik hogy te nem szoktad megnezni a forditas eredmenyet :)

Misztikus? Inkabb determisztikus. Ok, szar poen :)
Szoval: perszehogy megmondhato. Ha epp tudod, hogy (vigyazz, most cache meg
pipeline-nal jovok) melyik proci pontosan hogy mux. Ezt az atlag
halando nem tudja
(ha te tudod, akkor ugyes vagy, gratulalok), es foleg nem fog minden
procira optimalis
kodot irni (plane cben).

> > Szoval roviden: felesleges mikrooptimalizalni C-ben.
>
> Nehany sorral feljebb meg optimalizalni akartal, kicsit kusza lett ez
> a level. Egyebkent mit ertesz mikrooptimalizalas alatt?

Csak hogy nagyon tiszta legyen: feljebb azt irtam, hogy meghagyom az
optimalizaciot
a c forditonak, nem fogom az egesz programot asmban megirni.
Mikrooptimalizalas az,
amirol eppen szo van: picit modositasz egy ciklust (nem feltetlenul a
ciklusszervezest),
hogy nehany proci-ciklust megsporolj. Ilyet kell is, de nem allandoan, mertmire
elkeszul a prg, mar husszor atirtad azt a reszt, es nem cben, mert nem
sok ertelme van.

> > gy semmikeppen nem tudod megoldani, mert konnyen elofordulhat, hogy a te ke
zzel
> >  optimalizalt valtozatod lassabb lesz...
>
> Ez termeszetesen nem fordulhat elo. Kezzel, nemi gondolkodassal MINDEN
> FORDITOT meg lehet verni. Legfeljebb olyan sokat kell tokolni rajta,

Jah, csak nem mindegy, hogy ki fog hozza.

> hogy egyszeruen nem erdemes, mert sohasem terul meg.

Mintha mar hallottam volna valahol. Esetleg mondtam is ilyet? hmm..

> Kozismert tevedes, hogy a forditok hu de jol optimalizalnak.
> Ezt csak megerositi, hogy kezdokent belenezve a forditott kodba, az
> zavarosnak, erthetetlennek tunik, konnyen azt hiheti az ember, hogy
> szandekosan ilyen, mert ez jobb valamiert. Nem igy van.
> A kod altalaban zavaros, de ez sima benasag, az optimalistol is messze van.
> Kezzel jo esellyel lehet irni nem csak gyorsabb, de sokkal jobban ertheto
> kodot is. Ne gyere azzal, hogy a cache, meg a pipeline, meg a sok
> regiszter. Minden szempont kezelheto kezzel, semmi problemat nem okoz,
> rutin kerdese.
> A gyartok mindig adjak a procikhoz/forditokhoz a kis C libraryt, amiben
> KEZZEL OPTIMALIZALVA meg vannak csinalva a fontosabb aritmetikai

Ehhmehmm. Nem ide tartozik, de esetleg hallottal mar olyanrol, hogy ha beragad
a shift, az elegge zavaro? Nem veletlenul szoktak azt mondani, hogy ez
kiabalasnak szamit. Mindegy. Mellesleg most meg veletlenul sem cafoltal
meg. Ramutatnal, hogy hol irtam azt, hogy felesleges assembly-t hasznalni?
Mert szerintem nem irtam ilyet, csak azt, hogy ez legyen az utolso modszer az
optimalizalasra, es meg kell gondolni, hogy tenyleg belenyulsz-e, mert hiszed
vagy sem, nem minden jottment fogja leoptimalizalni. Rutin kerdese. Pontosan.
Ez az, ami nem mindenkinek van meg. Ha epp szepen kiismered magad, akkor orulj.

Kicsit osszefoglalva. Ird meg a programot amilyen egyszeruen tudod, ertelmes
algoritmusokat hasznalva. Ha gyorsitani akarod, nezd meg, hogy melyik
algoritmuson
lehetne javitani, esetleg lecserelni masikra, vagy optimalizalt
valtozatot hasznalni.
Meg mindig nem tetszik? A problemas reszeket assemblyben optimalizalni. De jo
tisztaban lenni vele, hogy ez utobbi sok idot vesz igenybe, es nem
feltelenul lesz
jobb, mint a fordito altal generalt. Foleg nem tobb procin...
Az, hogy cben mikrooptimalizalni, eleg kerdeses eredmenyt fog hozni...

Szabi