bravo pentru sapaturi! io ma ocupam in thread-uri numai de matematecariisme. deh, asta era pasiunea mea atunci.
t. 2015-09-04 8:01 GMT+03:00 Catalin(ux) M. BOIE <[email protected]>: > Salut. > > M-am apucat sa studiez problema si asta e ce am gasit: > > (gdb) disassemble epoll_wait > Dump of assembler code for function epoll_wait: > 0x00007ffff78ff160 <+0>: cmpl $0x0,0x2bc659(%rip) # > 0x7ffff7bbb7c0 <__libc_multiple_threads> > 0x00007ffff78ff167 <+7>: jne 0x7ffff78ff17c <epoll_wait+28> > 0x00007ffff78ff169 <+0>: mov %rcx,%r10 > 0x00007ffff78ff16c <+3>: mov $0xe8,%eax > 0x00007ffff78ff171 <+8>: syscall > 0x00007ffff78ff173 <+10>: cmp $0xfffffffffffff001,%rax > 0x00007ffff78ff179 <+16>: jae 0x7ffff78ff1af <epoll_wait+79> > 0x00007ffff78ff17b <+18>: retq > 0x00007ffff78ff17c <+28>: sub $0x8,%rsp > 0x00007ffff78ff180 <+32>: callq 0x7ffff790c630 > <__libc_enable_asynccancel> > 0x00007ffff78ff185 <+37>: mov %rax,(%rsp) > 0x00007ffff78ff189 <+41>: mov %rcx,%r10 > 0x00007ffff78ff18c <+44>: mov $0xe8,%eax > 0x00007ffff78ff191 <+49>: syscall > Aici e epoll_wait > 0x00007ffff78ff193 <+51>: mov (%rsp),%rdi > 0x00007ffff78ff197 <+55>: mov %rax,%rdx > 0x00007ffff78ff19a <+58>: callq 0x7ffff790c690 > <__libc_disable_asynccancel> > 0x00007ffff78ff19f <+63>: mov %rdx,%rax > 0x00007ffff78ff1a2 <+66>: add $0x8,%rsp > 0x00007ffff78ff1a6 <+70>: cmp $0xfffffffffffff001,%rax > 0x00007ffff78ff1ac <+76>: jae 0x7ffff78ff1af <epoll_wait+79> > > > Dupa cum se observa, epoll_wait este inconjurat de un *_asynccancel. > Care sint implementate cu futex-i. Care sint 'light', dar, mult mai scumpi > decit 'nimic'. Si asta se vede in profiling perfect: > > > -------------------------------------------------------------------------------- > Ir I1mr ILmr Dr D1mr DLmr Dw D1mw DLmw Bc Bcm > Bi Bim file:function > > -------------------------------------------------------------------------------- > 958,390 1,147 138 273,249 60 1 196,462 979 914 113,819 3,104 > 57,236 19,158 ???:??? > 501,410 7 7 160,414 0 0 160,404 58 0 60,165 73 > 0 0 ???:Log > 107,328 1 1 26,832 3 0 0 0 0 26,832 0 > 0 0 ???:__libc_disable_asynccancel > 98,417 2 2 26,841 2 0 0 0 0 26,841 0 > 0 0 ???:__libc_enable_asynccancel > 86,000 5 5 30,000 0 0 16,000 2 1 6,000 4 > 0 0 ???:Conn_enqueue_wait > 76,000 7 7 14,000 2 1 18,000 9 6 12,000 3 > 0 0 ???:Conn_printf > > (Scuze pentru liniile lungi.) > > Deci, in thread-uri, daca ai multe syscall-uri, vei plati acest cost. > Pe cind la procese obisnuite nu. > > Daca faci doar calcule matematice (putine syscall-uri), acest cost chiar > nu conteaza. > > Am ajuns la concluzia ca pentru un webserver performant, thread-urile nu > ajuta, dimpotriva. > > Cind o sa am timp sa reiau lucrul la web server, o sa compar performantele > si o sa le postez aici, daca o sa-mi mai aduc aminte... ;) > > On Thu, 3 Sep 2015, tiberiu socaciu wrote: > > > acum ce spun e poveste, din cele traite de mine: threaduri 1/core -- > > corect!, incearca sa nu faci nimic pompos in thread-uri (IO sau comun > icare > > sau etc). eu am folosit 2 threaduri la implementarea unui ADI pentru un > PDE > > cu 2 dimensiuni spatiale, la care am reusit sa rup operatorul ecuatiei in > > doua. cu un doctorand de la ubb (cu care colaborez de aproape un an si pe > > care il "co-indrum") incerc sa rupem operatorul n+1 dimensional (spatial) > > si sa vedem daca putem pune de o ADI. altfel, cu procese era putintel > > (parca) mai incetut (asta fuse acum 1000 de ani cand mai scriam cod; acum > > numai latru si urmaresc minciunele). > > > > t. > > > > 2015-09-03 7:46 GMT+03:00 Catalin(ux) M. BOIE <[email protected]>: > > > >> 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 > >> > > _______________________________________________ > > RLUG mailing list > > [email protected] > > http://lists.lug.ro/mailman/listinfo/rlug > > > > -- > Catalin(ux) M. BOIE > http://kernel.embedromix.ro/ > _______________________________________________ > RLUG mailing list > [email protected] > http://lists.lug.ro/mailman/listinfo/rlug > _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
