AVR32

[Andras Tantos]

Hali!

> > Fordításkor még nem tudhatod, hogy min fog futni.
>
> Bizony! Arról nem is szólva, hogy sokan úgy gondolják, hogy optimalizálás 
> =
> legyen minél gyorsabb a program. Pedig sok minden másra is lehet
> optimalizálni.
>
> Sot, van, hogy nem is a program közvetlen jellemzojére akarunk
> optimalizálni.. Hanem pl. fejlesztési idore. És akkor nem mindegy, hogy
> mennyi ideig kell üldözni egy eltévedt pointert, vagy egy memory leaket. 
> És
> ebben a nyelv és a környezet nagyon nagy segítségre tud lenni.
>
> Szabolcs
>

Nem birom tovabbb, most mar bele kell szoljak kicsit.

A futasi ideju (pontosabban a dinamikus analizis apaljan torteno) 
optimalizalas tenyleg jo dolog, de persze nem csak Java-ban lehet 
megcsinalni. A lenyeg az, hogy amig nem tudod, hogy a programot hogyan 
hasznaljak, sok atalkitasrol nehez eldonteni, hogy valoban megeri-e, vagy 
eppen bajt csinal. Egy pelda: egy fuggveny inline megvalositasa altalaban 
gyorsabb kodot eredmenyez, mert pl. nem toltunk extra idot a hivassal (ez 
csak az egyik, es meg csak nem is a legfontosabb elony, de ez most 
mellekes). Igenam, de ez sajnos a kod meretenek a novekedesevel jar, ami 
lecsokkenti a cache talalati valoszinuseget, tehat lehet, hogy eredoben 
lassabb lesz a kod. Megeri? A fene tudja, ki kene probalni. No, ez az amit 
nem lehet forditasi idoben megcsinalni, csak futasi idoben. Egy masik ilyen 
dolgog a 'loop-unrolling'-nak nevezett optimalizalas. Hogy merei-e nagyon 
fugg attol, hogy a ciklus hanyszor fut le, ezt pedig sokszor lehetetlen 
eldonteni a kod statikus analizise alapjan. Raadasul ugye nem lehet minden 
fuggvenyt inline-a tenni, nem lehet minden hurkot teljeseni szetteriteni, 
mert a program elfogadhatatlanul nagyra none. Azaz ha a fordito ugy dont, 
hogy egy fuggvenyt inline-ba rak, akkor ez azt is jelenti, hogy egy masikat 
nem tehet azza. Melyik tehat a fontosabb, A, vagy B? Nos, nyilvan a 
gyakrabban hasznalt, de melyik is az?

No szoval, ezert szeretnek a forditok tudni arrol, hogy a programot hogyan 
hasznaljak. Ha JIT (just-in-time compiler) alapu rendszerrel van dolgunk, 
mint a Java vagy a .NET, akkor ez aranylag egyszeru, hiszen a fordito egy 
gepen, egy idoben fut az alkalmazassal. Tradicionalis C/C++ kornyezetben ez 
nehezebb, itt a 'profile-guided' optimalizalast szoktak hasznalni (pl. a 
legujabb VC++ tudja).

Van azonban egy nagy problema: leven a JIT egyszerre fut az alkalmazassal, 
nagyon oda kell figyelni arra, hogy az optimalizalasok gyorsan elvegezhetok 
legyenek, hiszen a forditasi ido hozza adodik (valamilyen aranyban) az 
alkalmazas futasi idejehez. Igy aztan az igazan izmos optimalizalasokat nem 
szoktak a JIT-ek megcsinalni, es sajnos ezek kozott vannak azok is, amik 
igazan sokat profitalnanak a futasi adatok ismeretebol.

Van itt aztan meg egy-ket nagy gond, bar ezek mar nem kapcsolodnak szorosan 
az elozohoz. Az egyik, hogy a runtime alapu rendszereknel a runtime (es a 
JIT) jelenlete szukseges a program futasahoz. Ezt elso alkalommal be kell 
tolteni a memoriaba, ami bizony sokaig eltarthat. Ezert van, hogy a Java (es 
.NET btw) alkalmazasok olyan lassan indulnak el. A futas soran pedig a 
runtime vegig a memoriaban kell legyen, ami megnoveli a memoria-igenyt, 
lecsokkenti a cache talalti pontossagat, es konnyen vezethet komolyabb 
'paging'-hez. Raadasul ha hatekony akar lenni a rendszer, akkor egyszerre a 
memoriban kell tarolja a program eredeti byte-kodjat, es a leforditott 
reszeket is (hacsak nem csinal valami nagyon ugyeset, de erosen kerdeses, 
hogy megerne-e). Ez megint a memoria-igeny novekedesehez vezet. Ott van 
aztan a szemet-gyujtogetes, ami megitcsak noveli a memoria-igenyt, hiszen 
sok nem elo objektum is a memoriaban van meg. A nem-determinisztikus 
felszabaditas ugy altalaban is nagyon meg tudja az eletet neheziteni, de van 
vele meg egy nagy gond. Nevezetesen, hogy ilyen rendszerben nem lehet a kod 
egy darabjat dinamikusan ki-be totogetni a memoriabol, ugy, ahogy DLL-eket 
lehetett regen. Meghozza azert nem, mert a program nem tudja garantalni, 
hogy az osszes objektum, ami belehiv ebbe a koddarabba fel van szabaditva, 
pontosan a szemet-gyujtogetes es az ebbol kovetkezo nem-determinisztikus 
felszabaditas miatt. Meg a futtato kornyezet is csak nagyon nagy nehezsegek 
(ertsd ido/memoria) aran tudna ezt nyivantartani. Ezert aztan, legalabbis 
.NET alatt nem is lehet kod-reszleteket kivenni a memoriabol, ha azok 
egyszer oda bekerultek (azaz olyan van, hogy Assembly.Load, de olyan nincs, 
hogy Assembly.Unload). Gondolom a Java is ilyen, bar azzal nincs konkret 
tapasztalatom. Ez aztan ismetelten a memoria-igeny novekedesevel jar, 
kulonosen nagy, osszetett alkalmazasoknal.

Mindez oda vezet, hogy ezeknek a rendszereknek nagyon komoly skalazasi 
problemaik vannak, roviden komolyabb vasat igenyelnek - elsosorban tobb, 
gyorsabb memoriat. Ettol persze se a Sun, se az Intel, se az AMD nincs 
kulonosebben ketsegbe esve (tanulsag, ha egy HW gyarto nyom egy SW 
technologiat, az ember legyen ovatos :-)).

No, azt hiszem mara eleget irogattam, be is fejezem. Ja, mindenkinek 
koszonom a NYAK-gyarto tippeket.

Udv,
Tantos Andras