fir <f...@W...gazeta.pl> napisał(a):

> (po tej taniej koli (cola marki cola dwa litry za 1zl)
> co to ostatnio pije czuje sie jakos dziwnie)
>
> chyba najfajniej o paralelizowaniu mozna pomyslec na
> konkretnych przykladach (a nie mam tych przykladow za
> wiele - umialby ktos podac jakies dobrze okreslone
> uklady do sparalelizowania?) Podstawowym przykladem
> ktory do mnie powraca jest przyklad wioski - 'wioska'
> nazywam dla uproszczenia program (w c na pc)
> skladajacy sie z postaci chodzacych po dwuwymiarowej
> mapie (na ktorej poza postaciami moga byc jeszcze ew
> jakies przeszkody, domki czy drzewka)
>
> chodzi mi o postawienie kwestii czy wioske da sie
> sparalelizowac ladnie w mtb (multithreadingu
> bezkolizyjnym zob definicja w poscie 'mt - nazewnictwo')
>
> jak ktos z grupowiczow zabieralby sie do parelelizowania
> wioski?
>

realnie to poza samym wielkim movem (calej grupy)
to jest tam jeszcze grupowy draw a pozatym u mnie
przynajmniej jeszcze sam blit - i to ew mozna
by probowac rownoleglic

1. grupovy move //powiedzmy 20 ms (20 to sporo oczywiscie)
2. grupowy draw // nie wiem niestety ile ale powiedzmy 5 ms
3. blit // [pwoedzmy 3 ms

nie wiem ile zajmuje u mnie sumaryczny draw bo drawy sa
u mnie splecione z movami na poziomie pojedynczej jednostki

bigdrawa z blitem mozna oczywiscie bezkolizyjnie
rozbijac chocby i na tysiac kawalkow (tak sie przynajminej
mi wydaje), z tym ze jesli mialoby to byc jeszcze
paralelizowane z bigmovem to zeby nie bylo 'strzepienia'
(drawy tylko czytaja stan sceny i zmiany danych pod
drawem nie owocowaly by krytycznymi bledami ale ew
krotkotrwalymi bledami w obrazie)
trzebaby robic jakis doublebuffor dla samych movow -
a to jest mocno burdensome (dirty kode) - no ale costam
mozna zrobic (powiedzmy ze sciac paralelizacja caly
drawing do 1 ms)

pozostaje jeszcze 20 milisekundowy bigmove
ktorego trudno zrownoleglic ale warto pomyslec

(prof fir)



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/