Vlákno názorů k článku Co umí souborový systém ZFS od Messa - Jdou data ukládat na disky redundantně? Když se...
-
su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)"Ještě by mě zajímalo, když jsou všechny nebo alespoň většina informací 128bitových, neklade to o dost větší nároky na CPU?"
To si myslim osetri prekladac: na 32-bit architekture bude aj tak vacsina cisiel (snad okrem velkosti suborov) malych, teda staci napr. jednoduche scitanie jednou instrukciou ALU, resp. je mozne pouzit FPU na velke cisla (tusim na x86 je max. 80-bit integer), ale to sa mi zda je pomalsie.
nieco v zmysle:
ADD EAX,EBX
JNC bolo_male_cislo_ziadne_pretecenie_pokracujeme
ADC ECX,EDX
label bolo_male_cislo_ziadne_pretecenie_pokracujeme
call nejaka_pekna_funkcia -
su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)Uz pravdupovediac neviem, ako je to na x86/AMD64 atd. s branch penalties. Pri prichode Pentia a neskor MMX instrukcii ma to uz prestalo bavit. Nicmene, CMOV na x86 je a je to prave instrukcia, ktora na 'salamovych klonoch x86' ako VIA C3 sposobuje dost velky bordel (VIA C3 ju nepodporuje, haltne preventivne CPU). Jedina zaujimava vec, co som ohladne asm v poslednej dobe videl, je IOMMU.
-
su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)Ako by to teda bolo najrychlejsie na i686, ak predpokladame, ze vacsinou sa budu scitat 32-bitove cisla bez pretecenia? A v 1% pripadov s pretecenim do 64-bit? (samozrejme zalezi, ci scitame registre alebo pamat)
Ak sa dobre pamatam, v i686 boli nejake "double" instrukcie, ktore scitavali po 64bitoch. A v nejakom rozsireni ako MMX/SSE[2]?
Ak spravne predpokladam, tak gcc niektore z tychto optimalizacii robi, hoci AFAIK je tam dost miesta na zlepsenie. -
su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)Ide o scitanie 128-bit integerov (este predpoklad: pretecenie do 3. 32-bit slova nastava s 0,1% pravdep. a najvyssieho 32-bit slova nastava trebars s 0,01% pravdep., v podstate na tie pravdep. mozte kaslat, islo o to, ako by to fungovalo "beznom pripade", kde sa cisla vacsie nez 32-bit vyskytuju typicky vo velkosti suborov).
-
su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)Tak aby sme si rozumeli: ak je aj najvyssich 12 bytov oboch scitanych cisel nenulovych, ale pri scitani ziadnych 32-bit podslov to nepretece, tak staci scitat po 32-bit slovach, ak to nepretece. Uz vidim, ze som tam napisal hore trocha blbost, ale myslel som toto ;-). Prave v case 80286/80386 sa na tieto triky pouzivalo LEA, ADD/ADC ale zase aby som netvrdil blbosti, tak si to uz moc dobre nepamatam.
Otazka stale znie: ako najlepsie by mal kompilator zoptimalizovat scitanie dvoch 128-bitovych cisel na 32-bit arch? Samozrejme, kompilator nemoze vediet, ze vacsinou budete scitat cisla kde a+b < 2^32 v 99% pripadoch, ale ako by to najlepsie zoptimalizoval clovek?
Resp. ak predpokladame, ze vsetky 128-bit cisla nastavaju s rovnakou uniformnou pravdepodobnostou (co je jedina vec, co moze kompilator predpokladat), aky by mal "najlepsi" vysledok na i686/MMX/SSE[2]? -
Mikuláš Patočka (neregistrovaný)Kompilátor by nejlépe udělal, kdyby si to profilerem zjistil, jak často jsou ta čísla menší/větší než 2^32, 2^64, 2^96 a pak vygeneroval buď toto (v případě, že je výsledek většinou < 2^32):
ADD EAX, [cislo]
JC preteceni1
ADD EBX, [cislo + 4]
JC preteceni2
ADD ECX, [cislo + 8]
JC preteceni3
ADD EDX, [cislo + 12]
zpatky:
...
preteceni1:
ADC EBX, [cislo + 4]
preteceni2:
ADC ECX, [cislo + 8]
preteceni3:
ADC EDX, [cislo + 12]
JMP zpatky
nebo pouze toto (v případě, že k přetečením docházívá)
ADD EAX, [cislo]
ADC EBX, [cislo + 4]
ADC ECX, [cislo + 8]
ADC EDX, [cislo + 12]
... nebo může vygenerovat nějakou kombinaci těchto dvou postupů, když je výsledek mezi 2^32 a 2^64 nebo mezi 2^64 a 2^96.
=========
Jak by to měl programovat člověk? --- tak, že si daný typ deklaruje jako makro preprocesoru, výsledný soubor 4x přeloží pro velikosti typu 32, 64, 96 a 128 bitů a při běhu se použije ta verze, která odpovídá velikosti právě namountovaného filesystému. --- i když se zbavíme těch ADC, jak je popsáno výše, tak stále je tu problém ten, že jeden integer pak žere 4 registry, když to několikrát přeložíme, budeme mít i optimální využití registrů. -
su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)Diky.
Posledna otazka: tuto (http://www.root.cz/clanky/co-umi-souborovy-system-zfs/nazory/103563/) mi niekto tvrdi, ze podmieneny jump ma cenu 2-4 ADDov. Je to pravda alebo blbost? Pretoze v tom pripade by 4 ADD/ADC vychadzali zhruba rovnako ako pouzitie JC/JNC. Mam knihu o x86-asm v krabici pod stolom, ale je uz hodne out-dated (posledne Pentium a zmienka o MMX), co tvrdim je to co si pamatam.
Ad profiler: jasne, ale v pripade kompilovanych programov (napr. Gentoo) sa profiler ani nedostane k slovu, alebo?
"Jak by to měl programovat člověk? --- tak, že si daný typ deklaruje jako makro preprocesoru," -- to ale samozrejme zavisi ako to prekladac zoptimalizuje (pri 32-bit je to jasne, skor pri tych ostatnych to celkom nevidim). -
Mikuláš Patočka (neregistrovaný)Pokud je ten podmíněný skok správně předpovězen, tak je za 1/3 tiku (sežere jednu ze 3 mikroinstrukcí, co procesor může vykonat, a žádné další mikroinstrukce na něm nezávisí). Pokud je špatně předpovězen, tak jeho cena je rovná délce pipeliny --- t.j. 30 tiků na Pentiu4 Prescott, 20 tiků na předchozím Pentiu4, míň na AMD a Pentiu M / Core.
Na zmíněném Pentiu 1 byla délka pipeliny 5 tiků a na Pentiu-MMX 6 tiků --- takže špatně předpovězený skok trval tolik, správně předpovězený skok byl za 1/2 tiku.
Když se program neprofiluje, jak těžko říct, jak to kompilovat. Nejlepší je asi si spoustu programů zprofilovat a snažit se to z toho uhodnout i pro neprofilované programy.
Při 64-bitových operacích kompilátor generovat kód umí (i když GCC ho někdy generuje dost blbě, např. konstrukce 64bit_cislo>>32). Pro 96-bitové a 128-bitové neumí --- tam si to člověk musí sám napsat pomocí inline assembleru. -
Mikuláš Patočka (neregistrovaný)Na Intel Pentium 4 je to rozumné (pokud je výsledek sčítání většinou menší než 2^32), protože ADC je tam mikrokódované (asi 10 tiků), zatímco správně předpovězený podmíněný skok je pouze 1/3 tiku. Na AMD se klidně může použít ADC, protože je stejně rychlý jako ADD.
Pokud čísla budou často větší než 2^32, tak je lepší používat ADC, protože penalta za špatně předpovězený skok je 30-40 tiků, což je mnohem méně než trvání ADC. -
Tomas Dzik (neregistrovaný)Jak uz nekdo poznamenal nize, ZFS v sobe kombinuje vlastnosti softwaroveho volume manageru a filesystemu. Takze samozrejme podporuje i redundanci. Na Solarisu 10 podporuje mirroring a RAID Z.
Mirroring ovsem nefunguje uplne presne tak, jak jsme zvykli z volume manageru, protoze se nemirroruji bloky disku. Misto toho mohou byt v metadatech souboru ulozene odkazy na vice kopii datovych bloku tvoricich soubor. Takze k dosazeni redundance staci, aby se pouzilo vice kopii techto datovych bloku a aby tyto datove bloky byly ulozeny na ruznych discich. Takze je to vlastne mirroring na urovni filesystemu.
RAID Z je format velmi podobny RAID 5, ale (na rozdil od RAID 5) mu nevadi vypadek proudu pri zapisu (coz je duvod, proc diskova pole s RAID 5 musi byt zalohovana baterkou).
Krome toho se pracovalo i na formatu, ktery umozni prezit bez ztraty dat vypadek libovolnych 2 disku v poolu, ten ale zatim neni v Solarisu 10. (Nevim, jak je na tom v soucasne dobe OpenSolaris.) -
Je v OpenSolarisu od buildu 48 (IIRC). Nexenta-unstable uz RAID-Z2 ma. Mimochodem i rozkladani zataze rovnomerne na vsechny disky funguje docela hezky (zpool iostat -vpri praci s mysql databazi):capacity operations bandwidth pool used avail read write read write mypool2 6.04G 33.7G 12 145 1.54M 14.8M raidz2 6.04G 33.7G 12 145 1.54M 14.8M c2t3d0 - - 7 135 305K 4.95M c2t4d0 - - 7 133 314K 4.94M c2t5d0 - - 7 133 322K 4.95M c2t6d0 - - 7 134 322K 4.95M c2t8d0 - - 7 135 313K 4.95M ---------- ----- ----- ----- ----- ----- -----Jak je videt, mypool2 je vytvoren jako raidz2. V NexentaOS Alpha5 jeste zpool raidz2 vytvorit neumel.
