[so] Performance Notice - pentru implementari viitoare de asynch I/O pe windwos
Bercea Gabriel
gamitech at gmail.com
Thu Jun 12 02:08:36 EEST 2008
Scriu postul asta pentru ca mi se pare ca tema asta e printre cele mai
interesante, si a carei utlitate, e mult mai transparenta decat la
celelate teme.
Pentru cine a folosit metoda completion ports.
Performance tips:
De ce numarul de threaduri din pool este bine sa fie in unele cazuri mai
mare decat numarul de procesoare existente, si cum functioneaza de fapt
completion porturile.
Pentru sistem dual core, de ex.
Un completion port face schedduling LIFO pentru threadurile care in wait
state, pentru o notificare I/O . Daca unul din threaduri este deblocat,
atunci el trece din coada
interna de waiting a completion portului, in coada running. Completion
portul in acest moment, stie ca acel thread este in executie. Cat timp
threadul este in executie, portul
primeste inca o notificare I/O si trezeste alt 2 lea thread. In acest
caz.cele 2 threaduri servesc notificari. Problema este urmatoare. Daca
in timpul servirii unui request unul din
threaduri face apel la o un functie de wait, atunci timpul de procesor,
trece de pomana. In acest moment coada de waiting de la completion port
creste cu 1, chiar daca threadul nu este
in waiting cu GetQuedCompletionStatus. Asta inseamna ca daca ar fi un al
3 lea thread asteptand requesturi pe completion port, acesta ar fi
lansat. Asta se si intampla de fapt,
si performanta creste. Se recomanda ca poolul de threaduri sa fie mai
mare decat numarul de procesoare (si mai exact 2*no_CPUs) atunci cand se
face procesare intensiva pe fiecare request.
Aceste este un rezultat heuristic, care a fost scos in urma multor
testari a acestui concept.
O alta chestie care ar putea da boost, executiei, si care o gasesc utila
in unele cazuri, in care chiar nu te intereseaza cum s-a terminat un I/O
request si nu il vrei procesat.
Pentru urm scenariu, am in completion port, un hFile, asupra caruia am
facut un write, al carui deznodamant nu ma intereseaza, nu vreau sa il
procesez, nu vreau ca
GetQueuedCompletionStatus sa imi returneze pentru el. Here is the
undocummented trick :P
Overlapped.hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
Overlapped.hEvent = (HANDLE) ((DWORD_PTR) Overlapped.hEvent | 1);
WriteFile(..., &Overlapped);
Acest caz, in care overlappedul are eventul OR-uit pe biti cu 1, nu va fi pus in coada de I/O a completion portului, si deci GetQuedCompletionStatus
nu se va fi notificat pentru el.
Nu uitati
CloseHandle((HANDLE) ((DWORD_PTR) Overlapped.hEvent & ~1));
Negati 1 OR-uit pentru CloseEvent, logic.
CompletionPort urile sunt mecanisme destul de complexe si putin documentate, si sper sa fi fost de folos ce am spus. Asta daca se face aim pe performanta.
Bafta.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gamitech.vcf
Type: text/x-vcard
Size: 222 bytes
Desc: not available
Url : http://cursuri.cs.pub.ro/pipermail/so/attachments/20080612/f9f9f80e/attachment.vcf
More information about the so
mailing list