Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #31511 > unrolled thread

Szybkośc przelaczenia threadu przy rurce

Back to article view | Back to pl.comp.programming

Contents

  Szybkośc przelaczenia threadu przy rurce Sebastian Biały <heby@poczta.onet.pl> - 2018-03-20 22:25 +0100
    Re: Szybkośc przelaczenia threadu przy rurce "M.M." <mmarszik@gmail.com> - 2018-03-20 21:08 -0700
    Re: Szybkośc przelaczenia threadu przy rurce gof@somewhere.invalid (Adam Wysocki) - 2018-03-21 12:26 +0000
      Re: Szybkośc przelaczenia threadu przy rurce Sebastian Biały <heby@poczta.onet.pl> - 2018-03-31 13:19 +0200
    Re: Szybkośc przelaczenia threadu przy rurce Yakhub <aa@aa.aa> - 2018-03-26 09:24 +0200
      Re: Szybkośc przelaczenia threadu przy rurce Sebastian Biały <heby@poczta.onet.pl> - 2018-03-31 13:18 +0200
    Re: Szybkośc przelaczenia threadu przy rurce Maciej Sobczak <see.my.homepage@gmail.com> - 2018-03-26 02:52 -0700
      Re: Szybkośc przelaczenia threadu przy rurce Sebastian Biały <heby@poczta.onet.pl> - 2018-03-31 13:16 +0200

#31511 — Szybkośc przelaczenia threadu przy rurce

Cześć.

Jest sobie proces A.

W środku procesu A działają threads: T1 i T2.

Załóżmy że maszyna nie jest niczym zajęta i ma 2 fizyczne rdzenie.

T1 pisze do rury.

T2 czyta z rury.

W tej chwili T2 jest zablokowany na read na rurze.

T1 wkłada bajt do rury.

Jak szybko T2 zostanie wznowiony? Sa to dwa pytania: jak szybko 
informacja w rurze wyleci na zewnatrz i jak szybko wątek T2 ruszy.

Pytanie jest z gatunku ogolnych ponieważ chce wiedziec jak szybko moge 
się spodziewać wznowienia we współczesnych systemach operacyjnych. Tu i 
tam pobąkują że np. Windows jets w stanie przełaczyć kilkaset razy na 
sekunde kontekst wątku. Tylko że to dotyczy chyba ich ciaglej pracy. A u 
mnie t1 wsadził do rurki i, jesli moje urojenia są prawdziwe, T2 
powinien zostać wznowiony natychmiast (np. na drugim core). Chciałbym 
wiedziec jak oszacować to "natychmiast".

Moge napisac przykład. Ale może ktoś wie od ręki jak dziala OS (Win/Lin) 
w takiej sytuacji.

Opcja ekspercka: a co jeśli T1 jest w procesie A a T2 w procesie B? 
Procesor ma 2 cory, w systemie cisza. Czy strace czas na jakiś switch 
contextu? Urojenie jest takie że OS mógłby trzymac w gotowości Proces B 
ja wolnym core i nie powinno być spowolnień vs dwa wątki w jednym procesie.

[toc] | [next] | [standalone]

#31512

On Tuesday, March 20, 2018 at 10:26:15 PM UTC+1, Sebastian Biały wrote:
> [...]
> Moge napisac przykład. Ale może ktoś wie od ręki jak dziala OS (Win/Lin) 
> w takiej sytuacji.

Głowy nie dam, ale obawiam się, że nie otrzymasz tak precyzyjnej 
odpowiedzi, która uchroniłaby Ciebie przed pisaniem testów. Nawet
jakbyś dostał tak precyzyjną odpowiedź, to nie wiem czy jesteś pewny
co do nakładu obliczeń swojego oprogramowania. Podsumowując: jeśli to 
co robisz jest ważne i jeśli działaś 'na krawędzi' - czyli wykonujesz
relatywnie mało operacji względem operacji na rurkach/wątkach, to i
tak i tak czeka Ciebie kilka prób i pomiarów czasu. 

> [...]

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#31513

Sebastian Biały <heby@poczta.onet.pl> wrote:

> Jak szybko T2 zostanie wznowiony?

Nie ma na to żadnej gwarancji. Ani Windows ani Linux nie są OS-ami czasu 
rzeczywistego, a nawet jakbyś miał tylko te dwa procesy w systemie i 
żadnego innego (nawet init), to i tak kernel robi różne rzeczy i 
potrzebuje do tego procesora.

> Moge napisac przykład.

Spróbuj, pokesperymentuj też z sched_setaffinity.

http://man7.org/linux/man-pages/man2/sched_setaffinity.2.html

