SG.hu

A memória árának megugrása talán ráirányítja a figyelmet a szoftverek optimalizálatlanságára

Az emelkedő memóriaár kikényszerítheti a szoftverfejlesztés régóta halogatott szemléletváltását, mert gyorsan tarthatatlanná válik az a gyakorlat hogy egyszerű feladatok is indokolatlanul hatalmas erőforrásokat igényelnek.

Az elmúlt években egyre többször került szóba a szoftverek túlburjánzása, mégis sokáig úgy tűnt, hogy ez legfeljebb nosztalgikus panaszkodás marad azok részéről, akik még emlékeznek a kilobájtokban mért programokra. Most azonban a helyzet változni látszik. A memória ára folyamatosan emelkedik, és ezzel együtt egyre kevesebb mentség marad arra, hogy az alkalmazások indokolatlanul sok erőforrást emésszenek fel. Ahogyan az 1970-es évek energiaválsága rákényszerítette az ipart a hatékonyság újragondolására, úgy a 2020-as évek memóriahiánya is hasonló fordulatot hozhat a szoftverfejlesztésben.

A múlt század hetvenes éveiben a nemzetközi konfliktusok miatt kialakult üzemanyaghiány a benzinkútaknál hosszú sorokat, feszültségeket és drasztikusan növekvő költségeket eredményezett. A válasz végül az lett, hogy a gyártók és a fogyasztók egyaránt kénytelenek voltak takarékosabban gondolkodni. A hatékonyabb motorok, az alacsonyabb fogyasztás és az energiafelhasználás optimalizálása ekkor nem divat volt, hanem kényszer. A párhuzam ma is adja magát, csak éppen az energia helyét a számítógépes memória vette át.

A RAM ára az utóbbi időszakban meredeken emelkedett, és semmi nem utal arra, hogy ez a tendencia gyorsan megfordulna. Míg korábban a fejlesztők sokszor legyintettek egy újabb keretrendszer vagy több megabájtos könyvtár hozzáadására, ma ez a hozzáállás egyre nehezebben tartható. Felmerül a kérdés, valóban szükség van-e ekkora memóriaigényre a legegyszerűbb feladatoknál is. Tényleg megabájtok kellenek ahhoz, hogy egy weboldal megjelenítse a Hello World modern megfelelőjét?

Jó példa erre a Windows Task Manager, azaz a feladatkezelő. Maga a futtatható állomány körülbelül 6 megabájtot foglal a lemezen, ám futás közben közel 70 megabájtnyi memóriát igényel, mielőtt egyáltalán megmutatná a felhasználónak, mennyi memóriát használ éppen a Chrome. Az eredeti Feladatkezelő mindössze 85 kilobájt volt, és funkcionalitásban nem maradt el nagyságrendekkel mai utódjától. Ez az összehasonlítás jól rávilágít arra, mennyire elszakadt a modern szoftverfejlesztés a takarékosság elvétől.

Azok, akik még emlékeznek arra az időszakra, amikor komplett operációs rendszerek és hasznos alkalmazások futottak floppy lemezekről, és a memória mérete kilobájtokban volt mérhető, régóta értetlenkedve figyelik a mai gyakorlatot. Sokáig azonban a technológiai fejlődés minden kritikát elnyomott. A memória egyre olcsóbbnak és bőségesebbnek tűnt, így a szoftverek növekedése természetes velejárónak számított. A túlzott erőforrásigény miatti panaszkodás inkább tűnt múltba révedő morgolódásnak, mint komolyan vehető problémának.

A mesterséges intelligencia robbanásszerű terjedése azonban új helyzetet teremtett. A világ minden táján adatközpontok épülnek, tele hatalmas számítási kapacitással és óriási memóriaigénnyel. Ez a verseny azonnali hatással volt az árakra, és a memória mára olyan erőforrássá vált, amelyből korántsem jut korlátlan mennyiség. Ebben a környezetben egyre kevésbé elfogadható, hogy egy alkalmazás gondolkodás nélkül lefoglaljon további megabájtokat pusztán kényelmi okokból.

A fejlesztőknek érdemes újra megvizsgálniuk, pontosan mire van valóban szükségük egy adott keretrendszerből, és mi az, ami csak megszokásból vagy lustaságból kerül be a projektbe. A hatékonyság nem csupán technikai kérdés, hanem szemléletmód is. Ehhez viszont az is kell, hogy a vezetők időt és teret adjanak az optimalizálásra. Ha egy csapat energiát fordít arra, hogy biztonságos és jól karbantartható eszközkészletet használjon, ugyanekkora figyelmet érdemel az is, hogy ezek az eszközök mennyire hatékonyak memóriahasználat szempontjából.

