Új hozzászólás Aktív témák

• #95 Pikari veterán freeapro #94

  Új Válasz 2024-04-01 16:18:30 #95

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Pikari

  veterán

  válasz freeapro #94 üzenetére

  Nem mondtam olyat, hogy nem értenél hozzá... A feltételezésed, ami alapján azt gondolod, hogy oop kód esetén épp ezek lennének kioptimizálva, viszont túl optimista. A te magas szintű oop kódod optimizálódik ki, meg ami jól fog még futni, azok az adatbázis szerű műveletek, ahol pointerekről vagy osztályok példaányairól példányaira ugrálsz, vagy egyszerűen dolgokat címezgetsz. De egy olyan library vagy forráskód már nem, ami mondjuk egy armra nem külön ráoptimizált dekóderrel csomagol ki valami nyersanyagot/resourceokat/pl képet/valamit kitömörít/ betömörít/különféle nem alignált transzformációkat/nem az archnak megfelelő szélességű deltákat vagy bitszélességeket használva, hát hát pont ezek a sebességkritikus részek rengeteg programban. És minő meglepetés, ezeken vérzik ki az arm architektúra általában, mivel az egy végletekig egyszerűsített load-store architektúra. Onnantól kezdve az ilyen kódot vagy vért hugyozva valahogy armra optimizálják, vagy nem lesz optimizálva (általában nem is szokták, hanem pont a leg naívabb c kódra ifdefelnek vissza, hogy egyáltalán működhessen), akkor viszont hiába várod a jó teljesítményt pusztán attól, hogy a deklarációidból fakadó kód overheadje nem roszabb rajta, mint x86-on.

Új hozzászólás Aktív témák