2012. március 18., vasárnap

Bzip2 buhera

Az angol wikipedia dump feldolgozásával bíbelődök szabadidőmben, a dump egy egyszerű XML formátumú file Bzip2 tömörítéssel. Csak a legutolsó ellenőrzött oldal szöveg van benne, de még így is 15 GB tömörítve. Az első ötletem az volt, hogy a commons-compress BZip2CompressorInputStream osztályával egyszerűen meghajtom. Az első teszt-futtatásakkor kezdett kiderülni, hogy nem muzsikál valami szépen, elég lassúcska az import. Az első ötletem az volt, hogy akkor többszálúsítom és az egyik szál csak Bzip2 kitömörítést hajt és PipedOutputStream-en keresztül átdobja egy másik szálnak, ami csak XML-t parsol és a mongodb-be mentést egy executor csinálja néhány szállal, hogy ott biztosan ne legyen fennakadás. Hát... nagyon büszke voltam az architektúrális szörnyszülöttemre egészen addig, amíg elösször le nem futtattam ugyanis az elbonyolítás eredményeként csak 3 százalékkal javult a feldolgozás sebessége. A magyarázat egyszerű, a bzip2 tömörítés annyira elviszi a processzoridőt, hogy ahhoz képest az XML feldolgozás és mongodb interanciók szinte semmi. Egészen pontosan összesen a 3 százaléka. Na ekkor töröltem le az elbonyolítást teljesen mert 3 százalékért nem érdemes kétszeresen elbonyolítani.

Azért egy "gyors" összehasonlítás érdekelt a bzip2 implementációk között:
  • A linux bzip2 programja 40 perc alatt tömörítette ki a 15 GB-os dumpot
  • a pbzip2 (parallel bzip2) 4 szálon meghajtva 20 perc lett (2 core x 2 thread van a laptopomban, szóval ez logikus) Ez nem rossz, de a pbzip2 nem része az alaprendszereknek általában
  • Ugyanehhez a commons-compress-nek 100 percre volt szüksége. Véletlenül ilyen szép kerek szám, nem én találtam ki.
  • Mennyi lenne ha csak IO lenne az egész: egy sata vincsi általában másodpercenként 100 megát fel tud olvasni szekvenciális olvasásnál, az 150 másodperc lenne elvileg, a gyakorlati teszt hajszál pontosan igazolta az elméletet :-)
Szóval azt találtam ki, hogy akkor beintegrálom a bzip2-t egy InputStream-ként és akkor a feldolgozást lehúztam kereken 40 százalékra. A bzip2-vel érdemes lenne még buherálni, csak ahhoz be kell lőni a procik számát, szóval kicsit komplikáltabb...

A szomorú az, hogy ez így csak linuxon fut, szóval jó lenne egy olyan InputStream, ami elmegy a bzip2-vel és fallbackel commons-collections-ra.

Ennyi lett a kód, és végülis ezzel sikerült kibékülnöm egyelőre.

Na, érdekességként az angol wikipédia adathalmazából azoknak, akik idáig eljutottak:

  • 162396 állat és növényfaj, illetve rendszertani akármi
  • 239847 település
  • 26312 hajó - ez teljesen beteg...
  • 11902 tudós, 7762 sportoló, 2679 verekedő, 91871 "egyéb személy"
  • 13172 író és 20084 könyv
  • 7508 folyó
  • 3003 politikai párt - és vajon mennyi korrupció?

2012. március 15., csütörtök

Kicsi a patched?

A Belgának van az a zseniális száma "Az a baj" címmel, pár apróbb módosítással tök jól leírja, hogy miért megy lassan az oVirt fdejlesztése. Ezer dolgon akadhat el minden, és persze el is akad. És ezek nem a szoftverfejlesztési kihívások mert az nem lenne gond, azért vagyunk itt.  Egyébként vannak csodák, csak nagyon ritkán, különben nem hívnák őket csodának :-)

Ha nem fetcheltél origint az a baj
Ha nem rebaseltél az a baj
Ha rossz branchen vagy az a baj
Ha kurva sok branched van az a baj
Ha a tököd kivan a gittel az a baj
Ha nem megy a gerrit az a baj
Ha nincs reviewer az a baj
Ha más patchen dependelsz az a baj
Ha túl nagy a patched az a baj
Ha nem írtál junit-tesztet az a baj
Ha rossz patchbe tetted az a baj
Ha az ezredik patchnél elbaszod az a baj
Én ezt a refactort másik patchbe tenném az a baj
Mindenki csak +1-et ad az a baj
Fastforward-policy az a baj
Kezdheted előről az a baj
Ettől nem lesz semmi se jobb az a baj

Szóval mégis mitől lenne gyors?

2012. március 13., kedd

OFF: meló-sztori

2000-ben és 2001-ben egy C++ fejlesztő cégnél dolgoztam és ott találkoztam egy kezdő programozóval. Hát nem volt fiatal, akkor is már 40 körül lehetett, doktorija volt vegyészetből és egyébként egy nagyon értelmes arc volt. A csákó kapott egy desktop gépet és Bjorne Strostrup C++ könyvét (ami szvsz egy szerencsétlenség) és elkezdte megtanulni azt a csodálatos nyelvet :) merthogy elötte nem C++ban tolta. Egy hét után érdekes kérdéseket kezdett feltenni, két hét múlva érdekes ötletekkel kezdett előállni, fantasztikusan haladt, én zseninek tartottam. Az 1 hónapos próbaidő végén már komolyan a kezét rázogattuk, amikor megjött a főnök a központból (jól hangzik mi? két iroda volt... csak ennyi) és megdöbbenésemre nemcsak hogy kirúgrta az embert, de ocsmány megalázó módon rúgta ki, mindenki elött.

Totálisan semmi lövésem nem volt arról, hogy mi állt a dolog mögött, de pár archiktektúrális kérdés mögötti okot sem értettem (a szoftverünk is egy halom szerencsétlenség volt) szóval munkaadóm egy nagy halom rejtély volt számomra is. Na és akkor pár hónappal később jött egy űber programozó megintcsak a központból, este kimentünk a városban mászkáltunk és közben megkérdeztem tőle hogy tud-e valamit arról, hogy miért rúgták ki a "srácot". Kiderült hogy pont ez a programozó nézte át a munkáját és azt a következtetést vonta le belőle hogy 100 % biztosan összemásolta valahonnan, mert az egyik fele zseniális a másik fele meg tiszta láma, ezt írta vissza a főnöknek és hát ez lett belőle.

A cégről annyit, hogy kb 3-4 hónappal később behalt és kirúgtak mindenkit. Ez nem azt jelenti, hogy mégiscsak van igazság, egyszerűen csak természetes szelekció in action. Addigra kiderült hogy az architektúra kérdésekben is hasonlóan zseniális döntések játszottak.

A nyolcadik hibámat csak nehezen mondom el
Kaptam a központból egy tojást és várni kellett hogy kikel
Kelt és rögtön megvert aztán bedobott egy kútba
Azóta ő helyettesít, ő visz titeket tévútra
- Kispál és a Borz még régen amikor még jó volt