( bucko | 2016. 08. 21., v – 13:23 )

Valami bajod van a mikrokontrollerrel? (Pillcsike! Mindjárt elmagyarázom.)
Mivel én mondom meg a regiszter hosszát, hullára nem érdekel.
Ez marhaság, de semmiség ehhez képest:
Mindegy, mert kulturált nyelvekben tetszőleges bitszámú érték ábrázolható...
Ezt a kettőt így együtt véve - bár az utóbbi ugyan igaz - alapja az érthetetlenül lassú programok keletkezésének.

A locsemege féle mikrokontroller példa azért gyengécske, mert az tényleg alapszint.
Magas szinten meg általában senkit sem kell, hogy érdekeljen különösebben az alatta levő architektúra.
Sajnos ez abszolút nem így van. A mikrokontroller a bájt szervezésével borzasztóan egyszerű és áttekinthető. Magas szinten rögtön van cache, a diszknél fizikai blokkméret, a drivernél meg buffer méret. Persze a regiszter mérete is lényeges, amit ugye C esetén int-ként jelölnek, hogy tudjad mi az optimális adatméret. Ez csak az int, míg a lebegőpontos egységekben a különböző adathosszakra általában külön végrehajtóegységet építenek. A 8x256bit altivec mellett is használhatsz tetszőleges adatméretet, csak akkor lemodhatsz az altivec kihasználásáról, ami lényegesen lassab végrehajtást eredményez.
Tehát az állításodban van némi igazság, de az achitektúra elrejtése általánosságban sikertelen. Ezért a hányaveti adatábrázolást a magasszintű rendszer nem tudja ellensúlyozni.
Konkrét példák:
- Nem optimálisan foglalt tömb rendszeres cache invalidálást eredményez lecsökkentve a memória sávszélességét.
- Karakteres feldolgozás esetén a 32->64 bites program 5% lassulást okoz.
- Rossz (egyébként triviálisnak és jónak tűnő) adatábrázolás kb. harmadára lassítja a feldolgozást. Ilyet már optimalizáltam néhányszor "alacsony szinten". Az optimalizálás után visszarakhatod "magas szintre", az előny megmarad.
Ilyen apróságokat általában nem old meg a "magas szint".