☰

» »

niti (threads)

niti (threads)

1
2
»

jype ::

Češko.

Poskusi tole:

vgrep.py:
#!/usr/bin/env python

import sys

allfiles = dict()
for line in file(sys.argv[1]):
  allfiles[line.strip()] = 1

for line in sys.stdin:
  if line.strip() not in allfiles:
    print line.strip()


In potem namesto

find / | grep -v -f allfiles

poženeš

find / | python vgrep.py allfiles

noraguta ::

no če smo končali z gentoo helpdeskom, ter nadaljujemo na temo.

kar v praksi pomeni le , hitrejše kodiranje(nekaj več scenarijev obdelanih). ne rešuje pa kaj bistveno osnovnih problemov paralelizacije
Absolutno. Ampak to, da ponavadi samo kodiranje (in debugganje) ni čisto trivialno, je glavni vzrok, da se multithreading tako malo uporablja, tudi tam, kjer je problem čisto preprost in bi na relativno enostaven način pridobil ogromno - tega pa je precej.

pri debugiranju paralel fx pomaga malo ali skoraj nič, ponavadi ga celo dodatno zakomplicira(nekaj generirane kode ne rešuje problemov kot jih ne locki , semaforji etc. tega se zaveda celo sam duffy http://www.bluebytesoftware.com/blog/20...
nad .NETom precej bolše pristope k paralelizaciji že nekaj časa nazaj imela Cω ter nemerle.

no pa še citat iz zgornjega linka
Many folks with embarrassingly parallel algorithms will succeed just fine in a shared memory + locks + condition variables world, and indeed have already begun to do so. And specialized tools -- like GPGPU programming -- have popped up that, when small kernels of computations are written in a highly constrained way, will parallelize, sometimes impressively. Is this enough? Perhaps for the next 5 years, but surely not much longer after that.
Pust' ot pobyedy k pobyedye vyedyot!

Zgodovina sprememb…

  • spremenilo: noraguta ()

BigWhale ::

kar v praksi pomeni le , hitrejše kodiranje(nekaj več scenarijev obdelanih). ne rešuje pa kaj bistveno osnovnih problemov paralelizacije
Absolutno. Ampak to, da ponavadi samo kodiranje (in debugganje) ni čisto trivialno, je glavni vzrok, da se multithreading tako malo uporablja, tudi tam, kjer je problem čisto preprost in bi na relativno enostaven način pridobil ogromno - tega pa je precej.


Kodiranje threadov ni tko zlo problematicno. Po mojem se ga lahko loti vsak, ki ima vsaj nekaj kilometrine. Debugiranje pa tudi, nekaj printf() stavkov nametat v kodo je najmanjsi problem. Gre precej hitreje in lazje kot z raznimi visual debuggerji.

Tr0n ::

Bolj problem je proper sinhronizacija niti.

Mavrik ::

Niti ne, dokler točno veš kaj delaš in kaj se dogaja v programu.

Po mojih izkušnjah so se problemi predvsem pojavljali pri uporabi kakih slabo dokumentiranih eksternih knjižnic, pri katerih ni nikoli čist jasno če so thread safe ali ne.
The truth is rarely pure and never simple.

darkolord ::

Gre precej hitreje in lazje kot z raznimi visual debuggerji.
To pa res ne.

noraguta ::

Niti ne, dokler točno veš kaj delaš in kaj se dogaja v programu.

kar je pri konkuriranju procesov za en kos pomnilnika seveda trivialen problem.

Gre precej hitreje in lazje kot z raznimi visual debuggerji.

To pa res ne


dejstvo je , da in eno kakor drugo spremenita flow aplikacije.Če je robusno spisano mogoče pridemo še skozi v ostalem pa ne.
Pust' ot pobyedy k pobyedye vyedyot!

techfreak :) ::

Debugiranje pa tudi, nekaj printf() stavkov nametat v kodo je najmanjsi problem. Gre precej hitreje in lazje kot z raznimi visual debuggerji.

Ja pri treh for zankah je printf() lahek način debugganja. Če pa imaš kaj več je pa en normalen debugger VELIKO bolj primeren.

Binji ::

