tifyty

pure Java, what else ?

Spóroljunk a bájtokon

Anno a régi szép időkben papíron írtuk az assembly kódot. Volt egy laminált lapom, aminek a két oldalán ott voltak az opkódok hexában, és kézzel kellett kikeresni minden egyes utasításhoz a kódot hogy utána a hexa konzolon be lehessen vinni a gépbe. A relatív ugró utasítások offszetjét is kézzel kellett leszámolni. Harmadévben az egyetemen írtam is egy oktatófüzetet Z80 programozási gyakorlatok címmel, assembly mintapéldákkal, és magyarázatokkal. A füzetet az egyetemi nyomda sokszorosította. PDF, eMail? Ez a 80-as évek végén volt. A szöveg szerkesztéséhez a Tasword programot használtam. Emlékszik rá valaki?

Akkoriban azon versenyeztünk, hogy ki tud rövidebb programot írni egy adott problémára. Sok trükk volt arra, hogy hogyan lehet egy-egy bájtot megspórolni a programban. Olyan programot is írtunk, amelyik az ugró utasítás offset bájtját máskor végrehajtandó utasításként használta, attól függően, hogy éppen merre haladt a program futása. A decimális BCD korrekciós utasítást pedig egészen abszurd módon használtuk, hogy rövid, 16 bites osztó programot tudjunk írni.

Mostanában, mi programozók nem azzal vagyunk elfoglalva, hogy hogyan lehet bájtokat megspórolni, és ez jól van így. Én örülök ennek. Inkább sokkal magasabb szintű problémákra fókuszálunk, amelyeknek több értelme van. Az alacsony szintű problémákat megoldják a fordítók, betöltő programok. Mostanában van elég memóriánk, és olcsó. A Mac gépemben most 8GB memória van, ami 175ezerszer több, mint amennyi memóriája a ZX Spektrumnak volt. Ha ennyi ZX Spektrumot leraknánk egymás mellé az útra, akkor 61km hosszú lenne. A fordítók és az optimalizálók is tudják ezt, és nem azzal foglalkoznak, hogy a program legyen minél rövidebb futtatható formában. És ez jó. Általában.

Néhány nappal ezelőtt egy fórumon diszkusszióba keveredtünk azzal a tiszta kód gyakorlattal kapcsolatban, hogy egy metódus minden argumentuma legyen Java-ban final. Azt gondolom, hogy ez jó gyakorlat minden egyes argumentum elé odaírni a final kulcsszót, és tulajdonképpen a nyelv hiányossága, vagy tervezési hiba, hogy az argumentumok nem final változók alaphelyzetben. Ezt le is írtam, és erre válaszként azt kaptam, hogy ebben az esetben még egy lokális változóra van szükség, amibe átmásoljuk az argumentum értékét, és amit utána lehet módosítani, és ez memória pazarlás. Igen is és nem is. A JIT fordító a HotSpot JVM-ben majd jól kioptimalizálja. “Túl késő!” jött a válasz. Amikor a JIT optimalizál, akkor a byte kód már be lett töltve a néha bizony szűkös telefon memóriába. És a javac nem nagyon optimalizál, hiszen, mint ez már annyiszor említve lett: a túl korai optimalizálás minden házasság megrontója.

Hát már megint itt vagyunk? Takarékoskodunk a bájtokkal megint? Sajnos igen. A fordítók, és a többi hasonló szoftver eszközök a fő használati irányokra lettek kitalálva. Vannak ugyan olyan eszközök, mint a yguard, de nem biztos, hogy megfelelők az adott célra.

De ahogyan elmúlt a z80 bájt takarékos korszaka, el fog múlni ez is. Hamarosan már minden telefonban lesz annyi memória, hogy ne kelljen ilyen alacsony szintű problémákkal foglalkozni, és a programozók foglalkozhatnak a fontos dolgokkal. Csak éppen akkor majd jönnek a kevés memóriával rendelkező porszívók, villanykapcsolók, zuhanyrózsák és így tovább. Lehet, hogy egyszer, ha lelassul a fejlődés, akkor végleg eltűnik a memória mizéria. Talán. De akkor lesz más. Mondjuk sávszélesség. Majd le akarunk tölteni a személyes használatú űrhajónkra (lesz mindenkinek saját, mint most mobil) egy új szoftvert, és az űrhajó éppen két fényóra távolságra van, valahol a Jupiter környékén. Hand shaking, hibajavító algoritmusok, késleltetés… bájtok megint. Aztán ezt is megoldjuk, és akkor majd jönnek hasonló problémák a hiper szpészben, amit ma még kitalálni sem tudunk.

