többszálú bzip2 implementáció tesztelése sokmagos SMP gépen

 ( lacos | 2009. február 6., péntek - 3:23 )

Sziasztok,

írtam egy többszálú bzip2 szabad szoftvert (Julian Seward libbz2-jére alapozva), amelynek teszteléséhez segítséget szeretnék kérni. (Mivel ez nem a reklám helye, és szeretném elkerülni a népszerűségvadászat vádját, azért URL-t ill. programnevet nem írok; akit a lentiek fényében érdekel, a freshmeat-en vagy a google-lel megtalálja. Ha valakit az érdekelne, hogy minek írtam ilyet, az oldalon talál néhány teszteredményt, annak figyelmes böngészéséből kiderül.)

Alapvetően sokmagos SMP érdekel, 8 magig már teszteltem mások segítségével a programot (köszönet nekik). Egy korábbi változatot (szintén mások) teszteltek számomra egy 128 magos HP Superdome-on (szintén köszönet). Nagyjából ilyen kategóriájú rendszerhez hozzáférő, segíteni tudó és akaró kollégákat keresek. (Egyúttal remélve, hogy a programnak -- melyre a GPL értelmében nyilván semmiféle garancia nincs -- ezt követően hasznát is veszik esetleg.)

A teszt helyességet és skálázhatóságot vizsgálna. Minimális setup kell hozzá, a teszthez van hordozható shell script. Bármilyen UNIX 98 platform ill. "standard" csomagokkal ellátott modern GNU/Linux disztribúció megfelel (illetve utóbbiaknál talán a szükséges dash nem standard, ami nagy csúnyaság.) A felhasználótól csak egy irdatlan méretű, tömörítendő állományt kér a teszt.

Köszönettel:
lacos

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Tegnap tömörítettem be a 12G-s http-error.logot az egyik gépen. Ha ezt tudom... Egyébként FreeBSD-n működne elvileg ez a cucc? Igaz hogy mi 2-8 core-os rendszerekben utazunk, de igencsak hasznos lenne néha ha gyorsabban végezni a bz2.

Örülnék, ha tudnátok hasznosítani a programot. FreeBSD-t még nem láttam és FreeBSD-s felhasználótól nem kaptam még visszajelzést, de alapvetően működnie kellene, ui. a FreeBSD-nek szívügye a Single Unix Specification, annak ellenére, hogy nincs hivatalos bizonyítványuk róla:

http://www.opengroup.org/comm/press/01jun04.htm

A programot és a tesztszkriptet a SUSv2-höz igazodva írtam.

Hát mondjuk én Debiant használok, lennyt. Feltettem a pbzip2 csomagot, és azóta fele annyi időt eszik a bzip2.

Hónapokkal ezelőtt.

Nem volt nehéz ráakadni... apt-cache search parallel bzip

G

Hmm.... most van a mancsaim között egy Sun M5000, 8 db. 4 magos SPARC64 VII processzorral, magonként 2 párhuzamos thread-el, vagyis az oprendszerből (solaris 10) 64 virtuális cpu látszik.
Küldjél privátot, aztán keresek valami időpontot amikor nem hörögnek a userek....

-
(bocs, duplázódott az előző)

Ez mivel tud többet(jobbat) mint ez az implementáció:

http://compression.ca/pbzip2/

Én teszteltem Lacos cuccát a pbzip2 ellenében. Kb ugyanazt az eredményt kaptam mindkét esetben egy 2 magos Turion X2-es procin. Ami különbség, hogy ez nem külön tömörítő hanem egy filter a programok között. A hivatalos oldalán ezt olvastod:

"Lbzip2 is a Pthreads-based parallel bzip2/bunzip2 filter, passable to GNU tar with the --use-compress-program option. It isn't restricted to regular files on input, nor output. Successful splitting for decompression isn't guaranteed, just very likely (failure is detected). Splitting in both modes and compression itself occur with an approximate 900k block size. On an Athlon-64 X2 6000+, lbzip2 was 92% faster than standard bzip2 when compressing, and 45% faster when decompressing (based on wall clock time). Lbzip2 strives to be portable by requiring UNIX 98 APIs only, besides an unmodified libbz2."

--
Elméletileg nincs különbség elmélet és gyakorlat között. Gyakorlatilag van.

Köszönöm a tesztelést. Godot kérdésére adott válaszodat kiegészíteném a következőkkel (belátva, hogy nem volt reális elvárás ezt írnom a topicindítóban:

Ha valakit az érdekelne, hogy minek írtam ilyet, az oldalon talál néhány teszteredményt, annak figyelmes böngészéséből kiderül.

):

A projekt eredetileg kitömörítőként indult (ha megnézed a ChangeLog-ot, akkor látod, hogy eredetileg lbunzip2 volt a neve). A tömörítés triviálisan párhuzamosítható (kivéve persze, ha a tömörített blokkokat össze akarod shiftelni egyetlen bzip2 stream-be a végén, ami sebesség szempontjából nagy öngól, mert a muxert azonnal CPU-bound-dá teszi; ilyen pl. a 7za bzip2 modulja). Így a tömörítés és az egyszálú kitömörítés csak utólag lett hozzáadva.

A "kunszt" a többszálú kitömörítő:

  1. pipe-ból is párhuzamosan dolgozik,
  2. a single stream bz2 állományokat (egyetlen bzip2 stream-et) is párhuzamosan dob szét,
  3. a splitter nem CPU-, hanem IO- (pontosabban I-) bound, annak ellenére, hogy a bzip2 blokkok határai tetszőleges bitpozícióra eshetnek.

Ilyen felhasználási esetre példa: gpg -d kimenetét akarod kitömöríteni, vagy brutál hálózatról letöltve (wget -O -) egyből szét akarod dobni.

Javaslom, hogy az "oldalamról" jelenleg letölthető 3 reportba kukkantsatok bele, ha érdekel benneteket ennyire. Szerintem kibányászható belőle, hogy melyik esetben melyik programot érdemes használni. Javaslom a README-t is, ha valakinek van elég türelme :)

Az alapkikötés volt, hogy a libbz2-höz nem nyúlok.

Aha , a pbzip2 nem tud stdin-ből ill pipe-ból paralell dekompresszálni pl, no kipróbálom én is.

Kollégák csináltak egy esettanulmányt bzip2 párhuzamosításával, hallgatókkal, evaluációval Niagarán, stb, esetleg érdekelhet (pdf!):

http://digbib.ubka.uni-karlsruhe.de/volltexte/documents/614524

Team 2:

In particular, the entire library used in BZip2 as well as the I/O routines were rewritten using a producer-consumer pattern.

Vagyis a libbz2-t is párhuzamosította, ami hasznos, mert így esetleg library szinten is elérhető lesz (lbzip2 esetében ez kizárt, legjobb esetben is csak valami fork()-os megoldás jöhetne szóba, borzasztó bonyolultnak ígérkezne felépülni bármilyen hibából resource leak nélkül, önálló programban meg sima _exit(EXIT_FAILURE)).

Ennek bizonyos szempontból hátránya, hogy az "eredeti" libbz2-be bevezetett módosításokat nem követi. Például az 1.0.5-ben megjelent biztonsági rés foltozása nem került bele a libbz2-t szintén módosító bzip2smp ill. smpbzip2 programba (nem emlékszem pontosan, melyik(ek)be -- valamelyik talán az 1.0.3-ból indult el, és amikor legutóbb néztem, még nem húzták utána az 1.0.5-nek). Mondjuk a foltozás a kitömörítőt érintette, és ezeknek egyike sem foglalkozik kitömörítéssel.

Nyilván ha teljesen újraírja az ember a library-t, akkor ennek kisebb a jelentősége, mert jó eséllyel az eredetiben benne lévő rés nem szerepelni a saját műben sohasem (esetleg lesz helyette más :)). Ha jól láttam, pl. a 7za (p7zip) bzip2 tömörítője sem használja a libbz2-t.