Gyakran elhangzik az a félkomoly megjegyzés, hogy a Holdra szálláshoz szükséges számítási teljesítmény eltörpül egy mai okostelefon képességei mellett. Ez igaz, de hajlamosak vagyunk elfelejteni, hogy nem is olyan régen még teljes értékű operációs rendszerek és alkalmazások működtek rendkívül szűkös erőforrások mellett. Nem technológiai csoda volt ez, hanem tudatos tervezés eredménye. A több évtizedes növekedés visszafordítása természetesen nem megy egyik napról a másikra. Ehhez alapvető gondolkodásbeli váltásra van szükség. Újra kell értelmezni a fejlesztői eszközláncokat, és olyan ösztönzőket kell kialakítani, amelyek jutalmazzák a tömör, hatékony megoldásokat. Nemcsak a lemezen elfoglalt hely számít, hanem az is, mennyi memóriát használ egy alkalmazás futás közben.

Ahogyan az 1970-es évek energiahiánya kikényszerítette a hatékonyabb működést, úgy a 2020-as évek memóriahiánya is elhozhatja azt a korszakot, amikor a szoftverek nem próbálnak meg minden egyes bájtot felesleges sallangokkal kitölteni. Lehet, hogy a megoldás nem újabb hardver vásárlása, hanem az, hogy végre kevesebb memóriát használunk.

Hozzászólások

