Weblabor

Azt inkább nem commentálom, hogy ez a hozzászólás egy "Arguments against OOP" google groups topicról való :) De őszintén csodálom a kitartásodat :)

2 dolgot említ a hozzászólás írója: több core, és memory access. A kettőnek kb semmi köze egymáshoz, teljesen más problémát hoznak be.

Memory access: Ez ugye nem újdonság. Talán ismerősen hangzik, hogy "RAM is the new disk", vagy ennek egy másik verziója. A lényeg, hogy a mai processzorok sokkal gyorsabbak, mint amilyen gyorsan elérhető a memória, és egy rosszul szervezett adatszerkezettel kb lábon lehet lőni a legszebb kódot, és a legjobban kitalált algoritmust is. Konkrétan a jelenlegi processzorok kb 200x (!!!) annyi idő alatt érik el a memóriában lévő adatot, mint ami kéznél van (regiszterek, belső bufferek, L1 cache). Ezt nyilván az Intelnél is tudják :), ezért a mérnökök mindenféle spekulatív okosságokkal spékelték meg a procikat. Ami idevág, az a prefetching. Ez azt jelenti, hogy a processzor azt feltételezi, hogy okos adatszerkezetekkel dolgozunk (gyakorlatilag tömb), ezért arra számítva, hogy szépen végigmegyünk rajta (és miért ne tennénk, a programjaink valójában adatszerkezetek köré épült ciklusok és elágazások), betöltögeti nekünk a szomszédos memória területet a cache-be majd jó lesz az valamire alapon. És ha a programozó ezzel tisztában van, akkor jó is lesz :) És itt jön képbe az, amiért az OOP-t szokták bántani, nevezetesen a dinamikusan röptében létrehozogatott objektumok össze-vissza helyezked(het)nek el a memóriában, ezért az ilyen objektumokkal dolgozó kód igen nagy arányú cache miss-re van ítélve, ami azt fogja jelenteni, hogy a proci tökjót malmozik, miközben mi úgy látjuk, hogy vörösen izzik a gép, mert egész kelet-kína a mi kódunkat hajtja. Ezzel nagyon nem lehet vitatkozni, ez tény. De miért kéne ezt mindenképpen így csinálni? OOP kódban bűn a tömb, meg a szekvenciális adatszerkezetek? Én nem így látom, és szerencsére sokan nem így látják, ezért készülnek igen gyors kódok OOP alapokon. Sőt, pl a világ pénzügyi rendszerének igen tekintélyes része nemhogy OOP-ban, de Javaban készül. És gyors. Nagyon gyors :) Pár százalékkal lassabb, mintha C-ben írnák, de bőven elég gyors ahhoz, hogy ésszerű kompromisszum legyen a sebesség vs karbantarthatóság örök kérdésben. Nyilván nem az EJB-s horrorokra kell itt gondolni természetesen. Ráadásul OOP-vel egy belül bonyolultabb, szétoptimalizált kódot is el tudsz fedni szép interface-szel, procedurális kódban ez azért macerásabb. És ott is lehet csúfságokat elkövetni adatszerkezet téren, elég pl egy linked-list és unbounded queue házasságra gondolni. Lényegében azt kell látni, hogy az OOP kód is ugyanarra fordul, mint a procedurális, a processzor csak egyfélét ismer.

Ami a sok core-t illeti, ez nyilván többszálú programoknál kihívás. Szinkronizálni a szálakat, lockok, hogyan és mennyire skálázhatók az egyes algoritmusok stb. Az se véletlen, hogy bizonyos alkalmazási területeken inkább egyszálú programokat írnak, hogy ne kelljen a fentiekből adódó lassulással számolni. De ennek aztán tényleg nem sok köze van ahhoz, hogy OOP, vagy sem.