64bit, write(), ...

 ( apal | 2007. április 7., szombat - 17:54 )

Hehe, ez vicces, ke't he't szivas utan a kovetkezo" konkluziora jutottam: a write() nevezetu" elegge alapszintu" fv 64bites architektura'n, (ahol a sizeof(size_t)==8) sem ke'pes egyszerre 2giga'nal nagyobb darabot kiirni. Diszkre.

Kerdes: le van ez irva valahol?!

Ez nagy szopa's volt, az biztos, az ember mindenhol keresi a hiba't csak itt nem... Gondolom megoztom a ko"zzel e felfedeze'st, ilyforma'n, egy forumbejegyz'est azert nem e'r meg...

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ő.

A libc dokumentacio (Large File Support extension (LFS)) a te baratod. Lasd _FILE_OFFSET_BITS, _LARGEFILE64_SOURCE makrokat.

Hm, erdekes, mert a _FILE_OFFSET_BITS-et hasznalom (=64, mert a proginak mukodnie kell 32bites arch-on is), a _LARGEFILE64_SOURCE-ra meg aszondja a libc doksi, hogy:

On systems where the natural file size limit is greater than 2GB (i.e., on 64 bit systems) the new functions are identical to the replaced functions.

Tehat 64bites archon alapbol mennie kene, eszerint. 64bites archon egyebkent a FILE_OFFSET_BITS is 64, alapbol (azaz sizeof(off_t)==8), azt nem is kene ekkor beallitani ke'zzel.

4111 byte tól nagyobb write is meglep nem, hogy 2 GB :)

Eltolás != méret.

32 kiB adatot sem árt tudni kiírni, mivelhogy a FAT16/32-n még gyakran lehetett ekkora blokkmérettel találkozni, ha nagy volt a partíció.

több, mint 2GiB írása === több, mint 2 GiB memóriában tartása. Azért megfontolandó.

több, mint 2GiB írása === több, mint 2 GiB memóriában tartása. Azért megfontolandó.
A problema, amihez ez kell, az gyk nagymennyisegu adat transzponalasa. Adott egy ~100k x ~20k-s matrix, transzponald. Van vas, 8-16giga rammal, de meg az is keves (abba sem fer el a teljes adatmennyiseg). Es ez tipikusan az a problema, hogy baromi sok idot vesztesz azaltal, hogy olvasod-irod-olvasod-irod az adatot ugy hogy kozben relative keves adatot tarolsz memoriaban. Tehat, minel tobb adat van bent, annal (sokkal) jobb. Raadasul a transzponalas utan a matrixot me'g rendezni is kell, de ez mar egy masik mese (ahhoz erdekes modon nem kell sok memoria).

Tegyük fel, hogy van elég memória. Akkoris miért kell _egyben_ kiírni? Az OS úgyis kisebb blokkméretet használ.

Ha nincs elég memória, akkor marad a sok-sok IO művelet, ezt nem lehet kikerülni, max. a rendelkezésre álló memória függvényében minimalizálni. A legtöbb idő az IO műveletekre fog elmenni. Ez van, nincs mit tenni, ha nincs elég memória.

Tegyük fel, hogy van elég memória. Akkoris miért kell _egyben_ kiírni?
Az adat sok esetben stdin-rol jon, ertelemszeruen fogalmunk sincs, mennyi. Naivak vagyunk, es feltetelezzuk hogy el fog ferni. Sok realloc(), majd egyszercsak nyekk, vagyis nem nyekk, elerunk egy maxmem limitet. Akkor mkstemp(), diszkre ki, free(), elorol kezd feltoteni. Es akkor ma'r, ha ki kell irni diszkre, a memoriaban ott van homogenen az adat, akkor ma'r miert ne write(), egy hivas, oszt le van tudva. Na, itt bukott el a dolog, hogy en naivan azt hittem, hogy write(file,adat,4giga), ez megy... szoval pusztan lustasag miatt irtam ki egyben ;] Most mar kisebb darabokban (16m, asszem) irja ki, igy persze jo.

Ez van, nincs mit tenni, ha nincs elég memória.
hat, nehez az elet...

Lehetne ezt repülő ékezet nélkül? Iszonyat zavaró, rosszabb, mintha nem is lenne.

Hm, meg lehet tanitani az X-et arra hogy az alt+a az a' legyen, az alt+m az i', stb? Az XTerm (debian alatt) alapertelmezesben ilyen, ezt mar sikerult megtanulni egeszen hatekonyan, de hogyha altalaban X alatt is menne ez a kombinacio, az nagyon franko lenne. Melyik file-ban kell turkalni? vagy van sajat file (/home/juzer/.x*, vagy hasonlo) ahol minden felhasznalo maganak beallithat ilyen egyedi kombinaciokat?

ocsem kuldi ezt a kis hekket (xmodmaphez, igaz ez a szamok helyere rakja az ekezeteseket, de ugy is mindenki numpadot hasznal ;) ):

keycode 10 = udoubleacute Udoubleacute exclam
keycode 11 = aacute Aacute at
keycode 12 = iacute Iacute numbersign
keycode 13 = odiaeresis Odiaeresis dollar
keycode 14 = question exclam percent
keycode 15 = uacute Uacute asciicircum
keycode 16 = odoubleacute Odoubleacute ampersand
keycode 17 = udiaeresis Udiaeresis asterisk
keycode 18 = eacute Eacute parenleft
keycode 19 = oacute Oacute parenright
keycode 29 = z Z
keycode 52 = y Y
keycode 113 = Mode_switch
keycode 79 = 7 KP_7
keycode 80 = 8 KP_8
keycode 81 = 9 KP_9
keycode 83 = 4 KP_4
keycode 84 = 5 KP_5
keycode 85 = 6 KP_6
keycode 87 = 1 KP_1
keycode 88 = 2 KP_2
keycode 89 = 3 KP_3
keycode 90 = 0 KP_0
keycode 91 = period KP_Decimal

--
The Internet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals.

Hm, mit kell beirni hogyha en azt szeretnem hogy alt+m az a hosszu i (iacute) legyen, es az alt+shift+m az a nagy hosszu I? Tudom, rtfm, de ha valaki kapasbol beirja, aki tudja, akkor az emberiseg netto cpu-idejebol kevesebbet vesztunk el, mintha en most keresne'm ;] (amit egyebkent kerestem is, de a `man xmodmap` es tarsai semmi informativat nem adtak errol, az persze kiderult, hogyha moricka letori a sun-billentyuzetrol a jobb altot, akkor mit kell tenni hogy a bal alttal is menjen, de ez nem erdekel...)