A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!
Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
  • t_robert #9
    Amúgy a 80-as években rendesztek programozó versenyeket fiatal zsenik részvételével. Volr 1 KB, 4 KB és talán 16 KB-os kategória. A cél az volt, hogy olyan programot kellett készíteni ami bele fért ezen méretkorlátokban és minnél bonyolultabb és összetettebb dolgot valósított meg. jellemzáen valamit rajzolt a képernyőre. vagy valami mozgó grafikát csinált monochrome monitorra. aztán a legjobb gyöngyszemeket idönkén közzé is tették számítástechnikai újságok mellékletében. Aztán ki is lehett probálni azokat saját gépen ez még PC dos korszak volt. Aztán leesett állal bambult az ember, hogy sikerült ennyi mindent megcsinálni mondjuk egy 4KB-os programhóddal????? Na azok a srácok tudtak hatékonyan programozni. :)
  • t_robert #8
    ismerjük a mondást... nem létezik szar program csak illuzió... hanem nem elég a hardver hozzá..... tessék új hardvert venni évente. :) Amúgy én Noé mellett kezdtem az informatikát. Az első programjaimat egy ESZR R20-as számítógépen irtam assemblerben. Volt a gép memóriája 64 KB. Ami használt úgy 20 KB rendszermemóriát(supervisor) és maradék 44 KB- memóriában lehetett akár három programot egyidőben futattni prioritásos multitaskban. Vagyis úgy 14-15 KB memóriába kellett beleférni a leforditott gépi kódú programnak. Csinált is a gép úgy 20 ezer utasitást másodpercente. :) 6,25 MB-os lemezek voltak a géphez ős úgy nagyjából 730 méter hosszú mágnes szalagokat használó egységek. amire ráfért úgy 25 MB körüli adatmennyiség. :) és arra is lehetett programot írni. persze nem 300 GB-os COD programok futottak rajta. :) Én még láttam olyan PC programot, ami letörölte a képernyöt, majd kiírta, hogy "Hello word!" volt vagy 4 gépi kodú utasitás és vagy 25 bájt leforditva... :) Na ma próbálja meg valaki ugyan ezt megcsinálni a mai fejlesztő eszközökkel úgy pár 100 KB-os kód alatt... :)
  • t_robert #7
    A fő gond szerintem az OOP szoftver fejlesztés megjelenése. az csak úgy fossa a felesleges kódot. Tény hogy gyorsabb vele a fejlesztés csak hát simán lehet az elkészül kód akár 2/3-ad része is full felesleges. Például valaki feltesz a programban egy szabványos gombot. És bár csak 3 tulajdonságot ír át a gombon és csak egyetlen metódust használ mondjuk az on clikk eseményt(megnyomták a gombot) közben lesz a gombnak 18 féle tulajdonsága és 16 féle metodus(vagyis, hogy mit tud végrehajtani a gomb) Persze lehetne saját gomb osztályt létre hozni az eredeti ős osztály alapján kihagyva belőle olyasmit, amit nem fog használni az ember a programban. de ez már baszakodás, ami idő és energia. Így a legtöbben használják az alapgombot. Aminek felelesges adatai és kódjai is belekerülnek az alkalmazásba. És így van az OOP-ben készólt programban minden objeltummal osztállyal stb. Szerintem simán van olyan kódd, aminek a akár a 90%-is gyakorlatilag szemét és feleleges a konkrét program müködéséhez.
  • kvp #6
    Mar az nagy elorelepes volt, amikor a 32/64/128 bites lebegopontos szamok helyett elkezdtek 8/16/24 bites fixpontos szamokat hasznalni a neuralis modellek. Ugyanis nem csak a memoriaigeny csokkent le, hanem a sebesseg is nott. Igy jottek az altalanos gpu-k helyett a gyorsabb, de csak fixpontot (es persze integer-t) ismero vektoros MI gyoritok. Ha nem kell a teljes trigonometriai fuggvenysor es nem kellenek lebegopontos szamok, akkor az MI alapmuveleteket (szorzatok osszege vektorokon) sokkal kevesebb tranzisztorral sokkal gyorsabban el lehet vegezni. Es mellekhataskent ram is valamivel kevesebb kell hozza, azaz igy tobbet lehet ugyanannyi ram-mal elvegezni. Az MI-k eseten a kulonbozo meretu nyelvi modellekhez szukseges muveletek szoftveres es hardveres optimalizaciojat nagyon komolyan veszik.

    Igazabol a kerdes az, hogy meddig terul meg egyre tobb szamitasi kapacitast dobni egy adott problemara. A valasz persze az, hogy soha nem terult meg idaig, de hat ezert is hivjak ezt az egeszet MI buboreknak. (valodi MI-khez kevesebb szamitasi kapacitas, tobb logika kellene, de az egy az LLM-ektol eltero dinamikus feedback-es architektura lenne)

    ps: Egyebkent az oriasi programmeretek konnyen kezelhetoek lennenek ha a statikus es a dinamikus linkeles helyett dinamikus just in time forditas lenne, tehat az adott program osszeallitasakor mindig csak azt linkelnek bele ami tenyleg kell is az adott feladathoz es a library-kben levo dinamikus kodreszleteket betolteskor is szelektiven kezelne a rendszer. Ez persze nagymertekben elbonyolitana a logisztikat az os szintjen es nem ved az olyan "emberi" hulyesegek ellen, amikor valaki az x+y matematikai muvelethez egy MI hivast rak be, annak minden hatter infrastrukturajaval egyutt. Meg persze mennyivel egyszerubb egy feladatnal minden igenyt jocskan felulbecsulni mint dinamikusan kezelni a memoriat vagy a hattertarat es folyamatosan ellenorizgetni, hogy van-e meg belole.
  • Kryon #5
    Tényleg jól kitoltak magukkal, most kénytelenek jóval drágábban eladni a cuccot az adatközpontoknak...
  • Armagedown #4
    Nem valószínű, hogy hirtelen majd megfordul a több évtizedes trend és elkezdenek majd optimalizálni a kóóderek, pedig jó volna.
  • igazamvanvagyig #3
    kitoltak magukkal vettem volna egy gepet minimum 600 ert de igy nem ,elvbol
    a mostani is egy csucsmodell 2 eves meg az is tokeletes,nekem igy is jo sot jobb is de sok ember nem fog venni ez miatt
  • kjhun #2
    Egy XP-s gépen, kb. 4500KB memóriát fogyaszt, a mindössze 137KB-os méretű "taskmgr.exe" azaz a Feladatkezelő, hogy legyen mihez viszonyítani. Egyes spéci tömörítőprogramok is csak MB-okban mérhető memóriát fogyasztanak el, bár az igaz, hogy a klasszikus RAR5/7 és 7Z (LZMA-algoritmussal), nagy szótárakkal, sok-sok GB-ot is képesek elfogyasztani. Az optimalizálatlanság terén, kétségkívül a mai web-böngészők ülnek kábé a trón tetején, bár a kövérre hízlalt Windows és egyes gyártók ismertebb programjai sem kivételek ezek alól. A CPU/GPU-igény optimalizálása sem elvetendő igény volna, itt a játékok is erősen kiveszik, a részüket ebből. Ha, 20 éve azt mondod a kocka-haverodnak, hogy 600W-os VGA kell a gépbe (netán kettő is), meg 1000-1500W-os táp, kábé ez lett volna a válasz: Nade Margit! Nooormális???
  • kjozsef056 #1
    Megvetetni az emberekkel a többet jobbat mindenből mindig is kifizetődőbb volt és lesz mintsem költeni arra hogy a produkciód kisebb erőforrást igényeljen. Ezen nem tudom miért lepödik meg bárki is...ezer kegyetlen régóta így van.