lbzip2-2.0 benchmark

nice.

Köszi.

te munkád,

A 0.23-ig tartó 23 kiadás az én munkám. Ha letöltöd a honlapomról a legacy tarballt, vagy felrakod a disztródban lévő lbzip2 csomagot, akkor találsz benne egy README file-t; az dokumentálja az akkori állapotot. 2010. márciusában adtam ki, azóta én nem nyúltam hozzá.

(Illetve egyelőre még én vagyok a szponzorált karbantartója a debian csomagnak is, de ez már nem lesz így sokáig.)

A mostani fejlesztő/maintainer Mikołaj Izdebski, aki egy utolérhetetlen bzip2 guru és bitmágus (hexában olvassa a bit-stream-et, és fejből tudja az összes fázis algoritmusát; komolyan). Ő évekig dolgozott egy saját "yambi" nevű bzip2 tömörítő/kitömörítő stack-en, ami (nyugodtan állíthatom) páratlan. Például sokkal jobb teljesítménye van, és sokkal robusztusabb bit-stream hibákkal szemben, mint a hivatalos libbz2.

Mikołajjal akkor kerültem kapcsolatba, amikor bejelentette ezt a hibát. Aztán amikor megtalálta/kijavította a CVE-2010-0405-öt, akkor már nem állhattam meg, és megkérdeztem, hogy ki ő és mit csinál. Innen elkezdtünk levelezni, és a vége az lett, hogy az lbzip2-0.23-át áthelyezte yambi alapokra (a libbz2 helyett), valamint szétoptimalizálta a multi-worker decompressor-t az én kódomból (ami az lbzip2-ben igazából a kunszt).

Van, amit a kódomból ki is hajított ill. újraírt, mindenesetre a szálkezelés, a program szerkezete, a fő modul továbbra is az én kódom (bár az utóbbit kiegészítette egy kicsit, pl. a verbose opcióhoz a progress info-t továbbítani kell). A mostani kódnak, ha jól számoltam, kb. a harmada-negyede az enyém.

A yambi-ba iszonyatos mennyiségű kutatást és algoritmust tett bele (lásd ezt). Ebbe én nem is nagyon másztam bele (a libbz2 belseje ill. a file-formátum sosem érdekelt az elkerülhetetlenen túlmenően).

Azt viszont megnéztem / átbeszéltük, hogy a multi-worker decompressor-ban a bitminta-szkennelés sebességét hogyan sokszorozta meg; valami állati. (Erről írhatok többet, ha érdekel, de nem erőltetem; mindenesetre ehhez előbb el kellene olvasnod a README vonatkozó szakaszát.)

A 0.23 óta a hozzájárulásom tehát néhány tíz email, amelyek állítása szerint nem voltak haszontalanok. Én nagyon büszke vagyok, hogy a yambi végül az lbzip2-ben látott napvilágot. Pontosabban (a kódarányok figyelembe vételével) örülök, hogy egy ilyen nagyszerű projektnek az lbzip2 tudott vékony héjává válni.

Itt egyébként köszönetet kell nyilvánítanom egerész kollégának, akinek tapasztalt tanácsai a 0.23 utáni űrön átsegítettek, mert voltam olyan ponton, hogy letörlöm az egészet a francba. (Elégedetlenkedő, követelőző felhasználók, nem kívánt felelősség, stb.)

vagy csak népszerűsíted?

Már a 0.23 óta/előtt is elég gátlástalan marketingbe fogtam, de most aztán, hogy a kódot nem is én írom, végképp nincs megállás :) Számomra az lbzip2 egyik nagy leckéje a FLOSS-ról az volt, hogy jó bornak is kell a cégér. Néhány felhasználótól kaptam dicséretet is, hogy állat a forrás minősége meg a program, de ettől még alapvetően teljes sötétségben leledzett, amiből csak gátlástalan reklámozással tudtam egy icipicit kirugdalni.

Mondjuk a letöltési logom alapján nem nagyon van olyan szervezet-típus, amelyiknek sok az adata, sok a számítási kapacitása, és ne használná az lbzip2-t, de számszerűen nem sok a letöltés (főleg nem végfelhasználói programokhoz hasonlítva).

Plusz három magazin (egy japán, egy német és egy angol) nyomtatásban is írt (részben) róla cikket, szóval az öregkorra való emlékek már el vannak zárva :)

egyébként a 64 bites verzió hogy-hogy lassabb?

Innen idézve:

The 32-bit binary performs better during compression, while the 64-bit binary performs better during decompression. I suspect the 32-bit bzip2 library is faster in both modes; however, lbzip2's multiple-workers decompressor does a lot of 64-bit shifting, and this is likely so much slower in the 32-bit binary that its decompression advantage evaporates.

A 32 bites mód pedig jó eséllyel azért gyorsabb a 0.23-ban, mert (1) a libbz2 32 bites egészekkel dolgozik, a 64 bitből fakadó előnyöket nem használja ki, ugyanakkor (2) a 64 bitnek van hátránya is (pointer-ek, long-ok kétszer akkorák), ami kétszer akkora cache-lenyomathoz vezethet. A libbz2 rendkívül cache-érzékeny.

A közvetlen okot nem bizonyítottam be / mértem meg eddig, csak sejtem. Mindenesetre Knuth-nak van egy Flame About 64-bit Pointers című szösszenete, ami ebbe az irányba mutat.

windows-os verzió, esetleg 7z-be bekerülésre tervek?

cygwin-en tudtommal fordul-megy, legalábbis a 0.23. A 2.0-t még nem próbáltam.

A 7z-re nem látok se igényt (senki részéről :)), se esélyt. Ha windows felhasználó lennék, én egyértelműen a WinRAR-t használnám mindennapi munkára (rengeteg feature, biztonságiak is, többszálú, gyors, jó tömörítési arány); a 7z-t esetleg akkor, ha nagyon sok időm van, és nagyon jó tömörítés kell.

Az lbzip2-0.23 100%-ban a Single UNIX(R) Specification v2 szerint íródott, így cygwin-en elég jól megy emlékeim szerint, viszont windows-ra áttolni a szőrösebb részeket lényegében lehetetlen (gondolok itt a szignálok és a szálak vegyítésére). A 7zip pedig egy eredetileg windows-ra készül program (ez ordít még a portolt forrásról is), amelynek a p7zip néven ismert változata úgy illik a UNIX(R) parancssorba, mint tehénre a gatya.

Ettől függetlenül persze az LZMA hatalmas találmány; én csak annyit mondok, hogy senki sem tagadhatja le az eredetét.

... Elég részletes voltam? :)

Virágokat az öltözőbe, hibabejelentéseket Mikolajnak! ;)

Amekkora részem még van a kódban, akkora mértékben: örülök, ha hasznát veszed.

Egyelőre trekkelve van az új oldalon; sokat beszélgettünk róla. Nem nagyon lehet megfoltozni, mert ez igazából tervezési probléma.

Ha a memóriát blokkolásra képes erőforrásnak kezdjük tekinteni, akkor ronda holtpontokba lehet belefutni. Ami ötletek eddig előkerültek, azokban a holtpontok elkerülése vagy rontotta a teljesítményt, vagy mélyrehatóbb (szerkezeti) turkálást (végső esetben újraírást) igényelt volna. Én fáradt vagyok :)

Ráadásul ez egy kifejezetten szemét probléma; elég egyetlen függőséget, vagy egyetlen "ütemezési invariánst" elnézned a gráfban tervezéskor, aztán kódolsz két hetet, aztán a negyedik napon megáll.