On Saturday, April 20, 2013 11:04:29 PM UTC+2, Bronek Kozicki wrote:
> dobrze myślisz. Ponadto, jeżeli serwer jest dedykowany do jednego
> procesu, to możesz sobie pozwolić na SetThreadAffinityMask na każdym wątku
Nie wiem, ale wydaje się, że to jest bez sensu. Co jeśli system odbierze
sterowanie i inny proces nabije licznik taktów?
Pozdrawiam

do góry

Użytkownik "M.M." <m...@g...com> napisał w wiadomości
news:2bdc9de6-4aa7-4b4c-8c45-a2dd52871ca5@googlegrou
ps.com...
> Nie wiem, ale wydaje się, że to jest bez sensu. Co jeśli system odbierze
> sterowanie i inny proces nabije licznik taktów?

Cicho zakładam, że chodził będzie przede wszystkim proces profilowany a inne
będą w tle raczej nieaktywne.
Ale musimy rozróżnic dwa źródła problemów:
Jeden dotyczy tylko rdtsc - osobne liczniki na każdym rdzeniu, to załatwia
SetThreadAffinityMask na każdym wątku; daje się ustawić ręcznie, jednak czy
instnieje algorytm dodawania w miejsca kodu SetThreadAffinityMask dla
każdego wątku przez profiler, czy też jest to problem nieobliczalny?
--------------------------
Drugi, zupełnie inny - to wieloprocesowość i wielowątkowość - chcemy
zmierzyć daną funkcję, mierzymy czas na początku i końcu ale nam się włącza
inny wątek.
To występuje nie tylko przy rdtsc ale również przy QueryPerformanceCounter,
zdaje się że tylko GetTickCount jest od tego wolna, ale gdy chodzi o jej
dokładność - pokazuje wynik w milisekundach, ale tak naprawdę mierzy w 1/64
sekundowych tickach, przy których przełączane są wątki i procesy, więc
dokładność żadna.

do góry

On Sunday, April 21, 2013 12:02:08 PM UTC+2, Borneq wrote:
> Użytkownik "M.M." napisał w wiadomości
>
> news:2bdc9de6-4aa7-4b4c-8c45-a2dd52871ca5@googlegrou
ps.com...
>
> > Nie wiem, ale wydaje się, że to jest bez sensu. Co jeśli system odbierze
>
> > sterowanie i inny proces nabije licznik taktów?
>
>
>
> Cicho zakładam, że chodził będzie przede wszystkim proces profilowany a inne
> będą w tle raczej nieaktywne.
Przy takim założeniu wystarczy mniej dokładny pomiar.


[...]
> To występuje nie tylko przy rdtsc ale również przy QueryPerformanceCounter,
> zdaje się że tylko GetTickCount jest od tego wolna, ale gdy chodzi o jej
> dokładność - pokazuje wynik w milisekundach, ale tak naprawdę mierzy w 1/64
> sekundowych tickach, przy których przełączane są wątki i procesy, więc
> dokładność żadna.
Wystarczy taka dokładność w zupełności.


Małe fragmenty kodu można mierzyć licznikiem taktów. Duże mierzymy zwykłym
timerem jaki oferuje dany OS.


Naprawdę dokładnego pomiaru i tak i tak nie uzyskamy, to nie te czasy,
gdy każda instrukcja miała stałą ilość taktów. Wystarczy że inny proces
zmieni zawartość cache i już pomiar będzie inny, nawet gdy system nie
odbierze sterowania.


Pozdrawiam

do góry

nie rozumiem problemu
obawiasz sie ze jak masz cos takiego

m()
{
//rtdsc

f();

//rtdsc


}

to zczniesz na jednym a skonczysz na innym
rdzeniu bo system przerzuci proces na drugi
rdzen???

do góry

Dnia Sun, 21 Apr 2013 03:52:30 -0700 (PDT), firr kenobi napisał(a):

> nie rozumiem problemu

standard

> obawiasz sie ze jak masz cos takiego
>
> m()
> {
> //rtdsc
>
> f();
>
> //rtdsc
>
>
> }
>
> to zczniesz na jednym a skonczysz na innym
> rdzeniu bo system przerzuci proces na drugi
> rdzen???

A co w tym dziwnego???
I nie proces a watek. Wiesz, istnieje cos takiego jak watek. Ba, istnieje
jeszcze cos nizszego poziomu niz watek, ale nie bede Ci macil, bo to za duzo
nowosci naraz jak na twoja biedna glowe.

--
pozdro
R.e.m.e.K

do góry

On 21/04/2013 11:02, Borneq wrote:
> Użytkownik "M.M." <m...@g...com> napisał w wiadomości
> news:2bdc9de6-4aa7-4b4c-8c45-a2dd52871ca5@googlegrou
ps.com...
>> Nie wiem, ale wydaje się, że to jest bez sensu. Co jeśli system odbierze
>> sterowanie i inny proces nabije licznik taktów?
>
> Cicho zakładam, że chodził będzie przede wszystkim proces profilowany a
> inne będą w tle raczej nieaktywne.
> Ale musimy rozróżnic dwa źródła problemów:
> Jeden dotyczy tylko rdtsc - osobne liczniki na każdym rdzeniu, to
> załatwia SetThreadAffinityMask na każdym wątku; daje się ustawić
> ręcznie, jednak czy instnieje algorytm dodawania w miejsca kodu
> SetThreadAffinityMask dla każdego wątku przez profiler, czy też jest to
> problem nieobliczalny?
> --------------------------
> Drugi, zupełnie inny - to wieloprocesowość i wielowątkowość - chcemy
> zmierzyć daną funkcję, mierzymy czas na początku i końcu ale nam się
> włącza inny wątek.
> To występuje nie tylko przy rdtsc ale również przy
> QueryPerformanceCounter, zdaje się że tylko GetTickCount jest od tego


QueryPerformanceCounter wykonuje context switch, więc do mierzenia czasu
z dokładności poniżej 1 mikorsecondy się nie nadaje.


B.

do góry

On 21/04/2013 11:02, Borneq wrote:
> Użytkownik "M.M." <m...@g...com> napisał w wiadomości
> news:2bdc9de6-4aa7-4b4c-8c45-a2dd52871ca5@googlegrou
ps.com...
>> Nie wiem, ale wydaje się, że to jest bez sensu. Co jeśli system odbierze
>> sterowanie i inny proces nabije licznik taktów?
>
> Cicho zakładam, że chodził będzie przede wszystkim proces profilowany a
> inne będą w tle raczej nieaktywne.
> Ale musimy rozróżnic dwa źródła problemów:
> Jeden dotyczy tylko rdtsc - osobne liczniki na każdym rdzeniu, to
> załatwia SetThreadAffinityMask na każdym wątku; daje się ustawić
> ręcznie, jednak czy instnieje algorytm dodawania w miejsca kodu
> SetThreadAffinityMask dla każdego wątku przez profiler, czy też jest to
> problem nieobliczalny?

wspominając serwer, miałem na myśli że w przypadku aplikacji
produkcyjnej, która ma dla siebie dedykowany serwer, kod produkcyjny
(nie tylko profilowany) może sobie alokować na stałe CPU, tj. możesz dla
poszczególnych wątków ustawić affinity w aplikacji która będzie działać
w produkcji, a nie tylko na profilerze. To dobrze działa jeżeli masz
pulę wątków roboczych dostosowaną do liczby dostępnych CPU (najlepiej
jest zawsze zostawiać CPU0 dla systemu), ale nie za bardzo jeżeli
tworzysz wątki dynamicznie.


B.

do góry

Dnia Sat, 20 Apr 2013 13:04:43 +0200 po głębokim namyśle Michoo rzekł:

> On 20.04.2013 10:35, Borneq wrote:
>> Użytkownik "M.M." <m...@g...com> napisał w wiadomości
>> news:3ae04ea4-5412-4424-894d-8772dd5d8873@googlegrou
ps.com...
>>> Ja bym wyjął optymalizowany fragment do innego programu i uruchamiał
>>> zdecydowanie jako jednowątkowy.
>>
>> Weźmy przypadek dokładnego profilera, który może nie tylko mierzyć czas
>> funkcji ale i wewnątrz funkcji. Wtedy kompilujemy program z
>> informacjami dla profilera, który dodaje rdtsc w odpowiednich miejscach
>
> Jeżeli w trakcie wykonania był zmieniony rdzeń to wyniki rdtsc są
> niewiele mówiące. Zapisanie stanu procesu to kilkaset cykli, odczytanie
> również. Jak jeszcze proces trafił na niespokrewniony rdzeń to cache mu
> się rozleciało... Ten pomiar jest po prostu do powtórki.

Nie dałoby się użyć cgroups/cpu? Mając algorytm bez io dałoby się
profilować nawet wielowątkowy kod. Chociaż nie jestem pewien czy
to będzie działać.

--
Edek

do góry