Debugiranje pa tudi, nekaj printf() stavkov nametat v kodo je najmanjsi problem. Gre precej hitreje in lazje kot z raznimi visual debuggerji.

Ja pri treh for zankah je printf() lahek način debugganja. Če pa imaš kaj več je pa en normalen debugger VELIKO bolj primeren.

Pri threadih "normalen" debugger velikokrat odpove, ker ko debugiras se stvar lahko odvija drastično drugače kot pa pri izvajanju.
Kdor ne navija ni Slovenc, hej, hej, hej!

BlueRunner ::

Samo namesto printf greš na fprintf/java.util.logging.Logger/System.Diagnostics.Trace. Instrumentalizacija celotne aplikacije.

Včasih je nekaj podobnega avtomatično naredil Rational Purify. Kakšno pa je kaj danes stanje s temi orodji za transparentno opremljanje aplikacije z diagnostično kodo?

Jst ::

>Pri threadih "normalen" debugger velikokrat odpove, ker ko debugiras se
>stvar lahko odvija drastično drugače kot pa pri izvajanju.

Fora je tudi v temu, da programer sploh ne ve, koliko niti se bo generiralo oz. lahko obstajajo določeni pogoji za generiranje niti. Mavrik: Kako boš to debugiral z Visual debuggerjem?


Brane: glede tega, da že veš, kako spraviti določeno nit na določeno jedro, ne veš pa, kako bi jih štartal sinhrono, ti lahko povem en dirty hack: Na začetku vsake niti zahtevaš signal vsake, ko jih dobiš, nadaljuješ. Vse ostane v predpomnilniku dokler se scheduler ne odloči drugače. Potem se pa itak vaja ponovi.
Islam is not about "I'm right, you're wrong," but "I'm right, you're dead!"
-Wole Soyinka, Literature Nobelist
|-|-|-|-|Proton decay is a tax on existence.|-|-|-|-|

darkolord ::

Kako boš to debugiral z Visual debuggerjem?
Kaj točno? Kolko niti imaš seveda sproti vidiš. Ko izvajanje zaustaviš (npr. breakpoint ali ročno), za vsako nit vidiš, kje točno se trenutno nahaja... lahko seveda preklopiš na drugo nit in se ukvarjaš z njo

Brane2 ::

Brane: glede tega, da že veš, kako spraviti določeno nit na določeno jedro, ne veš pa, kako bi jih štartal sinhrono, ti lahko povem en dirty hack: Na začetku vsake niti zahtevaš signal vsake, ko jih dobiš, nadaljuješ. Vse ostane v predpomnilniku dokler se scheduler ne odloči drugače. Potem se pa itak vaja ponovi.


Ni videt. Signali pridejo na Linuxu ob sistemskih klicih, ne pa trenutno. Tudi medtem, ko ti zbiraš signale, ne moreš vedeti, koliko časa bodo določene niti "ostale s tabo", saj se jim scheduling lahko izteče.
Tudi če jih ujameš, je problem rešen samo do naslednjega timeslicea, pa še to z velikimi režijskimi stroški, ki verjetno presegajo koristi.

Moral bi imeti rešitev, kjer bi zahteval sinhronost skupine jeder in vsako jedro bi moralo pasti v thread, ki bi vedel, koliko jeder je padlo v multithread in po možnosti številko svojega threada. Takrat se lahko odločijo za optimalno procesiranje.

Definitivno bo treba poštimat to v kaki naslednji verziji kernela IMHO.
On the journey of life, I chose the psycho path.

noraguta ::

afinitete lahko določaš a se izkaže , da je user(programer) praviloma nerodnejši od schedulerja.

http://www.codeproject.com/KB/books/thr...

http://www.codeproject.com/Articles/356...

pa ne zdej člankov vzet kot suho zlato.
Pust' ot pobyedy k pobyedye vyedyot!

BigWhale ::

As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugging sessions are transient.
– Pike, R., and Kernighan, B. W., The Practice of Programming


Zato. :)

Zgodovina sprememb…

  • spremenil: BigWhale ()

darkolord ::

As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugging sessions are transient.
– Pike, R., and Kernighan, B. W., The Practice of Programming