A fentin túli okok, amiért nem akartam hozzányúlni a libbz2-höz:

  1. Belenéztem a forrásába :)
  2. Lappangott bennem ez:
    Our empirical findings show that considerable speedups can be gained by exploiting parallelism on higher abstraction levels through parallel patterns, which are more significant than speedups obtained from a fine-granular parallelization.

  3. A libbz2 (ahogy a PDF írja is) szét van optimalizálva szekvenciális futtatásra. A bzip2 man-ja is említi, hogy nagyon cache-tudatosan készült (a bzip2 borzasztó érzékeny a cache méretére).
    bzip2 usually allocates several megabytes of memory to operate in, and then charges all over it in a fairly random fashion. This means that performance, both for compressing and decompressing, is largely determined by the speed at which your machine can service cache misses. Because of this, small changes to the code to reduce the miss rate have been observed to give disproportionately large performance improvements. I imagine bzip2 will perform best on machines with very large caches.

    Számomra nem tűnt hasznos húzásnak eldobni ezt a befektetett munkát.

Az utolsó ponthoz kapcsolódóan: tömörítéskor a tömörítő szálak gyakorlatilag teljesen magukra hagyva, elszigetelten dolgoznak, ezért ha mindegyiknek jut egy dedikált nagyobbacska (L2) cache, akkor szép. A hyperthreading-nek ezért nincs semmilyen pozitív hatása az lbzip2 teljesítményére. Lásd még http://bzip2smp.sourceforge.net/

There is NO speedup coming from hyperthreading on the hyperthreaded machines, since hyperthreads don't have dedicated caches, and the bzip2 is very cache-dependent. Expect degraded performance if you try utilizing hyperthreads.

Core 2-kon (Duo és felteszem Quad is) relatíve ócskán megy (a hardware thread-ek száma alapján várható teljesítménynek a felét adja), mert ott minden egyes L2-n osztozik két mag, és az L2 általában nem elég nagy ahhoz, hogy elférnének egymás mellett a munkaterületeik, így folyamatosan kibabrálnak egymással a szálak. Athlon 64 X2-n nincs ilyen gond.

http://users.erols.com/chare/current_cpus.htm

Vissza a "team 2" alkotásához: a 8 magon elért 10-szeres (feletti) teljesítmény nagyon király, mindenesetre egyértelműen jelzi, hogy az alap bzip2 implementációt is újraírták. Külön kalapemelés, hogy ezt a gyorsulást úgy tudták elérni, hogy egy db bzip2 stream volt a kimenet. (Vajon összefügg ezzel, hogy ehhez a mutatványhoz ennél a sebességnél egy nyolcmagos gépen több mint 46 szálat kellett indítaniuk?)

Mindenesetre csak tömörítéssel foglalkozik. A bzip2-nél a kitömörítés is lassú, és a netről letölthető legtöbb tar.bz2 egyelőre a standard bzip2-vel készül (gondolom), így ha ezek kitömörítését sikerül felgyorsítani, akkor sokaknak tudunk segíteni.

Két dolgot jegyeznék még meg:

  1. A 900k néven emlegetett bzip2 input blokkméret valójában sem 900 * 1024, sem 900 * 1000 byte, hanem (900 * 1000 - 19) byte. Lásd https://lists.ubuntu.com/archives/ubuntu-devel/2006-January/014764.html. Ez empirikusan is ellenőrizhető, ki kell szedni 900 * 1000 byte-ot a /dev/urandom-ból egy munkaállományba (gyakorlatilag tömöríthetetlen), majd ebből a file-ból az első (900 * 1000 - K) byte-ot tömöríteni kell bzip2-vel (K fut 0-tól 19-ig), és a tömörített eredményben vizsgáljuk bzip2recover-rel, hogy hány bzip2 blokkot tartalmaz. Mindaddig, amíg K < 19, a blokkok száma kettő lesz, mivel az input túl sok ahhoz, hogy beleférne egyetlen bzip2 input blokkba.
  2. Az összes párhuzamos bzip2 ideiglenes móka; amint elkészül a párhuzamos lzma, kutya sem fog mást használni.

"Vissza a "team 2" alkotásához: a 8 magon elért 10-szeres (feletti) teljesítmény nagyon király, mindenesetre egyértelműen jelzi, hogy az alap bzip2 implementációt is újraírták."
Nem tudom biztosan, hogy mit értesz "alap bzip2 implementáció" alatt. Ha a bzip2 algoritmust magát, akkor nem, azt nem írták újra.

