Salut. On Wed, 2 Sep 2015, tiberiu socaciu wrote:
> cate thread-uri? ia incearca cu 2 thread-uri pe un procesor cu minim 2 > core-uri. 1 thread per core. Dar nu vad ce ar schimba asta. Problema este ca apare overhead de la inserarea, inainte si dupa anumite zone de cod, a codului de setare a cancel-abilitatii thread-ului. Folosind thread-uri nu vad cum pot sa scap de acel overhead. Si apar foarte sus in profiling. Ai idee cum pot sa scap de overhead? Evident, la procese nu apare. > t. > > 2015-09-02 6:47 GMT+03:00 Catalin(ux) M. BOIE <[email protected]>: > >> Salut. >> >> Lucrind la un web server folosind libraria Conn (LGPL, la mine pe site) >> am trecut de la procese la thread-uri. Si am avut o surpriza mare. >> La profiling imi aparea o functie foarte des: __libc_disable_asynccancel, >> __libc_enable_asynccancel, __pthread_disable_asynccancel, >> __pthread_enable_asynccancel. Toate 4 in primele 15 intrari, ordonate dupa >> cit timp dureaza. Cea ce doare. >> Asa ca am cautat ce fac aceste functii. Se pare ca au treaba cu functia >> pthread_cancel; pare ca o tona de locuri din cod sint invelite in >> disable/enable cancel. Si asta costa. Cel putin se observa in valgrind, >> dar daca imi aduc aminte, am observat si la timpul de executie. >> >> Deci, daca poti sa mergi cu procese, uita de thread-uri. >> Si procesele le poti mapa pe CPU-uri diferite cu >> pthread_attr_setaffinity_np. >> La thread-uri, poti partaza usor datele, dar trebuie sa ai grija cum. >> Foarte probabil o sa ai nevoie de functiile specifice de locking alre >> pthread sau de RCU (userspace-rcu, recomandat). >> >> -- >> Catalin(ux) M. BOIE >> http://kernel.embedromix.ro/ >> >> On Tue, 1 Sep 2015, Alex 'CAVE' Cernat wrote: >> >>> Salut >>> >>> Am mai lucrat cu multiprocess prin facultate, si de atunci pe ici pe >>> colo, treaba e simpla: fork() * n, n copii ale datelor, wait() & >>> friends, toata lumea fericita. >>> >>> Insa (mai nou ... sau mai vechi, ca e de multi ani), thread-urile au un >>> overhead mult mai mic decat procesele, dar din cate am inteles lucreaza >>> cu acelasi set de date, ceea ce nu e bine, pentru ca pe mine ma >>> intereseaza sa execut in paralel aceeasi bucata de cod dar pentru mai >>> multe seturi de date. >>> >>> Practic ma intereseaza sa paralelizez ceva de genul: >>> >>> operatii_de_inceput(); >>> for(i = 0; i <= N; i++) >>> operatii_in_paralel(i); <<<< paralelizare >>> operatii_de_final(); >>> >>> in cazul meu operatiile de final (daca exista) nu se bazeaza pe cele in >>> paralel (decat cel mult niste coduri de ok / eroare), astfel incat cu >>> procese le-as putea scoate usor, dar daca se poate cu thread-uri si e >>> mai performant ... de ce nu ? >>> >>> problema la care nu-i dau de cap (cel mai probabil pentru ca nu am >>> inteles inca prea bine cum functioneaza threadurile) este cum fac o >>> copie locala a unei variabile, astfel incat variabila respectiva sa aiba >>> valorea doar pentru threadul respectiv, in alt thread putand avea o alta >>> valoare, iar o asignare a acelei variabile intr-un thread sa nu >>> influenteze valoarea aceleiasi variabile dintr-un altul >>> >>> rezumand, in principiu ma intereseaza daca se poate face exact acelasi >>> lucru ce as putea sa fac cu multiproces ('copie' a datelor), dar >>> folosind threaduri (cel putin unele variabile sa fie 'locale' threadului) >>> >>> Mersi >>> Alex >>> _______________________________________________ >>> RLUG mailing list >>> [email protected] >>> http://lists.lug.ro/mailman/listinfo/rlug >>> >> _______________________________________________ >> RLUG mailing list >> [email protected] >> http://lists.lug.ro/mailman/listinfo/rlug >> > _______________________________________________ > RLUG mailing list > [email protected] > http://lists.lug.ro/mailman/listinfo/rlug > _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
