16 sept. 2013

lrz(ip)tar

lrzip/lrztar e un programel dezvoltat de cel ce face patch-urile -ck pentru nucleul Linux.
lrzip/tar este un "arhivator" destul de puternic si principalul atu al lui este compresia LZO si multi-threading-ul.

Asa ca m-am hotarat sa comprim acelasi folder, dar cu un numar diferit de thread-uri pentru a vedea cate thread-uri produc o arhiva in cel mai scurt timp.

Procedeul testarii/unelte:
- un procesor cu 4 nuclee si 4 fire de executie.
- un kernel custom (cu linux-3.11-ck/bfs,bld,uksm)
- un kernel stock (linux-3.11) dintr-o oarecare distributie (ArchLinux)
- un folder irelevant ca marime (124.3MB) sau ca continut (folderul se cheama "desk" si e genul ala de folder unde salvati chestii pe Desktop)
- un cronometru (utilitarul time din zsh, plus output-ul lui lrztar)

Comenzile folosite:

lrztar -L 9 -T -f -z -vv -o lr.zip Desktop/desk (autodetectie)
lrztar -L 9 -T -f -z -p 1 -vv -o lr.zip Desktop/desk (1 thread)
lrztar -L 9 -T -f -z -p 3 -vv -o lr.zip Desktop/desk (3 thread-uri)
lrztar -L 9 -T -f -z -p 4 -vv -o lr.zip Desktop/desk (4 thread-uri)
lrztar -L 9 -T -f -z -p 5 -vv -o lr.zip Desktop/desk (5 thread-uri)
lrztar -L 9 -T -f -z -p 8 -vv -o lr.zip Desktop/desk (8 thread-uri)
lrztar -L 9 -T -f -z -p 16 -vv -o lr.zip Desktop/desk (16 thread-uri)
Bun. Acuma intrebarea evidenta e: de ce asa multe thread-uri si de ce peste numarul de procesoare?
In primul rand, am rulat prima data programul fara vreun switch pentru fortarea numarului de thread-uri. Am vazut ca programul foloseste de fapt T+1, unde acel 1 vine de la thread-ul de asamblare a arhivei. Asadar, desi sunt 4 procesoare, vor exista de fapt 5 thread-uri, 4 lucrand la arhivare, al 5-lea la asamblarea finala a arhivei.

Deci, astea fiind spuse, avem mai multe combinatii interesante:
-p 1 unde am vrut simularea unui singur fir de executie
-p 3 unde lucreaza 3 nuclee la compresie si unul la formarea arhivei neasteptand dupa restul
-p 4 unde toate cele 4 nuclee lucreaza la compresie si thread-ul 5 asteapta timp liber pe unul  din nucleele foloste
-p 5 echivalentul lui make -j (numarul_nucleelor/firelor_de_executie+1). CK nu recomanda formula asta, spunand ca patch-urile lui se descurca mai bine cu numarul real de nuclee/fire de executie din procesor. Oare?
-p 8 cu 8 thread-uri, dublul fata de cate nuclee/fire de executie avem disponibile pe procesorul meu
-p 16 care de fapt se duce intr-un make -j11, si are 11 thread-uri ce lucreaza la comprimare + 1 de finalizare a arhivei, deci in total 12. Tot ce e peste 11 nu mai functioneaza, in sensul ca se va comporta ca si cum ai avea switch-ul -p 11.

Disclaimer: nu e un test -ck vs stock. Rezultatele sunt mai bune cu mai multe thread-uri pe stock, dar responsivitatea cam lasa de dorit. Daca rulez -p 16 (adica 11) pe stock si pe ck, ck-ul se simte altfel, nu are lag, nu are miscrostutter. Bine, nici stock-ul nu se misca asa de rau sau asa de greu incat sa zic ca nu se poate folosi, dar se simte ca ceva ruleaza in background, in schimb cu ck nu simti asta.

Bun. Astea fiind spuse, hai sa vedem. O sa grupez rezultatele in functie de kernel si numarul de thread-uri.

Kernelul stock.

-p 1
timp total: 5min 7sec = 307sec.
Timp de referinta = 307sec.
-p 3
timp total: 2min 29sec = 152sec
Imbunatatire 201.97% (-50.48%)


-p 4
timp total: 1min 59sec = 119sec
Imbunatatire: 257.98% (-61.23%)


