🚀 go-pugleaf

czwartek, 20 maja 2021 o 14:06:34 UTC+2 heby napisał(a):
> Cześć. 
> 
> Proces A komunikuje się z procesem B za pomocą *czegoś*. Np. rurek. 
> 
> Chce zmierzy czas takiej komuniakcji, konkretnie jak szybko w B 
> zareaguje ::read kiedy w ::A skończył się write. 
> 
> powinienem uzyć RDTSC zapewne ale: 
> 1) czy współczesne procesory zapewniają że dwa rózne procesy czytają ten 
> sam timer (np. rózne timery dla róznych rdzeni) 
> 2) jak *oficjalnie* przeliczyć to na sekundy? Z tego co widzę, 
> najczęsciej robi się benchmark na starcie aplikacji, ale ... to jest 
> takie sobie, bardziej brzemi jak workaround. 
> 
> Myślałem że odpale google, ale okazuje się że ... właśnie nie. Albo 
> odpowiedzi są błedne, albo nieaktualne, albo podają benchmark jako przykład. 
> 
> OSy tego jakoś nie ogarniają? Serio, musze benchmarkować timer? 
> 
> Całość problemu na C[++] i Windows/Linux.

Sam syf dostaniesz z tego, precesory zmieniają taktowanie, wiele rdzeni też tu nie pomaga. 
Jak to c++, sprawdź czy std::chrono::steady_clock i okolice mają wystarczającą rozdzielczość
(niestety, to bardoz mocno zależy od implementacji).

A co ważniejsze, naprawdę potrzebujesz wiedzieć, ile minie pomiędzy taką komunikacją?
To będzie zależne od bardzo wielu rzeczy i niezbyt powtarzalne. A jak robisz jakiś system
czasu rzeczywistego... to pewnie nie obejdzie się bez odpowiedniego OS. Zwykły linux i windows
nie dają zadnych gwarancji:)

pzdr
bartekltg

On 24/06/2021 22:43, bartekltg wrote:
> A co ważniejsze, naprawdę potrzebujesz wiedzieć, ile minie pomiędzy taką komunikacją?

Mam poważny problem związany z utylizacją CPU między procesami:

1) pętla
2)  A: wysyła bajt do rurki
3)  A: blokuje się na read bajtu w innej rurce
4)  B: odbiera bajt i go odsyła inną rurką
5)  B: blokuje się na read bajtu
6) NEXT I

Innymi słowy program nie robi nic, poza bezustannym przesyłaniem z 
potwierdzeniem.

Taki program utylizuje ~2% CPU... Całą reszta, jesli rozumiem, zostaje 
skonsumowana na wybudzanie/usypianie procesów.

Jestem ciekaw o jakich rozmiarach katastrofach rozmawiamy, czy naprawdę 
zablokowanie się read na strumieniu zajmuje miliony cykli zegara cpu?

> To będzie zależne od bardzo wielu rzeczy i niezbyt powtarzalne. A jak robisz jakiś system
> czasu rzeczywistego...

Interesuje mnie wydajnoć. Muszę się *szybko* komunikować między kilkoma 
procesami i rurki okazują się być kłopotliwe, mam na nich absurdalne 
spowolnienia.

piątek, 25 czerwca 2021 o 07:30:25 UTC+2 heby napisał(a):
> On 24/06/2021 22:43, bartekltg wrote: 
> > A co ważniejsze, naprawdę potrzebujesz wiedzieć, ile minie pomiędzy taką komunikacją?
> Mam poważny problem związany z utylizacją CPU między procesami: 
> 
> 1) pętla 
> 2) A: wysyła bajt do rurki 
> 3) A: blokuje się na read bajtu w innej rurce 
> 4) B: odbiera bajt i go odsyła inną rurką 
> 5) B: blokuje się na read bajtu 
> 6) NEXT I 
> 
> Innymi słowy program nie robi nic, poza bezustannym przesyłaniem z 
> potwierdzeniem. 

No, jeśli potwierdzanie to komunikacja z B do A i potwierdzasz
po każdym bajcie, to nic dziwnego, że to działa na ułamek procenta.  


Jesteś w ogole pewien, że odpalają się dwa wątki? 

> Taki program utylizuje ~2% CPU... Całą reszta, jesli rozumiem, zostaje 
> skonsumowana na wybudzanie/usypianie procesów. 

 
> Jestem ciekaw o jakich rozmiarach katastrofach rozmawiamy, czy naprawdę 
> zablokowanie się read na strumieniu zajmuje miliony cykli zegara cpu?
> > To będzie zależne od bardzo wielu rzeczy i niezbyt powtarzalne. A jak robisz jakiś system 
> > czasu rzeczywistego...
> Interesuje mnie wydajnoć. Muszę się *szybko* komunikować między kilkoma 
> procesami i rurki okazują się być kłopotliwe, mam na nich absurdalne 
> spowolnienia.