"Vajon összefügg ezzel, hogy ehhez a mutatványhoz ennél a sebességnél egy nyolcmagos gépen több mint 46 szálat kellett indítaniuk?"
A gép nyolcmagos volt, de magonként négy szálat tudott párhuzamosan futtatni, ami összesen 32 szálat jelent. Innen nézve a 10x gyorsulás már egyáltalán nem tűnik misztikusnak (; Hogy miért mentek 127 szálig, nem tudom; azt meg aztán pláne nem, hogy miért van a 2.b ábrán a kettes csapatnál olyan hirtelen ugrás 50 szál körül.
Az is érdekes még, hogy "realisztikusabb" számú szálnál (<16, de főleg <8) nem az a megoldás a leggyorsabb, ami összességében a legnagyobb gyorsulást eléri, sőt, kevés szálnál eléggé el is van maradva.

Nem tudom biztosan, hogy mit értesz "alap bzip2 implementáció" alatt. Ha a bzip2 algoritmust magát, akkor nem, azt nem írták újra.

Az algoritmust nem találták ki újra, viszont teljes egészében újraimplementálták. Ezt nem magamtól gondolom, a PDF-ből idéztem fent is:

In particular, the entire library used in BZip2 as well as the I/O routines were rewritten using a producer-consumer pattern.

A gép nyolcmagos volt, de magonként négy szálat tudott párhuzamosan futtatni, ami összesen 32 szálat jelent. Innen nézve a 10x gyorsulás már egyáltalán nem tűnik misztikusnak (;

Hoppá. Tényleg nem :) Mondjuk nem tudom, a 32 szál összesen hány (értelmes méretű) cache-en osztozott. Ha összesen 8-on, akkor nem csodálkozom.

A már említett Superdome-on (128 mag) az lbzip2 108-szoros skálázódást mutatott tömörítésnél (önmagához képest legalábbis; a standard bzip2-vel akkor még nem volt összevetve). Ezt most vagy elhiszitek, vagy nem, egyelőre nem tudok szépen formázott teszteredményt mutatni, csak a leveleimben szerepel:

--------
        1 | 142m25.224s |  0.9 MiB/s
      128 |   1m18.864s | 95.3 MiB/s

$ bc -l <<< '(142 * 60 + 25.224) / 78.864'
108.35392574558734023128
-------- 

A "miért pont ennyi szál viselkedik pont így" kérdésnél szerintem érdekes lehet, hogy milyen verziójú Solarist használtak. A Solarisban az 1:1 szálmodell a 8-as verzióban jelent meg, és a 9-esben lett kizárólagos (ha jól értem ezt: http://www.sun.com/software/whitepapers/solaris9/multithread.pdf). Mondjuk a karlsruhe-i jelentés dátuma (jól emlékszem?) 2008. november, tehát bizonyára 1:1-et használtak.

Értem én, hogy a pdf-ből idézted azt a mondatot, de nem tudom, hogy miért írták azt úgy oda. Mindenesetre jelzésértékű, hogy újraírást csak abban az egy mondatban említenek, azon kívül viszont mindenütt refaktorizálásról írnak, és azt hangsúlyozzák. Továbbá beszélgettem a szerzőkkel a tanulmány készítése közben/után, láttam előadást is róla, és mindig refaktorizálást emlegettek. Hidd el, hogyha valóban teljes újraimplementálásra került volna sor, akkor azt nem intézték volna el egy árva mondattal, hanem sokkal erősebben hangsúlyozták volna.

"Mondjuk nem tudom, a 32 szál összesen hány (értelmes méretű) cache-en osztozott. Ha összesen 8-on, akkor nem csodálkozom."
Az L2 cache 3MB, mint a 8 mag ezen osztozik. Hm, az annyit tesz, hogy 384k/mag? Soványka (;
Egyébként az 1GHz-es változatról van szó, nem az 1.4-es, bár nem tudom, hogy ez gyorsulás szempontjából számít-e; ha nem CPU korlátos, hanem memória, akkor szerintem nem igazán.

"Mondjuk a karlsruhe-i jelentés dátuma (jól emlékszem?) 2008. november, tehát bizonyára 1:1-et használtak."
Az esettanulmányt egy ICSE'08 workshopon májusban már publikálták, szóval attól korábbi.

Mindenesetre uname szerint jelenleg "SunOS i41s3 5.10 Generic_120011-14 sun4v sparc SUNW,Sun-Fire-T200 Solaris", de az tanszéki admin nem az az önszorgalomból update-elgetős fajta, szóval van rá esély, hogy ez még ugyanaz, amivel a méréseket is csinálták.

Az utolsó mondatot elmagyarázod?

Megnéztem wikipédián az LZMA-t, azt írja, ez a 7z algoritmusa.

Nekem úgy tűnik, hogy az én C2D gépemen a 7z nem csak kiírja, hogy két proci van, de párhuzamosan használja is mindkettőt.

Pár napja egy partíció image-et tömörítettem be pbzip2-vel és 7z-vel, és úgy láttam, hogy a pbzip2 szinte végig 200 százalékon pörgette a processzorokat, a 7z rosszabbul, kb. 160-180 között, a 200-at csak időnként érte el.

Namost ebből én úgy gondolnám, ez már most párhuzamos lzma.

A másik fele, ha a 7z a mostani sebességének a duplájával menne, akkor is lényegesen lassabb lenne, mint a pbzip2 mondjuk, márpedig sokszor a sebesség számít...

Vagy máshogy mondom: ha az a lényeg, hogy nagyon pici legyen, akkor úgyis 7z-vel tömörítek, nem érdekes, hogy mondjuk 45 percig tart, ami bzippel 10-15 perc alatt kész lenne.

Ha meg azt akarom, hogy gyors legyen, akkor meg úgysem ezt használom, de valószínű még csak nem is bzip2-t, hanem inkább gzipet, vagy mondjuk ha csak gyorsan hálón át kell tolni valami jól tömöríthető cuccot, akkor lzop-ot.

Tehát most vagy félreértem, hogy mi a párhuzamos lzma, vagy nem értem a gondolatmenetet...

G

Bocsánat, pontatlanul fogalmaztam. LZMA-n nem a 7-zip portolt változatát értettem (p7zip, 7z, 7za), mivel ennek parancssora nem unix-lelkű embernek való. LZMA-n a tukaani.org-on elérhető, "LZMA utils"-t értem, amelyből (utolsó ismereteim szerint) még nincs igazán király párhuzamos. A file formátumot (.xz) úgy látom, nemrég véglegesítették, amely lehetőséget ad a tömörített blokk méretének tárolására a blokk elején (3.1.3. Compressed Size). (Sajnos nem követeli meg minden körülmények között). Innentől kezdve a kitömörítési darabolás könnyen input-bound (tud lenni).

A két projekt (p7zip és lzmautils) egyébként nem nagyon látszik "ellenségeskedni", ugyanis az eredeti LZMA SDK és 7-zip szerzőjének, Igor Pavlovnak a neve ott szerepel az .xz formátumban is (0.1. Notices and Acknowledgements).

A gondolatmenetem az volt, hogy alapvetően lzma-t használnék, de most visszatart az a benyomás, hogy az "igazi unixoid" lzmautils még nincs kész (talán még design szinten sem, az 1.0.0-s fileformátum is január 14-én jött ki). Nincs olyan érettségi fokon, mint a gzip vagy a bzip2, ráadásul lassabb, mint a bzip2, úgyhogy kizárt, hogy használjam, hisz van (többszálú) bzip2 is. Amint megoldják a többszálúsítását (rendes command line formátum mellett), a fájdalom (= a bzip2-höz képesti lassúsága) a magok számával arányosan törpülni fog, így át fogok rá állni, és gondolom, más is. Tehát első megközelítésben számomra a méret a lényeg, de jelenleg akkora a sebességbeli különbség, hogy (pongyolán fogalmazva) a "második helyezettet" használom.

(A 7za LZMA párhuzamos is, bár sok magon még nem láttam, meg jól is tömörít, viszont a parancssora ill. a tömörített kimenete nem unix-lelkű. Nekem egy kompresszor ne tároljon fileneveket, kivált ne egynél többet, s kivált ne owner/group nélkül.)

Egyébként gzip-ből is létezik többszálú, Mark Adler által, pigz a neve.

Hát a 7z parancssorát én is utálom. Azt sikerült kisakkoznom, hogy akármi.tar-ból hogyan lesz akármi.tar.7z, és ha nagy fájlt tömörítek, ahol számít a méretkülönbség, akkor elolvasom a feljegyzésemet, hogy hogyan is használjam.

Kisebb méretnél meg nem használom.

G

LZMA-n nem a 7-zip portolt változatát értettem (p7zip, 7z, 7za), mivel ennek parancssora nem unix-lelkű embernek való. LZMA-n a tukaani.org-on elérhető, "LZMA utils"-t értem

- Valóban, a p7zip implementáció semmilyen szempontból nem unix-lelkületű. Sem a parancssora, sem a kimenete.

tar cf - directory | 7za a -si

segít valamit, de a fránya 7z konténerformátumtól így sem lehet megszabadulni.

Az lzma-utils-nak viszont nem csak a párhuzamosság a hiányossága. Gyakorlatilag sehogy nem tudod hangolni az algoritmust. Se szótárméretet, se semmit. Pedig pont ez lenne jó az egészben. Van egy ,,csúszka'' -1 -től -9 -ig, oszt' jó napot. Nekem ez eléggé fáj.
Lehetne --dict-size, meg a többi.

Az lzmautils parancssora szerintem idővel érni fog. Abból egy világszerte használt program fog kijönni; ha megnézed a tukaani.org-ot, eleve annak is írják.

Az lbzip2 parancssora még a -1 .. -9 megadását sem teszi lehetővé. Jó eséllyel nem is fogja :) Soha életemben nem adtam meg a bzip2-nek ilyen paramétert, attól az egy esettől eltekintve, amikor megnéztem, hogy egyre kisebb input blokkméretnél egyre jobban tudja használni a fix méretű, az input blokknál (illetve azzal arányos munkaterületnél) kisebb L2-t, ezért egyre gyorsabb. Ezt letudtam, aztán azóta sem adtam meg neki ilyen paramétert. Nem fogom kivezetni parancssorba: ha gyengébb tömörítésért cserébe gyorsabb akarsz lenni, használj más tömörítőt (párhuzamos gzip: pigz).

Ezt nem Neked mondom személyesen, csak jelzem, hogy ez a hozzáállásom.

Köszönöm a válaszod.

Nekem az a nézőpontom, hogy ha már tömörítö, legyen tömörítő. Az lzma egyik erőssége éppen a nagyfokú hangolhatóság. Ki tudja használni pl. a nagy memóriát. Nem mondom, hogy mindig mindent a maximális értékekkel tömörítek, nagyon sokszor használok pl. gzip-et, amikor bőven elég a ,,triviális'' tömöríthetőség, és fontos a sebesség. Viszont ha olyan dolgokat kell archiválnom, amik nagyon nagyok, és valószínűleg több évig nem fognak kelleni (ha egyáltalán valaha szükség lesz még rájuk), akkor úgy vagyok vele, hogy egy processz szépen elszüttyög velük, minél kisebb lesz, annál jobb. Csak azt akarom mondani, hogy a választás, állítgatás lehetősége alapvetően nem rossz dolog. Akinek megfelelnek a default értékek, annak nem muszáj babrálni vele.

Hozzaferek egy IBM x445-oshoz (16 db. Xeon 2.7 GHz, a Linux 32 procit lat), es nagyjabol csak tartaleknak van, tehat szabadon lehet garazdalkodni rajta. Irj uzenetet, megbeszeljuk.

Szerintem nyugodtan dobhattal volna linket, esatobbi, ennek a projectnek legalabb van ertelme.

---
pontscho / fresh!mindworkz

Oké, kösz a biztatást:

http://phptest11.atw.hu/

+1

Szerintem is nagyon hasznos dolog ilyen téren is fejlesztgetni, új ötleteket kipróbálni. Szerintem még egy SourceForge oldal is mehetne neki, ha már GPL-es, hogy többet értesüljenek róla. Ha felteszed SF-re, akkor én egy FreeBSD portot is csinálok belőle szívesen.

A FreeBSD port-ot nagyon megköszönném, de a SourceForge-ra (illetve bármilyen más netes SCM-be) nem fogom feltenni. Nem az egyes kiadások közötti diff-eket titkolom, egyszerűen nincs kedvem ezzel vacakolni.

(Ha valaki nekiáll google-lel, pillanatok alatt megtalálja az oldalt, ahonnan valamelyik kiadástól kezdve eléri mindegyik release-t, és készíthet magának diff-et; a "főoldalon" csak a friss van fenn, mert lusta vagyok. És azért van külön "főoldal", mert csak ott tudom megoldani legálisan a letöltők IP-jének naplózását (kíváncsi vagyok) -- a másik oldalon nem tudnám, így ott nincs naplózás. A másik URL-t természetesen megadom disztribúciók számára, akiknek fontos az automatikus upstream frissítés; egyáltalán nem "titok", csak próbálom a humán letöltőket a naplózós oldal felé terelni, mert -- ismétlem -- kíváncsi vagyok.)

Arról nem is beszélve, hogy ha esetleg kiesik az SF vagy nálam a net, akkor nem tudok commit-olni. (És nem, nem fogok emiatt git-et tanulni.)

Platformspecifikus patch-eket csak és kizárólag akkor olvasztanék be, ha az máshol sem árt, SUSv2-nek megfelel, nem nagyon ronda. (Nem lesz tele a kód #if-ekkel.) A beolvaasztás eleve úgy értendő, hogy megnézném a foltban az ötletet, aztán újraírnám. A copyright-on nem osztozom, köszönetnyilvánítás persze jár érte.

Már bocsánat, hogy a segítőkészségre ugatni kezdek :), kicsit szégyellem is magam. Szóval nagyon köszönöm, de az SF-et mint feltételt nem fogadom el. A hobbi nem demokratikus :) (Valóban, ettől még van pofám másoktól segítséget kérni teszteléshez, lásd itt. Elvégre a szoftver szabad.)

Ok, érthető az álláspontod. Én az SF-et nem is a repó meg a diffek miatt javasoltam, hanem azért, mert úgy tükrözve lenne rendesen a distfile. Néha-néha megesik, hogy adott portnak egyetlen tükre van, ami működik, de a világ egyes pontjairól valamiért nem lehet elérni, ezért akik onnan próbálják leszedni, azoknál problémákat okoz. Ettől függetlenül persze megcsinálom a portot, ez csak egy havaslat volt részemről. Másik javaslat, amit a portokról tudni érdemes, hogy sok fejlesztő x.y kiadásba utólag belefoglal kisebb javítást, ami miatt nem akar kiadni újabb verziót - és ez valamelyest ugye érthető is - de a portok, amelyek MD5/SHA256 hash alapján azonosítják be, hogy a leszedett distfile nem korrupt-e, ilyenkor ideiglenesen nem fognak működni, amíg valaki össze nem hasonlítja a régi és új distfile-t és ki nem javítja az ellenőrző összeget.
Érthető, hogy sok fejlesztő nem kíván vesződni ilyen dolgokkal, hogy SF tükrözés meg a kiadások efféle körültekintő kezelése, de valójában ezeknek a dolgoknak a leírtak miatt van jelentősége, nem csupán fölösleges formalizmusok.
A portot tehát megcsinálom hamarosan és akkor majd szólok, ha kész és leírom a tapasztalatokat, hogy van-e valami FreeBSD-specifikus dolog, ami nem működik, vagy ilyesmi.

Nagyon kösz a portot előre is.

Már közzétett release-hez irtózok hozzányúlni, eddig egyetlen alkalommal csináltam ilyet, amikor a freshmeat submit után, de még a megjelenés előtt, pár percen belül észrevettem valamit, és a megjelenés előtt sikerült feltölteni a javított verziót. Akkor mozgattam cvs tag-et, de normálisan ilyet nem szeretek csinálni, inkább kiadok egy újat. (Bár tényleg ciki/kényelmetlen.)

Szerintem nem lenne rossz reklam a projektnek, ha kidobnad hirbe, hogy van ilyen. A fikazok igy is meg fognak talalni, ugyse tudod oket elkerulni. Bar amennyire latom, szerencsere meg kevesen vannak.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Sajnos nekem is van akkora egóm, hogy erővel kelljen magam visszatartanom attól, hogy minden fórumon nagy dobra verjem. (A comp.compression hírcsoportba betoltam, de megbántam.) Próbálom azzal tűrtőztetni magam, hogy akinek fáj, hogy a bzip2 nem használja ki rendesen a gépét (ill. a pbzip2 bizonyos felhasználási eseteknél), az -- vélhetően -- nem nyugszik, hanem időnként körbenéz. Ezen a topic-on is sokat haboztam; végül csak legyűrt a sok szál iránti vágy :)