-p 5
timp total: 1min 48sec = 108sec
Imbunatatire: 284.25% (-64.82%)


-p 8
timp total: 1min 51sec = 111sec
Imbunatatire: 276.57% (-63.84%)


Am putea sa zicem ca deja e prea mult sa avem 8 thread-uri, dar -p 16 ne face o surpriza:
timp total: 1min 39sec = 99sec
Imbunatatire: 310.10% (-67.75%)
Asta inseamna de 3 ori mai repede ca un singur thread!


Si in final, autodetectia care vede 4 nuclee si ruleaza 4 thread-uri cum ar fi normal:
timp total: 1min 59sec = 119sec
Imbunatatire: 257.98% (-61.23%)
Adica exact ca si cu -p 4. (Logic)



Kernel custom

-p 1
timp total: 5min 13 sec = 313sec
Timp de referinta: 313sec.


-p 3
timp total: 2min 32sec = 152sec
Imbunatatire: 205.92% (-51.43%)
De 2 ori mai rapid.


-p 4
timp total: 2min 2sec = 122sec
Imbunatatire: 256.55% (-61.02%)
Comparand cu stock-ul, momentan ne aflam pe la aceeasi imbunatatire a timpului.


-p 5 sau ceea ce ck ne spune sa nu facem.
timp total: 1min 53sec = 113sec
Imbunatatire: 276.99% (-63.89%)
Suntem aproape de -p 8-ul din stock.


-p 8 Aici deja nu mai are sens. 8 thread-uri sunt overkill si nu aduc o crestere de performanta.
timp total: 1min 52sec = 112sec
Imbunatatire: 279.46% (-63.89%)


-p 16 nu aduce nici el o diferenta prea mare.
timp total: 1min 50sec = 110sec
Imbunatatire: 284.54% (-64.85%)

Si in final, autodetectia (4 thread-uri)
timp total: 2min 2sec = 122sec
Imbunatatire: 256.55% (-61.02%)
Adica exact ca -p 4 (logic)




Kernel stockp1p3p4p5p8p16auto
timp total (s)307s152s119s108s111s99s119s
Imbunatatire0%201.97%257.98%284.25%276.57%310.10%257.98%



Kernel customp1p3p4p5p8p16auto
timp total (s)313s152s122s113s112s110s122s
Imbunatatire0%205.92%256.55%276.99%279.46%284.54%256.55%



KS/KCp1p3p4p5p8p16auto
Diferenta ks/kc (s)+4s0+3s+5s+1s+11s+3s
Diferenta timp ks/kc(%)+1.95%0%+2.52%+4.62%+0.90%+11.11%+2.52%

Primul tabel se citeste: p3 merge de doua ori mai repede ca p1, p4 merge de doua ori jumate mai repede ca p1, p16 merge de 3 ori mai repede ca p1.
Al doilea la fel.
Al treilea se citeste: cu cat la suta e mai lent un p1 pe ck ca un p1 pe stock, etc.

Putem astfel concluziona:
-kernelul -ck este mai lent cu o medie de 4s (nu am luat in calcul testul cu autodetectia)
-diferentele de timp intre thread-uri sunt destul de mici pe kernelul stock vs kernelul custom, dar sunt aproximativ aceleasi intre numarul de thread-uri folosite. Adica referitor la scalabilitate, rezultatele sunt aproximativ aceleasi:

p1-p3,stock = 155s
p1-p3,custom = 161s
p3-p4,stock = 33s
p3-p4,custom = 30s
p4-p5,stock = 11s
p4-p5,custom = 9s
p5-p8,stock = -3s
p5-p8,custom = 1s
p8-p16,stock = 12s (s-a intamplat ceva aici)
p8-p16,custom = 2s

Crescand numarul de thread-uri observam, evident, o micsorare a timpului de compresie, dar diferentele intre -p4, -p5, -p8 si -p16 nu sunt asa de mari, nici pe kernel stock, nici pe custom. Exceptie face -p 16 pe kernelul stock. In orice caz, nu se (mai) vad diferente atat de palpabile pe niciun kernel dupa depasirea numarului de nuclee/fire de executie ale procesorului.
Urmeaza un tabel mai elaborat, imediat dupa ce ma prind cum as putea pune in valoare toate datele :))