Zato. :)
That's soooo last millenium. Seveda, če nimaš dobrih orodij, je verjetno res tako (in veliko jih je res tudi dejansko zanič). Z dobrimi orodji pa to počneš izjemno hitro in učinkovito (v sekundi dobim več relevantnih informacij, kot jih s print statementi nakucaš v nevem kolk časa). Ročen step-through (s sprotno evaluacijo stacka) je nekaj najboljšega po narezanem kruhu, kar se tiče debugginga.

Debugging je mnogokrat učinkovitejši od logginga. Tko, like par tisočkrat. Problem je edin, da so nekateri še mal "zadi" (tehnofobi?) in se jim to zdi kot kšna ovira (se ga bojijo) namesto super učinkovit pripomoček.

Zgodovina sprememb…

Mavrik ::

Na žalost niti približno ni najboljši pri debugganju niti. Ker ti debugger praktično takoj opazno spremeni situacijo izvajanja. Predvsem ga upočasni in obenem ti tudi ne pomaga opazno pri iskanju concurrency problemov ter race conditionov, ker ponavadi le-ti ob počasnem step-through izvajanju pogosto izginejo.

Še posebej se problem izpostavi, če se ukvarjaš z nitmi, ki procesirajo I/O, še posebej z mrežo, ker te računalnik na drugem koncu ne čaka in te preprosto timeoutne prej kot karkoli uporabnega zvediš (obenem pa to spet ni normalno izvajanje programa).

Debuggerji so hudo uporabne stvarce, samo pri debuganju threaded programov niso tako zelo uporabni, še posebej ko debugaš probleme s sihronizacijo.
The truth is rarely pure and never simple.

BlueRunner ::

Razhroščevalnik:
- če razhroščujem eno nit, to pomeni, da si verjetno nisem dobro razdelal algoritma
- za razhroščevanje pretekavanj je neuporaben
- za razhroščevanje sinhronizacije je neuporaben

Ali je razhroščevalnik potem samo potuha tistim, ki se jim ne da programirati z listom papirja in svinčnikom?

jype ::

BlueRunner> Ali je razhroščevalnik potem samo potuha tistim, ki se jim ne da programirati z listom papirja in svinčnikom?

Am, ne. Razhroščevalnik (i.e. gdb) potrebuješ zato, da lahko program, ki si ga pozabil zagnat v screen(1)u, spraviš vanj naknadno.

darkolord ::

Predvsem ga upočasni in obenem ti tudi ne pomaga opazno pri iskanju concurrency problemov ter race conditionov, ker ponavadi le-ti ob počasnem step-through izvajanju pogosto izginejo.
Tle si tut z loggingom direkt ne pomagaš prov dosti. Z debugganjem lahko naprimer primerjaš izvajanje (in to celo enostano pol-avtomatiziraš), ko se stvar včasih izvede pravilno in takrat ko se ne (kar je pogosto pri takih zadevah). Posamezne rezultate pa potem vzameš pod drobnogled.

- če razhroščujem eno nit, to pomeni, da si verjetno nisem dobro razdelal algoritma
lahko imaš tudi problem z vhodnimi podatki v algoritem, zunanjimi faktorji ali enostavno "tipkarskimi" napakami

Ali je razhroščevalnik potem samo potuha tistim, ki se jim ne da programirati z listom papirja in svinčnikom?
Pripomoček, s katerim najhitreje preveriš, če dejanski flow programa ujema s tistim, ki ga imaš na listu.

Zgodovina sprememb…

WarpedGone ::

Debuggerji so hudo uporabne stvarce, samo pri debuganju threaded programov niso tako zelo uporabni, še posebej ko debugaš probleme s sihronizacijo.

Tole mi je jasno. Kak je pol trenuten "state of the art" pristop k debuganju multithreaded zadev?

Na pamet mi pade samo debugiranje celotne virtualne mašine znotraj katere tečejo vsi threadi. Pause tako ustavi celo mašino in vse niti hkrati. Single-step je pe že nedefiniran.
Zbogom in hvala za vse ribe

darkolord ::

