[elektro] A szokásos C kezdő kérdések

[Vajk Fekete]

egy beagyazott rendszer egesz mas tema. Amugy a tema nagyon erdekes,
tulajdonkeppen reszben arrol beszelunk hogy az architektura tervezes,
modularizalas, optimalizalas mennyire elkulonitheto, es milyen sorrendben
kell legyenek.

egy beagyazott cuccnal siman az egesz architektura mulhat azon, hogy az
adott funkcio belefer-e 64 orajelbe vagy sem. ha igen, akkor lehet az
ISR-ben, ha nem akkor egesz mashova kell keruljon, vagy akar lehet hogy
akkor nem interrupt alapura kell tervezni.

Vajk

2013/1/31 Móczik Gábor <pm_levlista at progzmaster.hu>

> 2013.01.31. 10:50 keltezéssel, SZIGETI Szabolcs írta:
> > lesz az. Persze kijelentve mindezt mindenféle analízis és mérés nélkül.
> > Aztán amikor nagy nehezen sikerült rábeszélni egy profilingra, akkor
> > kiderült, hogy halálra optimalizálta a teljes futási idő 0,1%-ért felelős
> > kódrészt, ami így 25%-kal gyorsabb lett. vagyis nyert az egész futási
> időn
> > 0,025%-ot. És kerek szemekkel nézte, hogy volt egy függvény, amiben
> 50%-ot
> > ment a program. Ezt pár egyszerű fogással durván ötödére lehetett
> faragni.
>
> Ez jól hangzik egy PC-n, szerveren, ahol legfeljebb vársz 3 másodperccel
> többet egy eredményre, de egy real-time rendszerben, mondjuk egy
> mikrokontrolleres vezérlőrendszerben ez egyszerűen nem működik.
>
> Lehet hogy egy adott interrupt csak az idő 0.1%-ában fut, de akkor
> mondjuk adott igen szűk időkeret alatt valamit tenni kell. A CPU
> sebessége véges, és ha a lefordított kód nem fut le ennyi idő alatt,
> akkor valamit faragni kell.
>
> Nem ritka.
>
> > Szóval először működjön funkcionálisan jól, a kód legyen olvasható,
> > hordozható, karbantartható. Aztán mérünk és megnézzük, hogy tényleg lassú
> > vagy nagy-e és ha igen, akkor a mérés alapján megnézzük, hogy hol kell
> > faragni. Itt jöhet aztán a bitvadászat, de rendszerint nagyon kevés
> esetben
> > kell vadászni, primitív dolgokkal (pl. egymásba ágyazott ciklusok ki/meg
> > fordítása, jobb adatszerkezet, stb.) hatalmasakat lehet nyerni. De ehhez
> > mérni és elemezni kell.
>
> Ezzel mondjuk egyetértek. Nem kell mindent optimalizálni, csak azt ami
> nem felel meg, és azt is úgy, hogy minél kevésbé legyen speciális.
>
> -----------------------------------------
>           elektro[-flame|-etc]
>