🚀 go-pugleaf

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 ;).