V debuggerju lahko tudi ustaviš vse niti hkrati (lahko ko določena nit pride do breakpointa, lahko ko vse niti pridejo do breakpointa) in nato eno vzameš pod drobnogled, ostale pa po želji spustiš naprej; lahko pa tudi ustaviš samo eno, medtem ko ostale pustiš na miru

Zgodovina sprememb…

kopernik ::

Mah, pri nitih je isto kot pri vsakem drugem problemu. Z večanjem kompleksnosti na eni strani (št. niti in raznolikost niti), se veča kompleksnost na drugi (debuggiranje oz. nasplošno kar testiranje). Primerček : z večanjem števila niti, ki prek read/write lockov dostopajo do deljenega resorsa, se npr. v Javi5 implementaciji lockov počasi "zmeša" (ne moreš priti do write locka, ko je preveč zaseženih read lockov), v Javi6 je ta problem omiljen. To ugotoviti s kakšnim step-by-step debuggiranjem je praktično nemogoče.

Zgodovina sprememb…

  • spremenil: kopernik ()

Tr0n ::

mnogokrat učinkovitejši od logginga. Tko, like par tisočkrat. Problem je edin, da so nekateri še mal "zadi" (tehnofobi?) in se jim to zdi kot kšna ovira (se ga bojijo) namesto super učinkovit pripomoček.

Ne, to so samo linuxasi, ki nimajo pametnega debugerja. :)

jype ::

Tr0n> Ne, to so samo linuxasi, ki nimajo pametnega debugerja. :)

Če najdeš zmogljivejši debugger od gdbja, pozvoni.

WarpedOne> Kak je pol trenuten "state of the art" pristop k debuganju multithreaded zadev?

Prepisovanje v sodobnejše modele sočasnega izvajanja.

noraguta ::

Da ne bo pomote, sam še vedno cenim debuger kot solidno orodje a dandanašnji debugerji z actor pristopom ne ve kaj dosti počet. Tu je pomemben še compiler ter runtime. Ampak zamahnit z roko, da so stvari trivialne se mi zdi pa smešno. Če je problem trivialen pač ni problema, nitkanje v linuxu, windowsih je že stara stvar, ko pa se lotiš kar koli kompleksnejšega pa bog si ga vedi kdaj hudič udari naplan, se mi je že zgodilo, da šele na produkcijski mašini.
No ja pri mainstream orodjih kaže, da se je predvsem ogibati global variables, ter mutablov ako se le da. Tedaj je tudi lociranje napak lažje.

Glede designa na papirju imam pa zadržke le ker še nisem videl popolnega koderja.
Pust' ot pobyedy k pobyedye vyedyot!

Zgodovina sprememb…

  • polepsal: Mavrik ()

Jst ::

Debugger je ključno orodje pri programiranju; prej sem preveč enostransko napisal odgovor. Vendar ima svoje omejitve, ki se jih moraš zavedati. Včasih je kakšen problem v debugerju moč poiskati po urah in urah buljenja v monitor, dočim lahko težavo odkriješ z simple dev.log datoteko in a manner of minutes.
Islam is not about "I'm right, you're wrong," but "I'm right, you're dead!"
-Wole Soyinka, Literature Nobelist
|-|-|-|-|Proton decay is a tax on existence.|-|-|-|-|

noraguta ::

če koga slučajno zanima
http://msdn.microsoft.com/en-us/devlabs...
sicer pa upajmo da se TM v bljižni prihodnosti preseli na hw layer.
Pust' ot pobyedy k pobyedye vyedyot!
1
2
»

Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Asinhronost

Oddelek: Programiranje		122565 (2334) mihies
»

Hitrost Linuxovega jedra skozi čas (strani: 1 2 3 )

Oddelek: Novice / Operacijski sistemi		10826334 (21614) Icematxyz
»

c# debugger noce ujeti exceptiona!!

Oddelek: Programiranje		161493 (1164) BlueRunner
»

Niti (threads)

Oddelek: Programiranje		141876 (1544) snow
»

Desktop aplikacije večinoma niso multithreaded??? (strani: 1 2 )

Oddelek: Programiranje		554880 (4126) Gundolf

Več podobnih tem