du2

[Necroman]

Dotazek, co pouzivate za prostredky z TBB k realizaci druheho ukolu? Laka me to k vyuziti jen parallel_for, ale urcite by to melo jit i nejak elegantneji.

Take otazka, nevite o nejakych dobrych manualech na priklady pouziti TBB? Teorie a co to umi je sice fajn, ale je dobre to videt i nekde v praxi.

A jeste, narazil jsem na problem, kdyz se pokousim poustet program, ktery pouziva TBB, na jinem stroji, nez je parlab. Dostavam chybu
./du2: error while loading shared libraries: libtbb.so:
Hadam, ze se jedna o chybu nemoznosti dynamicky nalinkovat TBB knihovnu. Napada me jako reseni ji nalinkovat staticky, coz ale asi nebude prilis ciste reseni. Mate podobne problemy a pokud ano, jak je resite?

[_mffcore_]

Ja zatim nevidim nejaky podstatny problem s parallel_for. Ale velky potencial vidim porad ve zrychleni serivoeho vypoctu ... MKL spocte HUGE za neco pres 100 sekund - tedy asi 10 rychleji nez referencni verze. Pri namixovani zrychleni paralelizace a zrychleni seriveho vypoctu by na prvni pohled nemel byt problem dosahnout pozadovaneho zrychleni. Praxe ale asi bude jina.

O nejaky prikladech/manualech (krome dokumentace od Intelu) nevim.

S tou knihovnou ... ona na ostatnich strojich asi neni, protoze tam patrne nebude TBB nainstalovany. Mozna by ji stacilo zkopirovat do adresare se binarkou (Windows hleda DLLko v adresari s binarkou - zda Linux, to nevim). Staticke slinkovani by melo byt take reseni a nic necisteho na tom pro tento ucel nevidim.

[Necroman]

Vcera jsem si s tim trochu hral a po prepsani verze z pthredu do TBB, dost primocare, to pocita skoro stejne rychle, jako pthready, tj 7+ zrychleni..
U mkl je asi ten problem, ze to je optimalni verze, ktera byla predpokladam tvorena s ohledy na prakticky vsechny vlastnosti procesoru, pameti, sbernice, pristupu na disk. Bez pokrocilych znalosti assembleru a ruznych SSE instrukci podle me neni mozne se mkl ani priblizit. Uz jen pohled na to, ze moje prumerna binarka ma cca 10 KB a mkl asi 1.5 MB, to bude neco znamenat...

Ale jak rikas, hlavni moznosti optimalizace jsou prave u seriove verze. U TBB se toho uz moc vymyslet neda, maximalne zkusit vnorit parallel_reduce do parallel_for, pohrat si s grainsize ci pouzit partitioner, nebo pouziti memory alokatoru, co poskytuje TBB.

update, zoptimalizoval jsem nacitani dat ze souboru tak, ze nejdriv nactu matici b a az v pameti ji transponuju, a momentalne moje TBB verze zpracuje s nacachovanymi daty large matice za 10.5 vteriny, huge za cca 120 vterin.

[Necroman]

Jen dalsi poznatek, jak zrychlit cely proces: zkuste paralelizovat i operaci transponovani matice b!
Na large jsem tim zkratil cely prubeh programu cca o vterinu a na huge o cca 10 vterin. Neni to moc, ale je to znat.

A jeste prikaldam maly testik v bashi, ktery vam umozni otestovat netradicni rozmery matic... pokud pouzivate ruzne pocitani po blocich pevne velikosti, muze vas prekvapit, ze s maticemi lichych rozmeru si vas program neporadi:

Kód: Vybrat vše

#!/bin/bash
echo "this is a test for odd matrix input"
echo "generating matrices"
./generator 512 512 1 test0.a
./generator 512 512 2 test0.b

./generator 511 512 1 test1.a
./generator 512 512 2 test1.b

./generator 512 511 1 test2.a
./generator 511 512 2 test2.b

./generator 511 511 1 test3.a
./generator 511 512 2 test3.b

./generator 512 512 1 test4.a
./generator 512 511 2 test4.b

./generator 511 512 1 test5.a
./generator 512 511 2 test5.b

./generator 512 511 1 test6.a
./generator 511 511 2 test6.b

./generator 511 511 1 test7.a
./generator 511 511 2 test7.b

echo "running test"
X=0
while [ $X -le 7 ]
do
   echo $X
   ./mkl test$X.[ab] test$X.c
   ./du2 test$X.[ab] test$X.c2
   ./comparator test$X.c test$X.c2
   X=$((X+1))
done

[Návštěvník]

... Uz jen pohled na to, ze moje prumerna binarka ma cca 10 KB a mkl asi 1.5 MB, to bude neco znamenat...

Napriklad to, ze se ta binarka mkl kompiluje jako -static, takze je u toho mimo jine pribalena uplne cela MKL knihovna.

[weetya]

Jen dalsi poznatek, jak zrychlit cely proces: zkuste paralelizovat i operaci transponovani matice b!
Na large jsem tim zkratil cely prubeh programu cca o vterinu a na huge o cca 10 vterin. Neni to moc, ale je to znat.

Ja to pocitam tou tvoji metodou s rozdelenim na male bloky. Paralelni transpozice mi pomohla dost na medium a large matici (cca 30% zrychleni), ale u huge mi vychazi lepe matici b vubec netransponovat.

Co pouzivate za funkce z TBB? Ja zatim pouze parallel_for. Nepekne rozhrani cache_aligned_allocatoru se mi zatim nepovedlo zprovoznit.

[Necroman]

Ja to pocitam tou tvoji metodou s rozdelenim na male bloky. Paralelni transpozice mi pomohla dost na medium a large matici (cca 30% zrychleni), ale u huge mi vychazi lepe matici b vubec netransponovat.

Co pouzivate za funkce z TBB? Ja zatim pouze parallel_for. Nepekne rozhrani cache_aligned_allocatoru se mi zatim nepovedlo zprovoznit.

Jeste takova poznamecka, sice to nasobeni delim na bloky, ale samotne tasky tvorim pouze delenim matice a na skupiny radku. Bcko nijak nedelim.
Chce to trochu experimentovat, jak s velikostmi podbloku, tak s grainem, transpozici a pak pouzit nejlepsi metodu

Z TBB nakonec pouzivam jen parallel_for, momentalne mi to pocita large tesne pod 10 vterin a huge za 110.

[weetya]

Jeste takova poznamecka, sice to nasobeni delim na bloky, ale samotne tasky tvorim pouze delenim matice a na skupiny radku. Bcko nijak nedelim.
Chce to trochu experimentovat, jak s velikostmi podbloku, tak s grainem, transpozici a pak pouzit nejlepsi metodu

Z TBB nakonec pouzivam jen parallel_for, momentalne mi to pocita large tesne pod 10 vterin a huge za 110.

Ja to delam taky nejak takhle. Cas mam O(Necroman)
Neboli ~14, ~170.

[weetya]

Jen poznamka:
Ted jsem narazil na TBB implementaci Strassena v ty knize "Intel Threading Building Blocks", co nam o ni rikali na prednasce, ze je spatna.

Kdyby si s tim chtel nekdo pohrat...

[Kate]

mohla by sem nejaka dobra duse prosim napsat, jak prelozit icc ten ukol, aby to bezelo i na workerech, kde tbb neni?

[jonny]

To asi bohuzel nepujde. TBB neumoznuje staticke linkovani