Intel C2Q-on meg tudom neked nézni 64biten, ha még nem volt ilyenen tesztelve. Valamint ha minden igaz 1-2 héten belül lesz egy 2xQuad-core Xeon is, azon is megnézhetem ha érdekel.
Egyébként több önbizalmat, szerintem jó kezdeményezés :).
--
Discover It - Have a lot of fun!

Kösz a pozitív hangot és a segítséget.

Nem kérem, hogy erre külön időt fordíts, mivel 8 magig már teszteltük. (Ha mégis megteszed, megköszönöm.) A Core 2 Quad-on mondjuk érdekes lehet megnézni, hogy valóban felezi-e rajta a teljesítményt, hogy egy L2-n két mag osztozik.

A 64 bit érdekes kérdés. Ha belenézel a forrásban az lfs.sh-ba ("large file support"), látni fogod, hogy (SUSv2 kompatibilis módon) faggatja a getconf-ot, hogy milyen kapcsolókat kell átadni a platform compiler-nek a nagy file-ok támogatásához (bár ennek minimális jelentősége van, hiszen a program kizárólag filter, számára az stdin-t, stdout-ot, stderr-t a shell nyitja meg valamilyen platformspecifikus alapértelmezett módban). A SUSv2 négyféle programozási környezetet definiál, ebből három támogat valamiféle 64 bitet:

http://opengroup.org/onlinepubs/007908775/xcu/getconf.html
http://opengroup.org/onlinepubs/007908775/xcu/c89.html

