🚀 go-pugleaf

On 06/01/2021 12:54, fir wrote:
> czy jest normalnym podejsciem w kazdej ramce utworzyc watek

Nie. Wątki tworzy się na początku i zatrzymuje na synchronizacji, 
czekając na zadania.

Tworzenie wątków jest droższe niż czekanie na semaforze.

Wiele biblitek ma do tego gotowca, thread pool.

> kwestia jest taka ze chyab nie da sie stworzyc tych watkow przed cala petla gry i je poprostu ponawiac/wywolywac

Nie ma problemu z komunikacją międzywątkową. Zacznij od tego do czego 
służa semafory.

> ew inna opcją do rozwazenie jest odpalenie tych pobocznych watkow tak ze kazdy ma swoją petle z systemowym sleepem osobno i po flagach

Nie po flagach, tylko po prymitywach do synchronizacji. Condition, 
Semafor, Kolejka.

Lub wyższych koncpecji jak future/promise i thread pool.

środa, 6 stycznia 2021 o 14:31:59 UTC+1 heby napisał(a):
> On 06/01/2021 12:54, fir wrote: 
> > czy jest normalnym podejsciem w kazdej ramce utworzyc watek
> Nie. Wątki tworzy się na początku i zatrzymuje na synchronizacji, 
> czekając na zadania. 
> 
> Tworzenie wątków jest droższe niż czekanie na semaforze. 
> 
> Wiele biblitek ma do tego gotowca, thread pool.
> > kwestia jest taka ze chyab nie da sie stworzyc tych watkow przed cala petla gry i je poprostu ponawiac/wywolywac
> Nie ma problemu z komunikacją międzywątkową. Zacznij od tego do czego 
> służa semafory.
> > ew inna opcją do rozwazenie jest odpalenie tych pobocznych watkow tak ze kazdy ma swoją petle z systemowym sleepem osobno i po flagach
> Nie po flagach, tylko po prymitywach do synchronizacji. Condition, 
> Semafor, Kolejka. 
> 
> Lub wyższych koncpecji jak future/promise i thread pool.

 po flagach tez chyba powino dzialac...tyle ze byc moze w kombinacji ze sleepem 
ma to jakies minusy...sleep w windzie dziala ok z pobocznymi wątkami?

środa, 6 stycznia 2021 o 14:31:59 UTC+1 heby napisał(a):
> On 06/01/2021 12:54, fir wrote: 
> > czy jest normalnym podejsciem w kazdej ramce utworzyc watek
> Nie. Wątki tworzy się na początku i zatrzymuje na synchronizacji, 
> czekając na zadania. 
> 
> Tworzenie wątków jest droższe niż czekanie na semaforze. 
> 
> Wiele biblitek ma do tego gotowca, thread pool.
> > kwestia jest taka ze chyab nie da sie stworzyc tych watkow przed cala petla gry i je poprostu ponawiac/wywolywac
> Nie ma problemu z komunikacją międzywątkową. Zacznij od tego do czego 
> służa semafory.
> > ew inna opcją do rozwazenie jest odpalenie tych pobocznych watkow tak ze kazdy ma swoją petle z systemowym sleepem osobno i po flagach
> Nie po flagach, tylko po prymitywach do synchronizacji. Condition, 
> Semafor, Kolejka. 
> 
> Lub wyższych koncpecji jak future/promise i thread pool.

a jest wogole jakis w miare krotki ale dobry tutorial do tego ? najlpeiej cos co opisywaloby zadanie zblizone do tego co opisalem na poczatku (czyli kod liczacy co ramke ekran ktory chcialbym podzielic tak by odzielne watki liczyly odzielne kawalki)

gdy goglowalem za tym parenascie di temu nic sensownego sie w google nie pojawialo.w same te watki za gleboko nie che wchodzic bo jak na dzis nie przepadam za tym 'tematem'

On 06/01/2021 14:40, fir wrote:
>> Lub wyższych koncpecji jak future/promise i thread pool.
>   po flagach tez chyba powino dzialac...

Nie, ponieważ albo będzie się kręcił bez sleepa, przepalając energię, 
albo semafor będzie szybszy od sleepa.

W grę, z flagami, wchodzą też detale działania cache. Zmiana zmiennej w 
CPU1 nie powoduje natychmiastowej widzialnosci w CPU2. W niektóych 
architekturach nawet kolejnośc zmian pamięci jest nieokreślona jeśli 
obserwujemy ją z innego rdzenia.

> ma to jakies minusy...sleep w windzie dziala ok z pobocznymi wątkami?

Sleep to najgosze co można wybrać. Nie ma żadnej zalety, a same wady.

środa, 6 stycznia 2021 o 14:46:53 UTC+1 heby napisał(a):
> On 06/01/2021 14:40, fir wrote: 
> >> Lub wyższych koncpecji jak future/promise i thread pool. 
> > po flagach tez chyba powino dzialac...
> Nie, ponieważ albo będzie się kręcił bez sleepa, przepalając energię, 
> albo semafor będzie szybszy od sleepa. 
> 
> W grę, z flagami, wchodzą też detale działania cache. Zmiana zmiennej w 
> CPU1 nie powoduje natychmiastowej widzialnosci w CPU2. W niektóych 
> architekturach nawet kolejnośc zmian pamięci jest nieokreślona jeśli 
> obserwujemy ją z innego rdzenia.
> > ma to jakies minusy...sleep w windzie dziala ok z pobocznymi wątkami?
> Sleep to najgosze co można wybrać. Nie ma żadnej zalety, a same wady.



nie przecze ale chodzi tez o to by to zrozumiec

co do przepalania rdzenia przez sleepa
to nei ejstem zbyt przekonany co do tego czy
jest to mozliwe bo od lat uzywam sleepa na glownym
watku obserwujac czasy ramek i tez zuzycie procka
w trayu i nigdy nie bylo tak by sleep nie zadzialal
na glowym watku.. to by nie zdzialal na pobocznym tez
wydaje mi sie wiec chyab raczej 'unexpected'

moglbym to pomierzyc timerami i poobserwowac 
w zasadzie ale na razi enie che mi sie w to 
wchodzic

nei wiem jak technicznie ale logicznie sleep 
jest zupelnie poprawna funkcją itd

faktem jest tez jednak ze kiedys za dawnych czasow
na jakichs kompach obserwowalem ze sleep jakby byl
czasem nie wiadomo w zaleznosci od czego
wyrownywany do 15 ms nawet jak wolane bylo 5 ms
ale od lat tego nei widzialem mozliwe ze to bylo
tylko na jednordzemiakach

co do tego synchronizowania flafami tez nie jestem
pewien czy to jest zle, jak mowie zrobilem to i
raczej dzialalo choc nie robilem dokladnych
testow timerami itd - kwestia jest taka ze w tym
akurat kodzie o ktorym mowie mozna bylo zrobic na
lajcie tak by kazdy watek pisal do swojej flagi
a glowny tylko je czytal wiec nie bylo tak ze
jakies dwa pisaly do wspolnej flagi, nawet
jakby cos tam sie w czasie rozminelo o pare
mikrosekund miedzy watkami to tez nie robiloby
to problemu co najwyzej jeden poczekalby tego
jednego sleepa wiecej

ale pewnie bedzie trzena poczytac wiecej
faktycznie o tych wspomnianych rzeczach
(na poczatek uzywalbym raczej tych prostszych)

tenx za informacje bo byly pomocne, mam jakis obraz
co i jak