-- 
[ Email: a@b a=grp b=chmurka.net ]
[ Web:   http://www.chmurka.net/ ]

[toc] | [prev] | [next] | [standalone]

#31537

On 3/21/2018 1:26 PM, Adam Wysocki wrote:
>> Jak szybko T2 zostanie wznowiony?
> Nie ma na to żadnej gwarancji.

Nie pytam o gwarancje, nie pisze apliakcji RT.

> Spróbuj, pokesperymentuj też z sched_setaffinity.
> http://man7.org/linux/man-pages/man2/sched_setaffinity.2.html

Misiałbym wczesniej chyba miec pojęcie o tym jak działa algorytmika 
schedulera wątków i procesów. To troche spory temat na samodzielne 
przegryzanie się.

[toc] | [prev] | [next] | [standalone]

#31532

Dnia Tue, 20 Mar 2018 22:25:53 +0100, Sebastian Biały napisał(a):

> Jak szybko T2 zostanie wznowiony? Sa to dwa pytania: jak szybko 
> informacja w rurze wyleci na zewnatrz i jak szybko wątek T2 ruszy.

Odpowiedź: Wątek T2 ruszy wtedy, gdy OS znajdzie czas, żeby go przełączyć.
Nie wcześniej, i nie później.

Ten czas możesz co najwyżej zgrubnie oszacować, bazując na statystyce
(czyt. "w 80% przypadków, będzie to krócej, niż X"), ale nigdy nie będziesz
go pewien.

-- 
Yakhub

[toc] | [prev] | [next] | [standalone]

#31536

On 3/26/2018 9:24 AM, Yakhub wrote:
>> Jak szybko T2 zostanie wznowiony? Sa to dwa pytania: jak szybko
>> informacja w rurze wyleci na zewnatrz i jak szybko wątek T2 ruszy.
> Odpowiedź: Wątek T2 ruszy wtedy, gdy OS znajdzie czas, żeby go przełączyć.
> Nie wcześniej, i nie później.

Pytam o średni czas obserwowany w aplikacjach.

> Ten czas możesz co najwyżej zgrubnie oszacować, bazując na statystyce
> (czyt. "w 80% przypadków, będzie to krócej, niż X"), ale nigdy nie będziesz
> go pewien.

Nie musze być pewien, przesylam miliony małych komunikatów w czasie 
życia aplikacji, chcę mieć wyłącznie pogląd statystyczny o jakich 
czasach mówimy we współczesnych systemach operacyjnych i co mozna zrobić 
aby te czasy redukować.

[toc] | [prev] | [next] | [standalone]

#31533

> Jak szybko T2 zostanie wznowiony? Sa to dwa pytania: jak szybko 
> informacja w rurze wyleci na zewnatrz i jak szybko wątek T2 ruszy.

To jest jedno pytanie, bo pierwsze nie ma sensu w oderwaniu od drugiego.

> Pytanie jest z gatunku ogolnych ponieważ chce wiedziec jak szybko moge 
> się spodziewać wznowienia we współczesnych systemach operacyjnych. Tu i 
> tam pobąkują że np. Windows jets w stanie przełaczyć kilkaset razy na 
> sekunde kontekst wątku.

Etam. Dwa procesy komunikujące się na tym samym pececie przez lokalne TCP są w stanie przesłać 10000 komunikatów na sekundę właśnie w ten sposób (nie ma powodu, żeby lokalne TCP było szybsze, niż rura). Po drodze dzieje się mnóstwo innych rzeczy, niż samo pisanie i czytanie, więc da się to odchudzić i jeszcze przyśpieszyć.
Bardzo łatwo jest to zmierzyć, napisz pętlę i weź do ręki zegarek.

> Tylko że to dotyczy chyba ich ciaglej pracy. A u 
> mnie t1 wsadził do rurki i, jesli moje urojenia są prawdziwe, T2 
> powinien zostać wznowiony natychmiast (np. na drugim core). Chciałbym 
> wiedziec jak oszacować to "natychmiast".

Nie ma czegoś takiego jak "natychmiast", jeśli coś jest gdzieś indziej.
Natomiast możesz rozważyć dwa przypadki:

1. T1 pisze, T2 czyta i tak w kółko
2. T1 pisze, T2 czyta, T2 pisze, T1 czyta, i tak w kółko

Różnica jest taka, że jeśli T1 tylko pisze, to może napisać dwa komunikaty zanim T2 odczyta pierwszy. To nie jest problemem jeśli T2 rozróżnia granice między komunikatami, ale może spowodować, że T2 obudzi się tylko raz i za jednym odczytem pobierze wszystkie dostępne dane (czyli dwa komunikaty). To zakłóci pomiar, bo ilość komunikatów nie będzie równa ilości wybudzeń.
Drugi scenariusz (ping-pong) zapewnia, że komunikaty są pisane i czytane pojedynczo. Pierwszy scenariusz może być szybszy w sensie throughput, co zwykle jest korzystne.

> Opcja ekspercka: a co jeśli T1 jest w procesie A a T2 w procesie B?

Też trzeba zmierzyć.

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#31535

On 3/26/2018 11:52 AM, Maciej Sobczak wrote:
> Etam. Dwa procesy komunikujące się na tym samym pececie przez lokalne TCP są w stanie przesłać 10000 komunikatów na sekundę

Kiepsko. Jesteś pewien że masz TCP_NODELAY?

> Bardzo łatwo jest to zmierzyć, napisz pętlę i weź do ręki zegarek.

Jestem wrogiem statystcznych benchmarków z gatunku for( i = 0 ; i < 
10000000 ... bo są nic nie warte w praktyce.

Ja tak naprawde pytam o internalne dzialanie systemu operacyjnego.

Np. swego czasu w windowsie był lub jest taki algorytm który jesli watek 
zawiesi się na wait to inny watek wykorzystuje jego pozostałą cześć 
slotu czasowego. Zakładając że byłby od wybrany sprytnie, czyli akurat 
ten który dane ma odebrać było by to szybsze niż czekanie na nastepną 
rundę. A może można pomóc wskazując jaki inny watek miałby się obudzić 
kiedy ja zrobie wait. A może trzeba robić spinlocki zamiast czekać 
biernie na wyjście z read. A może porzucić rury na rzecz jawnego shared 
memory bo nie mają sensu. itd itp. Jestem pewny że ktoś już to wczesniej 
obadał i wie jak zrobić to sensownie szybko.

[toc] | [prev] | [standalone]

Back to top | Article view | pl.comp.programming

csiph-web