No, w sumie rurki nie sa od tego. To zastępuje sytuacje A pisze do pliku, B czyta z pliku,
nikt nie obiecuje, że nie będzie buforowania etc, w końcu co zbobić z jednym bajtem. 

Jak chcesz iść całkiem na całość, to pewnie to lub coś podobnego:
https://www.boost.org/doc/libs/1_76_0/doc/html/interprocess.html
https://theboostcpplibraries.com/boost.interprocess

Ale to trochę overkill. 

Zastanow sie, czy na pwno potrzebujesz osobnych proecesów, może wątki
wystarczą.

Jak chcesz duzęgo transferu danych (i dużych % w uzyciu cpu), transferuj duze paczki danych, buforuj etc. 

Jeśli chesz szybkiej reakcji, jak pisałem poprzednio, nie ten system.



pzdr
bartekltg

On 27/06/2021 01:35, bartekltg wrote:
> No, jeśli potwierdzanie to komunikacja z B do A i potwierdzasz
> po każdym bajcie, to nic dziwnego, że to działa na ułamek procenta.

Czysto teoretycznie: powinno być 100% jednego rdzenia minu czas spędzony 
w kernelu na switchowaniu wątków i procesów. Ale obecnie mamy przecież 
multicore.

> Jesteś w ogole pewien, że odpalają się dwa wątki?

Dwa procesy.

> No, w sumie rurki nie sa od tego.

Są IPC ;) W zasadzie nie ma innych rozwiązań, jesli to ma być kanoniczny 
Unix.

> To zastępuje sytuacje A pisze do pliku, B czyta z pliku,
> nikt nie obiecuje, że nie będzie buforowania etc, w końcu co zbobić z jednym bajtem.

Tak to wygląda z poziomu API, ale pod spodem są inne implementacje, np. 
buforowanie rurki wykonywane jest bezpośrednio w kernelu specjalistyczną 
implementacją, ponoć super szybką. Podobno, tak piszą w internetach. Bo 
mi nie działa tak szybko, aby skakać z radości.

> Jak chcesz iść całkiem na całość, to pewnie to lub coś podobnego:
> https://www.boost.org/doc/libs/1_76_0/doc/html/interprocess.html
> https://theboostcpplibraries.com/boost.interprocess

Używam. Podstawowy problem to spinlocki.

> Ale to trochę overkill.

Nie, to całkiem spoko, gdyby nie fakt, że spinlocki powodują złudzenie 
że program wypełnia cały rdzeń, a to tylko kręcenie sie w kółko w 
ciasnych pętlach, czekając na bajt. Dodatkowo nie wiem, czy używanie co 
chwilę "fence" w celu czekania na kocherencję cache między rdzeniami, 
jest wydajne.

> Zastanow sie, czy na pwno potrzebujesz osobnych proecesów, może wątki
> wystarczą.

Potrzebuje, z przyczyn kłopotliwych do wyjaśnienia (komercyjna aplikacja).

> Jak chcesz duzęgo transferu danych (i dużych % w uzyciu cpu), transferuj duze paczki danych, buforuj etc.

Tak by się mogło wydawac, ale rura ma 4kB w kernelu i w zasadzie, jeśli 
wysyłam takie paczki, to czas reakcji po drugiej stronie jest równie 
długi. Zwiększam przepustowośc, responsywanośc pozostaje taka sama.

Walczę o responsywność, nie przepustowość.

> Jeśli chesz szybkiej reakcji, jak pisałem poprzednio, nie ten system.

Nie chce reakcji RT, ale spodziewam się reakcji nie bazujacej na 
"sleep(1)". A obecnie mam wrażenie, że te sleepy ktoś mi złośliwie 
powstawiał do kodu.

W ignorancji swojej myślałem, że drugi proces będzie miał przydzielony 
inny rdzeń CPU i *natymiast* po zauważeniu czegoś w buforze wykona się 
"read()". Ale się nie wykonuje tak natychmiast, wręcz zdumiewająco długo 
to trwa. Jestem ciekaw dlaczego, najzwyczajniej nie rozumiem kosztu 
przełączenia procesu/wątku we współczesnych CPU chyba, skoro to tyle 
zajmuje. Wydawało mi się, że wręcz przełaczenia nie będzie, a jedynie 
wybudzenie (tzn brak problemów z cache/stronami) - z uwagi na multicore. 
Jestem zaskoczony, dlatego chciałem sobie to pomierzyć, coby zrozumieć 
jeszcze mniej ;).