Mi a tanulság? Mindegy, hogy hogyan fejlődik a technológia, a trükkök időről időre visszatérnek. Talán kicsit más formában, de az alapprobléma megmarad: nem szabad az erőforrásokat pazarolni. És ez nem csak a programozásra igaz. Védd a fákat, egyél hódot! (angolul ez egy kicsit pikánsabban hangzik.)

12 responses to “Spóroljunk a bájtokon

  1. zmb január 30, 2013 10:00 du.

    Az ilyen jellegu “optimalizalaskor” azon szoktam tunodni, hogy hany byteot sporolunk meg? 10-et? 12-ot? Gyorsan megneztem 1.7.11-el forditva a ket esetet. Ha kozvetlenul hasznalom a fuggveny parameterben atadott int valtozot novelem, akkor az kemeny 6 byteal kissebb, mintha elobb egy lokalis valtozoba tolnam. Nem vagyok benne biztos, hogy runtime kornyezetben is olyan egetvero kulonbseg lenne. Megeri ilyen “trukkoket” alkalmazni, hogy megsporoljunk par bytetot?

    • v január 30, 2013 10:03 du.

      Előfordul, bár magam mostanában nem fejlesztek mobilra, de amikor már mindent kioptimalizáltál és még mindig hiányzik 6 bájt, hogy beleférj a készülékprofil max memóriába akkor ez is számít.

  2. tamasrev január 30, 2013 10:53 du.

    Hátő…
    Szerintem karbantartható kódot kell írni – aztán _ha_ kell, akkor spórolunk/optimalizálunk. Minden más, jól tudjuk, premature optimization.

  3. b0c1 (@b0c1) január 30, 2013 11:48 du.

    Hat a fent emlitett konkret problemara nalunk be van allitva az eclipse hogy menteskor minden parameter valtozot tegyen finalla (ami kodban modositva lett , nos azt nem piszkalja, halleluya eclipse save actions, amugy ugyan itt source code formazast is csinaltatunk amirol is volt java levlistan egy kisebb vita :)).

    Ezen felul: Mobil es mobil kozott van kulonbseg, manapsag a boltokban okosteleofnok mennek es nem j2me-vel kell sz*pni (enis “jaccotam” vele, nem jott at), ott a memoria minimum 512M (az en telomban konkretan 2G) szoval azert annyira itt sem igaz hogy az az 6 bajt fog kellni.

    Ettol fuggetlenul en is inkabb annak orulnek ha vagy minden final lenne, vagy mindenkeppen meg kellene mondanom hogy az adott valtozo final vagy nem (lasd scala, val es var :))

  4. Mefi január 31, 2013 1:35 de.

    Én mondjuk sok esetben – ahol természetesen lehet – a szép és érthetően fogalmazott kód érdekében szívesen feláldozom azt a néhány bájtot.

  5. Farkas Péter január 31, 2013 9:31 de.

    Szánom-bánom tudatlanságomat a final használta terén. Többször próbáltam már utána olvasni. Szinte mindig arra jutottam, hogy már-már hitvita szinten van a használni vagy nem használni. A saját (egyre jobban azt érzem, hogy téves) véleményem: Ahol jó részt találkoztam vele ott már túlzásokba estek, rontotta az olvashatóságot, növelte a “zajt”.
    Amennyiben lehetséges kérhetnék egy rövid összefoglalást, hogy mikor érdemes, mikor kell, mikor fölösleges és mikor ellenjavallt a final használta?

    • b0c1 (@b0c1) január 31, 2013 2:27 du.

      Igazabol ez hitvita lesz. Final annyit csinal hogy az adott nevhez ragasztja az adott referenciat, ennyi es nem tobb. En szeretem hasznalni, az en szemenek nem zavaro es nem erzem hogy a kod olvashatosagat rontana (ellenben pl attudom adni anonymous inner classnak a bejovo parametert haepp azkell), de volt olyan projectem ahol nemhasznaltuk es nem haltam bele 😀

      Nekem kart nem okoz, es altalaban hasznosnak itelem meg, de szerintem ezt kodolasi stilus valogatja.

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s

%d blogger ezt kedveli: