Przenoszenie wątków do okien. Sekcje krytyczne są bardzo powolne.

Question

Przenoszę kod do okien i stwierdzam, że wątki są bardzo powolne. Zadanie trwa 300 sekund w oknach (z dwoma xeon E5-2670 8 core 2.6ghz = 16 core) i 3.5 sekund na linuxie (xeon E5-1607 4 core 3ghz). Korzystanie z ekspresu vs2012.

Mam 32 wątki wszystkich wywoływanie EnterCriticalSection(), popping 80 bajtów std :: stos, LeaveCriticalSection i wykonanie niektórych pracy (łącznie 250k zadań).

Przed i po każdym krytycznym wywołaniu sekcji drukuję identyfikator wątku i aktualny czas.

• Czas oczekiwania na blokadę jeden wątek jest ~ 160ms
• pop pracę ze stosu zajmuje ~ 3ms
• Wywołanie urlop trwa ~ 3ms
• Zadanie wykonuje ~ 1ms

(w przybliżeniu to samo dla debugowania/wydania, debugowanie zajmuje trochę dłużej. Chciałbym móc poprawnie profilować kod: P)

Komentowanie wywołanie zadania sprawia, że ​​cały proces trwa 2 sekundy (wciąż więcej niż linux).

Próbowałem już zarówno queryperformancecounter i timeGetTime, oba dają w przybliżeniu taki sam wynik.

AFAIK zadanie nigdy nie wykonuje żadnych połączeń synchronizacyjnych, ale nie mogę wytłumaczyć spowolnienia, chyba że to zrobi.

Nie mam pojęcia, dlaczego kopiowanie ze stosu i wywoływanie muzyki pop trwa tak długo. Inną bardzo mylącą rzeczą jest to, że wywołanie metody leave() trwa tak długo.

Czy ktoś może spekulować, dlaczego działa tak wolno?

Nie sądziłbym, że różnica w procesorze dałaby 100-krotną różnicę wydajności, ale czy w ogóle mogła być związana z dwoma procesorami? (konieczność synchronizacji pomiędzy oddzielnymi procesorami niż wewnętrznymi rdzeniami).

Nawiasem mówiąc, jestem świadomy std :: thread, ale chcę, aby mój kod biblioteki działał z pre C++ 11.

edit

//in a while(hasJobs) loop... 

EVENT qwe1 = {"lock", timeGetTime(), id}; 
events.push_back(qwe1); 

scene->jobMutex.lock(); 

EVENT qwe2 = {"getjob", timeGetTime(), id}; 
events.push_back(qwe2); 

hasJobs = !scene->jobs.empty(); 
if (hasJobs) 
{ 
    job = scene->jobs.front(); 
    scene->jobs.pop(); 
} 

EVENT qwe3 = {"gotjob", timeGetTime(), id}; 
events.push_back(qwe3); 

scene->jobMutex.unlock(); 

EVENT qwe4 = {"unlock", timeGetTime(), id}; 
events.push_back(qwe4); 

if (hasJobs) 
    scene->performJob(job); 

a klasa mutex, z linux #ifdef rzeczy usunięte ...

CRITICAL_SECTION mutex; 

... 

Mutex::Mutex() 
{ 
    InitializeCriticalSection(&mutex); 
} 
Mutex::~Mutex() 
{ 
    DeleteCriticalSection(&mutex); 
} 
void Mutex::lock() 
{ 
    EnterCriticalSection(&mutex); 
} 
void Mutex::unlock() 
{ 
    LeaveCriticalSection(&mutex); 
} 

Answer 1

Wydaje się swoim Windows wątki stoją super-twierdzenia. Wydają się być całkowicie serializowane. Masz około 7 ms całkowitego czasu przetwarzania w sekcji krytycznej i 32 wątków. Jeśli wszystkie wątki zostaną umieszczone w kolejce na zamku, ostatni wątek w kolejce nie będzie działał, dopóki nie spocznie około 217 ms. To nie jest zbyt daleko od 160ms obserwowanego czasu oczekiwania.

Tak więc, jeśli nici nie mają nic więcej do roboty, niż wejście do sekcji krytycznej, wykonaj pracę, a następnie opuść sekcję krytyczną, takie zachowanie się spodziewam.

Postaraj się scharakteryzować zachowanie profilowania linuxa i sprawdź, czy zachowanie programu jest naprawdę, a porównanie jabłek z jabłkami.

Answer 2

Okna CRITICAL_SECTION obracają się w ciasnej pętli przy pierwszym wejściu. Nie zawiesza wątku, który wywołał EnterCriticalSection, chyba że upłynął znaczny okres w pętli spinu. Zatem posiadanie 32 wątków rywalizujących o tę samą sekcję krytyczną spowoduje spalenie i zmarnowanie wielu cykli procesora. Wypróbuj zamiast tego muteksa (patrz CreateMutex).