(A 64 bites int típusok mondjuk mindegyik környezetben kötelezőek, http://opengroup.org/onlinepubs/007908775/xsh/inttypes.h.html.)

Eddig nem annyira érdekes. Onnantól érdekes, hogy az lfs.sh milyen sorrendben próbál programozási környezetet választani.

Eddig egy sparc-on tudtam összehasonlítani, a 32 bites változat gyorsabb.

Gyorsan (~1,5 óra) csináltam egy összehasonlító teszt félét bzip2, pbzip2 és lbzip2 közt.
Felraktam ide az eredményeket.

Amit észrevettem az, hogy az lbzip2 mindenféle bzip-pel készült tömörített fájlt több szálon csomagol ki, míg a pbzip2 csak a saját maga által létrehozott fájlokat hajlandó több szálon kibontani.

Szerk: C2D@2ghz, 32bit
--
\\-- blog --//

Köszönöm a tesztet. Két megjegyzésem van:

  1. Amikor bzip2-vel illetve pbzip2-vel dolgozol, a kimenetet ne file-ba írasd, hanem a /dev/null-ba. A file-ba írásnak (akkor is, ha a program futása alatt csak a buffer cache-be megy) van költsége. Érdemes egyébként az inputot is /dev/shm alá tenni, vagy előmelegíteni vele a buffer cache-t (cat input >/dev/null). Ez persze nem a normál felhasználás, de a teljesítményteszt sem a normál felhasználás.
  2. Amikor lbzip2-vel dolgozol, akkor (a fentieken túl) kérlek ne használd a tar-t: nincs miért, költsége viszont van. Az lbzip2 -d <input >/dev/null simán megteszi. (Ha biztosítani akarod a pipe-ból olvasást (mivel az előző példa reguláris file-t olvas -- attól, hogy a standard input-ról jön, még simán reguláris file és seek-elhető lenne), akkor cat input {pipe} lbzip2 -d >/dev/null.

Kösz!
lacos

Egy 16magos (4x4 amd quad core) vason ki fogom probalni par napon belul; egyelore me'g valahogy egy jo nagy file-t kell krealni a problema szamara ;) (a /dev/urandom meg nem tudom mennyire lehet "reprezentative" egy tomoritoteszt/osszehasonlitas/ban).

Az elso" futtatasok:

$ dd if=/dev/urandom of=kaka.dat bs=1M count=512
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 79.7761 seconds, 6.7 MB/s
$ time cat kaka.dat | lbzip2 > /dev/null     

real    0m15.888s
user    3m58.727s
sys     0m7.288s
$ time cat kaka.dat | bzip2 -f > /dev/null

real    3m21.572s
user    3m20.733s
sys     0m1.584s

Egy otlet: a progi hordozhatosagat egy kis autoconf-fal novelnem majd a jovoben.

gratula, hajra!

A.

Egy otlet: a progi hordozhatosagat egy kis autoconf-fal novelnem majd a jovoben.

Kb. annyira van szukseg autoconfra egy ilyen projectnel, mint sirasonak a fagyott talajra. :)

---
pontscho / fresh!mindworkz

Hat, tul azon hogy nemtrivialis libeket (bz2 dev) tartalmaz, amit nem art kulturaltan kibanyaszni a matrixbol, effele nem-tul-elegans megoldasokat is szuksegtelenne' tesz, mint pl:

CFLAGS=$$($(SHELL) lfs.sh CFLAGS) -D _XOPEN_SOURCE=500 -pipe -ansi -pedantic -O3

ha ezeket a kis aprosagokat osszeadod, maris tobb sallang gyult ossze mint amekkora egy jolnevelt (ezen projekt igenyeinek megfelelo") configure.ac lenne.

A.

Akkor is felesleges, valojaban az a shell script is az. Gyakorlatilag ennyi leforditani nalam ugy, h a vegeredmeny egy UNIBIN binaris (tehat egyszerre i386-ra es ppc-re):

Aeon:lbzip2 pontscho$ cat Makefile.osx 

SRCS = main.c lbzip2.c lbunzip2.c lbunzip2_single.c lacos_rbtree.c
OBJS = $(SRCS:.c=.o)

CFLAGS = -arch ppc -arch i386 -O3 -isysroot /Developer/SDKs/MacOSX10.4u.sdk
LDFLAGS = -lbz2 -lpthread -arch ppc -arch i386
export MACOSX_DEPLOYMENT_TARGET = 10.4

.c.o:
	$(CC) -c $(CFLAGS) -o $@ $<

all: $(OBJS)
	$(CC) -o lbzip2 $(OBJS) $(LDFLAGS)

clean:
	rm -f $(OBJS) lbzip2

Siman modosithato ugy, h barmely platformon mukodo Makefile legyen belole, es nem kell hozza tobb szaz kilonyi shell script es egyebb varazslas.

---
pontscho / fresh!mindworkz

Hehe, nekem pont az osx-re portolando, futasideju dinamikusan betoltendo" cuccok (-ldl, *.dylib vs. *.so, hulye cc kapcsolok, amik persze masok, stbstb) volt az ami utan azt mondtam hogy oke, akkor most inkabb autoconf :] Azert mar ezzel sem volt annyira egyszeru", hogy menjen i386/64: deb, fc, sparc/sunos, sparc/deb, osx plusz dec/netbsd alatt is, ugyanaz a forras-fa, "siman modosithatas" nelkul.

Oszinten?

-rw-r--r--  1 pontscho  staff  2460 Feb  4 16:24 config.mak

Ennyi kellett ahhoz, h forduljanak a cuccaim osx/w32/lnx/*bsd/osf1-re x86/ppc/sparc64/aplha64-re. Make rettenetesen jol hasznalhato eszkoz, amit ha tud hasznalni valaki, akkor nincs szukseg masra. Csak a sok uj sutetu huszar (jellemzoen a linux "developerek") ezeket mar elfelejtettek es ekkor szuletett az auto*. Ne vedd szemelyeskedesnek, elhiszem, h neked nagyon jo az autoconf, nem ketlem, de en koloncnak tartom. Plane, h nem egy esetben ugy kezdodik egy csomag leforditasa, h egy masik shell scriptbol modositom az autoconf altal generalt kodot azert, h mukodjon is.

Szerk: ha a CFLAGS, LDFLAGS melle odabokod a -arch ppc64 -arch x86_64 flag-ket is akkor ez lesz belole:

Aeon:lbzip2 pontscho$ file lbzip2
lbzip2: Mach-O universal binary with 4 architectures
lbzip2 (for architecture ppc7400):	Mach-O executable ppc
lbzip2 (for architecture i386):	Mach-O executable i386
lbzip2 (for architecture ppc64):	Mach-O 64-bit executable ppc64
lbzip2 (for architecture x86_64):	Mach-O 64-bit executable x86_64

---
pontscho / fresh!mindworkz

persze, sokaig en is makefile-ba tettem bele ezeket. de nem csak a fenti peldak miatt jo szvsz ez az egesz marhaskodas az autoconf-fal hanem egy fokkal rendszerezettebb lesz a cucc, ha csomagolni, dokumentalni (csak a legalappvetobbek: texi, *roff, help2man), install-alni, stb is kell. Ha csak makefile-ban minden megoldhato, az ugy onmagaban tenyleg nem rossz; de a kollega altal hasznalt makefile, ami behaxol egy sh-szkriptet... akkor mar inkabb autoconf.

Plane, h nem egy esetben ugy kezdodik egy csomag leforditasa, h egy masik shell scriptbol modositom az autoconf altal generalt kodot azert, h mukodjon is.
E?

E?

Napirajz \o/

Pl. cURL. Szepen felparametereztem config scriptet, ahogy a nagykonyv megirja egy osx alatt mingw32-vel torteno cross compile-hoz. Hibatlanul le is fut, minden tok jo. Egeszen addig amig nem akarom leforditani. Ugyanis hiaba kozoltem vele, h mi a compiler, o csak azert is a "gyari" gcc-vel akar forditani, es h teljes legyen a kep, egy cygpath nevu dolgot keres, ami ugye nincs. Errol csak egy sed scripttel tudtam lebeszelni.

Vagy a masik eset. OSX-en --disable-dependency-tracking nelkul az autoizes forrasok nagy resze nem fordithato, mert gcc - jogosan - csak egy arch-ra tud dep listat generalni. Lehet en vagyok moho azzal, h unibint akarok forditani :)

Mikor ezekbe belefutok, nagyon csunyan tudok karomkodni, mert mar tobbet er az idom, mint h minden egyes aldott alkalommal ujra es ujra vegig szivjam ezeket. Tobb szazezer soros kodjaink vannak szimplan a fent emlitett platformokra osszerakva csak make-kel. Sosem volt eddig gond vele.

De ez mar nagyon-nagyon off topic.

---
pontscho / fresh!mindworkz

Napirajz \o/
glotah ;)

Várj, a http://hup.hu/node/66857#comment-714450-ben nem pont azt mondtad, hogy make-ben van fuggoseg kezeles, kb. 5 sorbol ki is hasznalhato? Nem akartam belekötni, gondoltam biztos jobban tudod, bár határozottan úgy emlékszem rá, hogy a SUSv2 make bizony nem tud semmilyen rekurzív függőséglistát előállítani (gráfot, amit majd topologikus rendezés szerint be kell járni). Itt fent te is azt mondod, hogy a gcc generálja a dep listát. Akkor most mit akartál mondani a másik hozzászólásban (make-ben van fuggoseg kezeles, kb. 5 sorbol ki is hasznalhato)? A .d, .Tpo meg hasonló megoldások szerintem nem szabványosak.

A make-ről szívesen tanulok :)

Oke, nem voltam eleg egyertelmu.

depend:
        $(CC) -MM $(CFLAGS) $(SRCS) 1> .depend
ifneq ($(wildcard .depend),)
include .depend
endif

Remelem igy mar az. GCC generalja a grafot, make pedig alkalmazza. Persze ez eleg gnu spec a gcc miatt. Most igy hirtelen nem emlekszem, h az altalad emlitett make verzio ezt eszi-e vagy issza.

---
pontscho / fresh!mindworkz

Az -M-et a SUSv2-ben nem ismeri a c89, a SUSv3-ban (= POSIX 1003.1, 2004 Edition-ben) pedig nem ismeri a c99.

Az ifneq, wildcard, include kulcsszavak egyikét sem ismeri sem a SUSv2 make, sem a SUSv3 make. Utóbbinak érdemes elolvasni a RATIONALE szakaszát, ugyanis beszél többek között az include-ról:

Historically, the make utility has been an especially fertile ground for vendor and research organization-specific syntax modifications and extensions. Examples include: [...] Adding C preprocessor-style "include" and "ifdef" constructs (System V, GNU, BSD, and others).

[...]

The best way to provide portable makefiles is to include all of the rules needed in the makefile itself.

[...]

The System V INCLUDE feature was considered, but not included. This would treat a line that began in the first column and contained INCLUDE <filename> as an indication to read <filename> at that point in the makefile. This is difficult to use in a portable way, and it raises concerns about nesting levels and diagnostics. System V, BSD, GNU, and others have used different methods for including files.

The System V dynamic dependency feature was not included.

A SUS az én meglátásomban egy "write once, compile anywhere" helyzetre törekszik, és a szabvány a hangsúlyt a "compile anywhere"-re helyezi. A "write once" hogyanja a fejlesztő dolga, "develop anywhere" nem szerepel a célkitűzésben.

Elsore is vagtam az indokot, de van egy pelda ra, h van egy apro gond vele:

gcc $(/bin/sh lfs.sh CFLAGS) -D _XOPEN_SOURCE=500 -pipe -ansi -pedantic -O3 -c main.c
getconf: no such configuration parameter `_XBS5_ILP32_OFFBIG'

Sima BSD hasonlo az osx-en latottakhoz, (azonkivul, h nem fordul ezzel):

gcc $(/bin/sh lfs.sh CFLAGS) -D _XOPEN_SOURCE=500 -pipe -ansi -pedantic  -O3 -c main.c
getconf: no such configuration parameter `_XBS5_ILP32_OFFBIG'
main.c: In function 'setup_opts':
main.c:313: error: '_SC_THREAD_THREADS_MAX' undeclared (first use in this function)
main.c:313: error: (Each undeclared identifier is reported only once
main.c:313: error: for each function it appears in.)

OSF1-en, mert ostoba a shell:

xxx> make
gcc $(/usr/local/bin/bash lfs.sh CFLAGS) -D _XOPEN_SOURCE=500 -pipe -ansi -pedantic  -O3 -c main.c
sh: syntax error at line 1: `(' unexpected
*** Exit 2

A $($(SHELL) lfs.sh CFLAG)-t `$(SHELL) lfs.sh CFLAG`-ra cserelve mar jo, ez a $() tipusu behelyettesites eleg uj otlet a shell-ben. Mondjuk a kerdes eleg teoretikus, mert par helyen at kell(ene) dolgozni a forrast, h forduljon rajt.

OpenBSD/sparc64-en es Solarison most passz, az otthon van kikapcsolva en meg a vilag vegen.

Amit mondani akartam, h szep es jo az a SUSvx, es h torekednek egyseges szabvanyra, de nem mindig jon ossze a dolog az egyedi aprosagok miatt. Ezt szoktak megoldani azzal, h kulonbozo platformokhoz kulonbozo Makefile-okat dobnak ossze, vagy bevetik az autosux-ot, ami vagy mukodik vagy nem. Sajna (vagy hal'isten, nem tudom eldonteni) ezek kvazi szabvanyokka valtak az utobbi idoben a sok elterjedt, a GNU "szabvanyait" elonyben reszesito szoftverek miatt. Nem veletlenul van az icc-nek is gcc kompatibilis interface-e, es van az oscsotany OSF/1-re is GNU make.

Amugy ha gondolod, megfixalom a fentieket ugy, h minnel kevesebb helyen kelljen modositani a kodod.

Szerk: remelem ertheto mit akartam mondani, igy kave elott eleg nehez a beszelokemet kovetni. :)

---
pontscho / fresh!mindworkz

Erre:

gcc $(/bin/sh lfs.sh CFLAGS) -D _XOPEN_SOURCE=500 -pipe -ansi -pedantic -O3 -c main.c
getconf: no such configuration parameter `_XBS5_ILP32_OFFBIG'

nagyon egyszerűt fogok mondani: nem SUSv2 a getconf-od. Ha megnézed a README-ben az Installation alatti első mondatot:

Please enable SUSv2 conformance in your environment.

Hogy ezt a saját rendszereden hogyan tudod megtenni, abban nem tudok segíteni. Ha megnézed az lfs.sh-t, van benne egy glibc-s bugreport-azonosító, mivel még a glibc getconf-ja sem volt valóban SUSv2 konform. Legnagyobb megdöbbenésemre Ulrich Drepper a mai napon elfogadta a bejelentésemet és a CVS-ben javította a getconf-ot.

Megkérdezheted, hogy ha alapvetően az a hozzáállásom, hogy a rendszer csináljon SUSv2 kompatibilitást, akkor miért kivételezek a GNU/Linux-szal, és azon belül is a Debian-nal, vagyis azokra miért rakok be workaround-ot. (Lásd az lfs.sh-t, ill. az Installation-beli záróljeles tippet GNU/Linux felhasználóknak.)

Azért, mert azon dolgozom, és az arra való specifikus workaround-ot képes leszek karban tartani. FreeBSD-t sajnos még sosem láttam, de ha küldenétek is rá most érvényes workaround-ot, akkor sem tenném be, mert nem tudnám karbantartani, tehát az upstream tarball-ban rátok lennék utalva, vagy közösségi projektté kellene tennem az lbzip2-t.

Annak persze nagyon örülnék, ha valaki csinálna rá egy kívül karbantartott port-ot :)

A _SC_THREAD_THREADS_MAX makróval ugyanez a helyzet: ha nem tudja a libc-d, akkor vagy nem SUSv2 módban vagy, vagy a libc-d nem SUSv2.

OSF1: Az OSF1 az általam látott egyik, a SUS-hoz leghívebb OS. Már a SUSv1 (UNIX 95) időkben is LP64 volt! Természetesen van rajta SUSv2 shell, le is van írva, hogyan kell használni (talán standards(5) man lap, BIN_SH és egyebek), csak te szerintem nem állítottad be / nem adtad át a make-nek. OSF1-en (ex has, már nem emlékszem pontosan) leginkább így kellene fordítani:

$ # beállítjuk a SUSv2 környezetet, majd
$ make -f Makefile.portable SHELL=/path/to/SUSv2/shell

Ha jól emlékszem, OSF1-en (Tru64-en) a standards(5) két dolgot ír elő SUSv2-höz: az egyik a BIN_SH, a másik pedig az, hogy a PATH-od elejére be kell tenni valami extra könyvtárat, ami megdöbbentő módon két binárist tartalmaz: egy sh nevűt, és egy make nevűt... :)

Tehát OSF1-en nem ostoba sem a shell, sem a make, csak te nem azokat a változatokat használtad belőlük, amelyeket én a README-ben kértem tőled.

Read The Fine Manual, please :)

(Annyit azért megjegyzek, hogy az OSF1-en a <pthread.h> elkezd sírni, ha nincs -pthread kapcsoló megadva a c89-nek. Na ez borzasztó hiba, nem is értem, hogyan nem bukott meg rajta a SUSv2 tanúsítványuk. Nincs workaround, javítsák meg a Tru64-et, vagy minden Tru64-es felhasználó szitkozódva írjon bele a Makefile.portable-be.)

Amit mondani akartam, h szep es jo az a SUSvx, es h torekednek egyseges szabvanyra, de nem mindig jon ossze a dolog az egyedi aprosagok miatt. Ezt szoktak megoldani azzal, h kulonbozo platformokhoz kulonbozo Makefile-okat dobnak ossze

Hát nem tudom megállni, ide be kell raknom, amit az egyik segítőkész huppernek írtam:

Például a p7zip-et gcc-vel akartam fordítani Tru64-en. A p7zip-ben van kb. 20-30 makefile, van köztük olyan, aminek az a neve, hogy makefile.tru64_gcc, vagy valami ilyesmi. (Az általam elvárt platform compiler-t (c89) nem használja, de nem is használhatná, mivel a p7zip nagyrészt C++-ban van megírva, C++-ra a POSIX pedig egyáltalán nem tér ki tudtommal.) Nosza, az INSTALL doksi szerint

$ cp makefile.tru64_gcc makefile.machine
$ make

Láss csodát, nem működött, bele kellett turkálnom, mert amióta a makefile.tru64_gcc készült, azóta kijött új gcc, kijött új Tru64, és így tovább.

A konkrét problémára nem emlékszem, de bele kellett reszelnem valamilyen plusz kapcsolót -- azt hiszem, a Tru64-en a megakasztotta a fordítást, ha a compiler előzetesen nem kapta meg a -pthread kapcsolót. A -pthread persze borzasztóan nem standard, de az isten szerelmére, nekem a platformhoz adott specifikus "makefile.tru64_gcc"-t kellett emiatt reszelnem!

Vagyis hiába vette Igor Pavlov és barátságos felhasználói a fáradtságot a 20-30 makefile elkészítésére, ezek közül up-to-date jó ha 3-4 van, saccra.

Amugy ha gondolod, megfixalom a fentieket ugy, h minnel kevesebb helyen kelljen modositani a kodod.

Köszönöm, de az általam kiadott csomagba nem akarok ilyet beletenni. Az én véleményem az, hogy a kód (C, shell, Makefile.portable), amennyire csak kitellett tőlem, a SUSv2-höz igazodik. Az eddig bejelentett problémák (amelyeket persze köszönök) mind arról szóltak, hogy "a rendszerem nem tudja a SUSv2-t, vagy nem állítottam be rajta a SUSv2-t". Úgy érzem, az ilyen gondok csomagbeli elhárítása nem az én feladatom (mellesleg egyszerűen nincs is kedvem hozzá, bántja a kis kényszeres szépérzékemet). Úgysem tudnám olyan jól megcsinálni (külső segítséggel sem), mintha valaki összetolna az adott rendszerhez egy rendes, központi fába kerülő, karbantartott patch-et, port-ot, ahogy én is csináltam a debian-hoz. (Persze hogy bekerül-e egyáltalán, az jó kérdés.)

Amen atyam. :) (Amugy nem vagyok egy OSF1 betyar, csak van accom egy alfara, es idonkent ra szoktam nezni ha olyanom van.)

---
pontscho / fresh!mindworkz

nem arrol volt szo hogy linuxal foglalkozol csak? miert kell belemenni ennyire a dolgokba?
mas, mondjuk engem qvara idegesit a gnuizm pl: solarison talalkozok vele sokat, szal szerintem (is) jo lenne valami olyan makefile/autofools/akarmi moccert kitalalni ami mindenhol muxiq

--
1&2

Én szurkolok neked, hogy rábeszéld a színtiszta make használatára, de fenti példád pl. helyből 3 db gnuizm-ot használ: ifneq/endif, wildcard és include. BSDmake alatt pl. ".if ! akarmi" illetve .include formában kéne írni, de kapásból. pl. a wildcard-ra nem tudok megoldást. És gyanúm szerint mondjuk Sol/HP/AIX rendszeren se menne extra progi telepítése után a fenti pár sorod.

Az már csak extra morgolódás, hogy és mi van az alapból nem gcc-t használó rendszerekkel (gondolok itt megintcsak a fenti hármasra: szerintem a -MM mint makefile generátor, nem igazán létező megoldás más (nem-gcc) rendszerekben. Akkor már inkább a makedepend parancs, de az ugyanúgy nem hordozható.

BSDmake alatt pl. ".if ! akarmi" illetve .include formában kéne írni, de kapásból. pl. a wildcard-ra nem tudok megoldást. És gyanúm szerint mondjuk Sol/HP/AIX rendszeren se menne extra progi telepítése után a fenti pár sorod

Jah, miutan lefirkaltam a dolgot jutott eszembe, h ez eleg gnu spec. Aztan az is, h ezek (HPUX-ot leszamitva, azzal meg nem futottam ilyen szinten ossze) mindegyiken ott figyel a gmake is.

Az már csak extra morgolódás, hogy és mi van az alapból nem gcc-t használó rendszerekkel (gondolok itt megintcsak a fenti hármasra: szerintem a -MM mint makefile generátor, nem igazán létező megoldás más (nem-gcc) rendszerekben.

Igen, ez meg a komment iras elott leesett, de mivel lacos gcc-t emlitett, mint amivel legeneralja a grafot, ezert mertem oda firkalni.

---
pontscho / fresh!mindworkz

Természetesen pontatlanul fogalmaztam :)

ha user #inlcude-ot változtatok, tolok egy gcc -MM -MG-t és bedrótozom: arra gondoltam, hogy egy ekkora méretű projektnél észre bírom venni magamon, ha user #include-ot változtatok meg. Ilyenkor gyorsan átváltok a shell-be, futtatok egy nem hordozható gcc -MM -MG-t, a kimenetén (az explicit függőségeken) egy kicsit dolgozok (jó eséllyel nem kézzel), vagyis hozzárakom a fordítási "akciót" mindegyik függőséghez; és a létrejött Makefile részletet statikusan belemásolom a Makefile-ba. (Ezt az egészet a régebben szokásos "make depend" alá is be lehet tuszkolni, ahol a Makefile szintaxisa hordozható marad, csak a "depend" target máshol esetleg nem fut, de nem is hívja senki.) Így

  • én fejlesztés közben (a projekt kicsike mérete miatt) könnyen tudok függőségeket generálni; ill. esetleg nagyobb projektnél is, ha ritkán változtatok user #include-ot
  • a Makefile nálam csak a módosult forrásokat fordítja újra,
  • a "végfelhasználó" hordozható Makefile-t kap,
  • és ha olyan make-je van, még parallel build-et is tud csinálni, mert a függőségek miatt nem tud elromlani a sorrend (mondjuk a projekt mérete miatt a parallel build itt konkrétan nonszensz). Ez persze egyetlen binárist forrásokból előállító Makefile-nál talán nem olyan lényeges.

Vagyis alapvetően a gcc -M-be nem köthetek bele, ha egy egyébként hordozható Makefile-ban (vagy egy abból meghívott akármilyen script-ben) szerepel, hiszen a hozzá való target-et a végfelhasználó (aki csak lefordítja) nem fogja kérni.

megjegyzem az ifneq/endif helyett eleg a "-include .depend" (hangsuly a "-"-n).
es a manual szerint ezt nem is csak a gnu make tudja.

- Use the Source Luke ! -

Ez nagyon csecse, de az implicit rule-okat én nem szeretem, mert a függőségeket nem tükrözi, és fejlesztés közben nem bízom abban, hogy pont azt fordítja újra, amit módosítottam.

Az explicit rule-ok statikus vagy menet közbeni generálásával most ne foglalkozzunk, ahány ház, annyi szokás; ekkora méretű projektnél ha user #inlcude-ot változtatok, tolok egy gcc -MM -MG-t és bedrótozom :)

Plusz egy: mit értesz azon, hogy valojaban az a shell script is {felesleges}? Melyik shell script?

Ez nagyon csecse, de az implicit rule-okat én nem szeretem, mert a függőségeket nem tükrözi, és fejlesztés közben nem bízom abban, hogy pont azt fordítja újra, amit módosítottam.

Az explicit rule-ok statikus vagy menet közbeni generálásával most ne foglalkozzunk, ahány ház, annyi szokás; ekkora méretű projektnél ha user #inlcude-ot változtatok, tolok egy gcc -MM -MG-t és bedrótozom :)

make-ben van fuggoseg kezeles, kb. 5 sorbol ki is hasznalhato.

Plusz egy: mit értesz azon, hogy valojaban az a shell script is {felesleges}? Melyik shell script?

Az lfs.sh. Nem nyalaztam at, h mit csinal, de abbol tekintve, h az eredeti Makefile-lal is gond nelkul lefordult minden, nem letfontossagu. :) Megegyszer mondanam, annyira nem melyedtem bele.

---
pontscho / fresh!mindworkz

Az lfs.sh. Nem nyalaztam at, h mit csinal, de abbol tekintve, h az eredeti Makefile-lal is gond nelkul lefordult minden, nem letfontossagu. :)

http://hup.hu/node/66857#comment-714302

A getconf használatát ne nevezzük "nem túl elegáns megoldás"-nak, mivel a getconf az egyetlen szabványos módszer shell-ből azoknak a kapcsolóknak a lekérdezésére, amelyekkel ilyen vagy olyan 64 bites programozási környezetet lehet választani. (Lásd máshol a topic-ban.)

Az valóban nem elegáns, hogy minden fordításhoz meghívom egyszer a script-et, a linkeléshez meg kétszer, de könyörgöm, 5 db forrásról és egy linkelendő binárisról van szó...

Kösz a tesztet és a szurkolást.

A /dev/urandom talán valóban nem a legjellemzőbb input :)

Egy otlet: a progi hordozhatosagat egy kis autoconf-fal novelnem majd a jovoben.

Úgy érted, az én helyemben? Ki van zárva, hogy egy hobbiprojektért megtanuljam az autoconf-ot. A program hordozhatósága (szabványokat tekintve -- hadd jelentsem ki nagyképűen) nagyjából maximális, leszámítva azokat az esetleges linuxizmusokat/gnuizmusokat/debianizmusokat, amelyeket legnagyobb erőfeszítéseim ellenére sem tudtam nem belerakni / kigyomlálni / észrevenni.

Arról nem tehetek, hogy a mai, ingyen hozzáférhető operációs rendszerek vagy nem támogatják a SUSv2-t, vagy nem árulják el azokat a beállításokat, amelyekkel (effektíve) támogatják. Az autoconf-ot nagyon maszat megoldásnak tartom, bár a gyakorlatban bizonyára jól tud működni, ha valaki hajlandó hozzányúlni és megtanulni. Az autoconf a gyakorlati, könyékig olajos, sufnibarkács megoldás; én inkább a formális standard-okat szeretem, bár ez valóban jobban dolgoztatja a felhasználót (ki kell találnia, hogyan tud SUSv2 lenni). "Kicsit" purista vagyok :), és nem szeretnék ötven autoconf/automake állományt beleröffenteni a tarball-ba (melyeknek mérete ráadásul sokszorosan meg is haladná a saját kódomét).

A nehézséget az okozza, hogy míg a legelterjedtebb fordító, a gcc, és a legelterjedtebb(?) libc, a glibc helyből támogatják a "C89" nyelvet ill. a SUSv2 interface-eit, addig a legelterjedtebb(?) shell (bash) tapasztalataim szerint nagyon nem támogatja a SUSv2-ben leírt shell-t. A többi shell-ről nem is beszélve; eleve rengetegfélét használnak az emberek. A helyzetet súlyosbítja, hogy míg C-ben az ember nem szokott interaktívan bütykölni (létezik ugyan C REPL, de kevesen élnek abban szerintem), addig a bash (ill. egyéb nem-POSIX shell) az emberek testi-lelki jóbarátja, így mindenki elvárja, hogy bármely shell script az ő shell-jében menjen jól. Míg az emberek feje (legalábbis ha megfelelő API doksikat nézeget, lásd SUS) nagyjából szabványos C-vel van tele, addig az emberek feje abszolút hordozhatatlan ill. nem szabványos shell-lel van tele (az enyém is!)

GNU/Linux-on az egyetlen általam ismert POSIX shell a Debian Almquist Shell (dash), amit az ash-ból portoltak. Ez még számomra is jókora meglepetés volt, nem is olyan régen; ugyanis interaktívan dolgozni én is csak bash-ban vagyok hajlandó. Hordozható program írására azonban GNU/Linux alatt a dash való (és a SUSv2 környezethez kellenek bizonyos GNU utility-k is, például GNU coreutils, diffutils, time stb).

Persze ha valaki bármilyen OS alá csinál egy port-ot, azt megköszönöm, de beolvasztani szinte biztos, hogy nem fogom. Nyilván az volna a legszebb, ha a Debian-ba bekerülhetne a csomag (már debianizáltam, a mentors-on elérhető), azonban a szponzorom most nagyon nem ér rám.

Szerintem az autoconf-ot nyugodtan meg lehet tanulni egy hobbiprojekt kedveert. Az nem annyira agyu-vereb. Ami tenyleg durva es tenyleg nem erdemes megtanulni az az automake/libtool/aclocal/... na, azok durva'k. Nem keverendo" :)

Az autoconf lenyege, hogy olyan sh-szkripet gyart le, ami egy kavefozon is lefut. A tobbivel nem kell torodnod. A kis extra szkript-toredekek, amit meg kezzel kell beletenned, azok meg baromi egyszeruek. Pl libbz2 teszteles:

AC_CHECK_HEADERS(bzlib.h)
AC_CHECK_LIB(bz2,BZ2_bzlibVersion)
AC_CHECK_LIB(bz2,BZ2_bzBuffToBuffCompress)
AC_CHECK_LIB(bz2,BZ2_bzBuffToBuffDecompress)

if  test "x$ac_cv_header_bzlib_h" = "xyes" && \
    test "x$ac_cv_lib_bz2_BZ2_bzlibVersion" = "xyes" && \
    test "x$ac_cv_lib_bz2_BZ2_bzBuffToBuffCompress" = "xyes" && \
    test "x$ac_cv_lib_bz2_BZ2_bzBuffToBuffDecompress" = "xyes" ; then
        X_CFLAGS="${X_CFLAGS} -DENABLE_BZ2"
        X_LIBS="${X_LIBS} -lbz2"
fi

A.

Hozzáférek egy Sun T5220-hoz (NiagaraII, 8 mag, magonként 8 thread), ha érdekel dobj privátba egy mail-t, hogy konkrétan milyen tesztet futassak. (Solaris van rajta, és marad is.)

Mindenkinek köszönöm a segítséget és a konstruktív hozzászólásokat!

Néhányotoknak név szerint is: tesztriportot küldött Bartos-Elekes Zsolt (report_x86_linux_2.txt) és Csatlós Imre (report_sparc_solaris_2.txt), Kövesdán Gábor pedig elkészítette a FreeBSD port-ot. Ha nem bánjátok, belekerültök a README-be és a manual-ba. (Következő kiadás majd valamikor lesz :))

Nagyon pozitív élmény volt!

Szia! Megnéztem a kicsikét a FreeBSD-port után. Nyilván sem a gép, sem a tesztadat nm megfelelő, de mind egy-egyprocesszoros/egmagos, mind egy kétmagos gépen egy aprócska 30M-s fájlon pont ugyanazt produkálta, mint a bzip2 (1.0.5) és a pbzip2 (szintén 1.0.5). Mekkora tesztadaton (és mekkora gépen) kéne érzékelhető nyereséget elkönyvelnem az lbzip2-vel?

Méretben nagyjából ugyanakkorát kell kapnod, mint a másik két említett programmal (azokat -9 módban futtatva). A gyorsulásnak erős korlátja, hogy a processzormagjaid mekkora dedikált (adat)cache-sel rendelkeznek (nyilván L2-ről beszélünk, vagy annál nagyobb méretűről). Ha nincs dedikált cache-e minden egyes magnak, és a közös cache (ha van ilyen) sem elég nagy, akkor nem nagyon fog gyorsulni.

Mivel a pbzip2 és az lbzip2 teljes mértékben függetlenek egymástól, viszont a rendszereden egyik sem tömörített a standard bzip2-nél gyorsabban, azért valahol mélyebben van a szűk keresztmetszet.

Egy egyszerű ellenőrzésnek ezt javaslom:

cat bigfile >/dev/null
time bzip2 <bigfile >/dev/null
time sh -c 'bzip2 <bigfile & bzip2 <bigfile & wait' >/dev/null

Ha a második time ideje lényegesen nagyobb (mondjuk duplája) az első idejének (a real-t nézd), akkor a rendszeren nincs miért pbzip2-t ill. lbzip2-t használni. A teszt alatt természetesen ne terheld mással a gépet.