środa, 6 stycznia 2021 o 15:30:01 UTC+1 fir napisał(a):
> środa, 6 stycznia 2021 o 14:46:53 UTC+1 heby napisał(a): 
> > On 06/01/2021 14:40, fir wrote: 
> > >> Lub wyższych koncpecji jak future/promise i thread pool. 
> > > po flagach tez chyba powino dzialac... 
> > Nie, ponieważ albo będzie się kręcił bez sleepa, przepalając energię, 
> > albo semafor będzie szybszy od sleepa. 
> > 
> > W grę, z flagami, wchodzą też detale działania cache. Zmiana zmiennej w 
> > CPU1 nie powoduje natychmiastowej widzialnosci w CPU2. W niektóych 
> > architekturach nawet kolejnośc zmian pamięci jest nieokreślona jeśli 
> > obserwujemy ją z innego rdzenia. 
> > > ma to jakies minusy...sleep w windzie dziala ok z pobocznymi wątkami? 
> > Sleep to najgosze co można wybrać. Nie ma żadnej zalety, a same wady.
> nie przecze ale chodzi tez o to by to zrozumiec 
> 
> co do przepalania rdzenia przez sleepa 
> to nei ejstem zbyt przekonany co do tego czy 
> jest to mozliwe bo od lat uzywam sleepa na glownym 
> watku obserwujac czasy ramek i tez zuzycie procka 
> w trayu i nigdy nie bylo tak by sleep nie zadzialal 
> na glowym watku.. to by nie zdzialal na pobocznym tez 
> wydaje mi sie wiec chyab raczej 'unexpected' 
> 
> moglbym to pomierzyc timerami i poobserwowac 
> w zasadzie ale na razi enie che mi sie w to 
> wchodzic 
> 
> nei wiem jak technicznie ale logicznie sleep 
> jest zupelnie poprawna funkcją itd 
> 
> faktem jest tez jednak ze kiedys za dawnych czasow 
> na jakichs kompach obserwowalem ze sleep jakby byl 
> czasem nie wiadomo w zaleznosci od czego 
> wyrownywany do 15 ms nawet jak wolane bylo 5 ms 
> ale od lat tego nei widzialem mozliwe ze to bylo 
> tylko na jednordzemiakach 
> 
> co do tego synchronizowania flafami tez nie jestem 
> pewien czy to jest zle, jak mowie zrobilem to i 
> raczej dzialalo choc nie robilem dokladnych 
> testow timerami itd - kwestia jest taka ze w tym 
> akurat kodzie o ktorym mowie mozna bylo zrobic na 
> lajcie tak by kazdy watek pisal do swojej flagi 
> a glowny tylko je czytal wiec nie bylo tak ze 
> jakies dwa pisaly do wspolnej flagi, nawet 
> jakby cos tam sie w czasie rozminelo o pare 
> mikrosekund miedzy watkami to tez nie robiloby 
> to problemu co najwyzej jeden poczekalby tego 
> jednego sleepa wiecej 
> 

logicznie to raczej trzymalo sie kupy (to czyli synchrronizacja na sleepach i flagach) wiec i technicznie 
mogloby sie trzymac o ile te sleepy albo watki nie wykazywaly jakichs wewnetrznych nie znanych mi cech powodujacych ze cos tu jest nie tak

co troche nawiazuje do starego watku na CLC gdzie pisalem jak pamietam uzytkownikowi AL ze mozna synchronizowac watki nawet bez atomikow (na podobnej zasadzie o ile pamietam tylko nawet w drobniejszej skali czasowej, obecnie troche nie pamietam tamtego przykladu)

jesliby sie okazalao ze ta watki czy sleepy maja jakies cechy ktore powoduja ze sie nie sprawdzaja w tego typu kodzie to troche kiepsko bo fajnie by bylo jakby ludzie projektowali rzeczy na taki nazwijmy to "woluntarystyczny" sposob ;c

> ale pewnie bedzie trzena poczytac wiecej 
> faktycznie o tych wspomnianych rzeczach 
> (na poczatek uzywalbym raczej tych prostszych) 
> 
> tenx za informacje bo byly pomocne, mam jakis obraz 
> co i jak

On 06/01/2021 15:29, fir wrote:
> co do przepalania rdzenia przez sleepa

Sleep nic nie przepala. Busy wait przepala (spin lock) czekający w pętli 
na zmienną. Istnieją hybryty spinlock z condition które zapewniają 
troche wiecej zjadanej energii i szybką reakcję.

W dodatku poprawne napisanie szybkiego spinlocka jest bardzo trudne (z 
uwagi na synchronizacje cache na różnych architekturach cpu). Zazwyczaj 
takie mechanizmy są dostarczane w formie biblitek, aby program nie 
zajmował się detalami działania peocesora.

> nei wiem jak technicznie ale logicznie sleep

Bo mylisz sleep z busy wait.

Sleep jest najgorszy, bo gwarantuje najgorszą responsywaność i ma taki 
sam profil energetyczny jak semafor.

Busy wait jest najszybszy, ale tylko pod warunkiem że potrafisz go 
poprawnie napisać (cache) i masz prąd za darmo.

Semafor jest najlepszy "w gólnym przypadku". Jesli masz przypadek 
krytycznie ważny pod kątem wydajności, to hybryda spinlock z 
condition/semafor.

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) { }.

ś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

ś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)

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