środa, 6 stycznia 2021 o 16:29:44 UTC+1 fir napisał(a):
> środa, 6 stycznia 2021 o 16:06:52 UTC+1 heby napisał(a):
> > On 06/01/2021 15:41, fir wrote:
> > > ze mozna synchronizowac watki nawet bez atomikow
> > W ogómym przypadku to nie jest skuteczne. W przypadku architektury x86
> > może być czasem możliwe.
> >
> > W bardzo ogólnym wypadku wymagany jest choć fence, który trzeba jawnie
> > uzyć w kodzie programu. Taki mechanizm w CPU który zapewnia
> > synchronizację dostępu do pamięci między różnymi rdzeniami i cache.
> >
> > Tak więc ogólnie rzecz biorąc nie da się zrobić sensownej synchronizacji
> > tylko na spilockach bo to zależy na czym to ma pracować. Zwyczajowo w
> > świecie wielordzeniowym trzeba się badziej postarać niż while(!flag) { }.
> while z pust apetla bym nei uzyl ale ze sleepem 2-3 milisekundy nie wydaje mi sie
juz tak glupie..ogolne programowanie tez mnie nie kreci bo ogolne programowanie to
zle porogramowanie bo w ogolnosci nie dziala optymalnie na specyficznych maszynach ;c

>
> schemat btw raczej jaki wymodzilem byl raczej taki
>
> int ready = 0;
> do
> {
> while(current<ready) { sleep(2); }
> do_work();
> ready++;
> } whie(1);
>
> cos w tym stylu, robota dzielona na porcje numerowane liczba naturalna, current
zaczyna sie od -1,
> boczne watki czekaja na sleepach; glowny thread robi current++ do 0 wati ruszaja az
ustawia ready na 1
> glowny watek sprawdza czy wszystkie maja ready wieksze niz current jesli tak
popycha current itd
>
> w moim przekonaniu to raczej chyba powinno dzialac

przez powinno mam na mysli ze odpalilem to i dzialalo (ale nie ejestem pewien czy
nei przegapilem jakichs wzglednych subtelnosci), current to oczywoscie odpowiada
numerowi ramki obrazu w symulacji ktora dzialac ma na okolo 50-120 fps na jednym
watku zajmowala ok 30 ms na ramke wiec w optymalnym podziale roboty powinno wyjsc po
15 ms na rdzen na dwurdzeniaku... nie mierzylem czasu tylko patrzylem na oko czy jest
szybciej i wylogowalem tez stany tych ready i current do loga textowego i na oko
wygladalo ok

aczkolwiek zawsze jak ktos wie co tu sie moze realnie chcrzaic to wiedza o detalach
mile widziana

(fir)

do góry

On Wednesday, January 6, 2021 at 4:38:15 PM UTC+1, fir wrote:
> środa, 6 stycznia 2021 o 16:29:44 UTC+1 fir napisał(a):
> > środa, 6 stycznia 2021 o 16:06:52 UTC+1 heby napisał(a):
> > > On 06/01/2021 15:41, fir wrote:
> > > > ze mozna synchronizowac watki nawet bez atomikow
> > > W ogómym przypadku to nie jest skuteczne. W przypadku architektury x86
> > > może być czasem możliwe.
> > >
> > > W bardzo ogólnym wypadku wymagany jest choć fence, który trzeba jawnie
> > > uzyć w kodzie programu. Taki mechanizm w CPU który zapewnia
> > > synchronizację dostępu do pamięci między różnymi rdzeniami i cache.
> > >
> > > Tak więc ogólnie rzecz biorąc nie da się zrobić sensownej synchronizacji
> > > tylko na spilockach bo to zależy na czym to ma pracować. Zwyczajowo w
> > > świecie wielordzeniowym trzeba się badziej postarać niż while(!flag) { }.
> > while z pust apetla bym nei uzyl ale ze sleepem 2-3 milisekundy nie wydaje mi sie
juz tak glupie..ogolne programowanie tez mnie nie kreci bo ogolne programowanie to
zle porogramowanie bo w ogolnosci nie dziala optymalnie na specyficznych maszynach ;c

> >
> > schemat btw raczej jaki wymodzilem byl raczej taki
> >
> > int ready = 0;
> > do
> > {
> > while(current<ready) { sleep(2); }
> > do_work();
> > ready++;
> > } whie(1);
> >
> > cos w tym stylu, robota dzielona na porcje numerowane liczba naturalna, current
zaczyna sie od -1,
> > boczne watki czekaja na sleepach; glowny thread robi current++ do 0 wati ruszaja
az ustawia ready na 1
> > glowny watek sprawdza czy wszystkie maja ready wieksze niz current jesli tak
popycha current itd
> >
> > w moim przekonaniu to raczej chyba powinno dzialac
> przez powinno mam na mysli ze odpalilem to i dzialalo (ale nie ejestem pewien czy
nei przegapilem jakichs wzglednych subtelnosci), current to oczywoscie odpowiada
numerowi ramki obrazu w symulacji ktora dzialac ma na okolo 50-120 fps na jednym
watku zajmowala ok 30 ms na ramke wiec w optymalnym podziale roboty powinno wyjsc po
15 ms na rdzen na dwurdzeniaku... nie mierzylem czasu tylko patrzylem na oko czy jest
szybciej i wylogowalem tez stany tych ready i current do loga textowego i na oko
wygladalo ok
>
> aczkolwiek zawsze jak ktos wie co tu sie moze realnie chcrzaic to wiedza o detalach
mile widziana
>
> (fir)

A jakby użyć OpenCL?

Pozdrawiam

do góry