Desktop aplikacije večinoma niso multithreaded???

Ravnokar si presegel mindset povprecnega programerja, bravo. Zakaj pa Microsoft in Sun tega ne podprejo v svojih najbolj "sodobnih" toolih? Ker prodajajo vedno najsirsemu moznemu delu kupcev. Oziroma, da ne bom zvenel grobo - najvecji del problemov, ki jih ljudje resuje so povprecni in hkrati povprecne resitve so v povprecju dovolj dobre .

Drugace je ta ideja v akademskih krogih pravzaprav ze dolgo znana, recimo razne implementacije, ki imajo lightweight taske:

http://www.sac-home.org/
tocno to kar ti opisujes

http://portal.acm.org/citation.cfm?id=6...
qlisp - lisp z implementacijo t.i. "prihodnosti" za doseganje sinhronizacije paralelnih taskov

http://www.macs.hw.ac.uk/~dsg/gph/
in a nutshell: oznacis kjer se haskell koda izvaja paralelno

http://www.erlang.org/
asinhroni vzporedni objekti, za doseganje ultra robustnosti

http://www.mozart-oz.org/
teh ne razumem cisto, ampak zgleda ultrafensi :)

Zakaj pa Microsoft in Sun tega ne podprejo v svojih najbolj "sodobnih" toolih? Ker prodajajo vedno najsirsemu moznemu delu kupcev.

Halo! Jutri dobimo večjedrne procesorje v vsako kišto. In velikokrat slišim, kako večina programov deluje samo enonitno. In ne mi rečt, da se s tem problemom ne bodo morali soočiti tudi taveliki.

Jaz sem si pogledal tiste linke, ki jih je dobavil 64202, ampak ti se nanašajo na bolj preproste, doma napisane jezike. Še najbližje je res sac-home, ampak kolikor jaz to razumem ta program naredi zunanjo knjižnico z multithreaded kodo (dll), ki jo lahko vključiš v svoj program.

Jaz bi dopolnil pribljubljen kompajler: npr. gcc. Ne vem koliko ljudi ima voljo, da se ubada z nečim, kar bi na dvoaliveč procesorski platformi teklo hitreje 40%. Ni to takšen pridobitek, da bi se splačalo veliko truditi zanj.

for, foreach, while so najbolj osnovni konstrukti, ki jih zna uporabljati vsak in se tudi pogosto uporabljajo. No, seveda pa mora biti programer toliko pameten, da ve, ali računa Fibonačijevo zaporedje, oziroma ali je to, kar se z elementom naredi neodvisno od tega, kar se naredi s predhodnim.

CCfly (namesto da scheduling delamo za vsak posamezen element): če bi bil 'element dispatching' pravilno narejen, bi bila fiksna razdelitev počasnejša. Recimo, da je ene elemente hitreje izračunati kot drugo - prestavljaj si šprint na 100m z 8 tekači (predstavljaj si procesorje) - ko pride tekač na cilj mora čakati ostale, da opravijo svojo nalogo.

Število niti mora biti na večprocesorkem sistemu od 2 do (število procesorjev-1). In koliko je procesorjev najbolje ve operacijski sistem. Ko so narejeni ti štirje/osem TSSjev, compilerjev loop control ob koncu ene iteracije samo zahteva NovProstiElement. Kar (odvisno od spremenljivke) ne bi smelo zahtevati več kot 20 procesorjevih urnih ciklov.

Edini - in največji problem je dodelitev pomnilnika za spremenljivke, ki se res spreminjajo v tej zanki ter kako določiti OUTPUT spremenljivko.

output spremenljivko bi označil z besedo 'common' npr. - common mycommonvar[100].

Pomnilnik za interloop spremenljivke bi se določil dinamično: vsak nov TSS ima ves pomnilnik označen Read-Only (vsak TSS ima svoj CR3 -address of the page directory), razen onih spremenljivk, ki so označene s COMMON in pomnilnika OS, ki ostane tak kot je.
Prvo pisanje na ReadOnly memory pokliče Exception 0E, ki alocira novih 4K, skopira vanj vsebino originalnega pomnilnika in dovoli spreminjanje tega kosa pomnilnika.

Compiler lahko pri tem pomaga, da pove v katerem kosu pomnilnika so spremenljivke, ki se bodo spreminjale in že vnaprej določi posebej Writable strani za vsak TSS posebej. Compiler lahko tudi alocira tiste spremenljivke, ki se spreminjajo znotraj loopa zaporedno (da niso fragmentirane po več 4K straneh, če so lahko v eni).

No ja, kaj mislite?

Tole z Microsoftovimi profiti je brez veze. Oni hočejo imeti razvojna orodja zastonj, samo toliko zaračunajo da se Borland drži nad vodo. Če še niste videli: Join Microsoft Empower for ISVs za 375$.
Šenkajo 5 Desktop Win+Office in 1 WinServer+SQL ter MSDN Universal Subscription za 1 leto (podaljšaš lahko še za 1 leto). Za start-up firmico ni, da ni.
Ampak tole s profiti je offtopic. Mene zanima nitenje.

Take zanke bi bile fina zadeva ampak uporabna samo v tocno dolocenih primerih...

Poskusam se spomniti, kdaj sem nazadnje uporabil for zanko, ki bi jo lahko takole razparceliral... :)

U pa se en projekt:
http://www.research.att.com/projects/cy...
(isti lab. kot c++ bjarne!:)

Sicer stable verzija nima multithreadinga, sem pa nekje glede tega nasel paper, ki opisuje, kako v cyclone memory management "100%" varno vkljuciti threade (precej bolj varno kot v c/c++/java vsaj:). Malo podobno kot tvoja razlaga.

Sicer v splosnem paralelnost ni uporabna samo zaradi raw prepustnosti, ampak tudi zaradi odzivnosti in preprostosti programiranja. Paralelne for zanke so samo (majhna) podmnozica raznih moznih paralelnih konstruktov, ki ti izjemno olajsajo pisanje programov, ki so polni asinhronih eventov. Recimo network programiranje, gui, ...

Sicer v splosnem paralelnost ni uporabna samo zaradi raw prepustnosti, ampak tudi zaradi odzivnosti in preprostosti programiranja.

Cakaj malo, ali ti pravis da je forTS bolj enostavno od for? Aja, BTW bistri, tvoje ime ni najbolj primerno, morda bi bilo namesto ThreadSafe bolje kaj ala Parallel?

Paralelne for zanke so samo (majhna) podmnozica raznih moznih paralelnih konstruktov, ki ti izjemno olajsajo pisanje programov, ki so polni asinhronih eventov. Recimo network programiranje, gui, ...

Morda v prihodnosti, ko bo multithreading res vecinoma deloval na multiplih procesorjih. Poleg tega je za GUI najbolje uporabiti message queue. Nasploh, da bi za obvladovanje asinhronih elementov uporabil tak tip zanke?? :/

Kje vidis da mesam ljudi? Prejsnji post? Prvi stavek se nanasa nate (avtorja citiranega besedila), v drugem se pa tudi direktno obrnem na cloveka, ki je zacel s to temo in podal ime forTS. Ali si mislil kaksno drugacno mesanje?

No lightweight threadi so ze vredu. Pri velikem stevilu threadov pa tako ali tako ze rabis dokaj pameten scheduler ce zelis imeti korist in ne izgube. Kar se enostavnosti tice imas kar prav. Upam da bo C# kmalu dodal podporo za kaj takega . Jaz ponavadi prvo pogledam na hitrost in ucinkovitost in mi zato pristop ni vsec. Pri 1000+ threadih lahko ze kar pozabis na lokalnost podatkov, kakor sem ze omenil pade tudi hitrost preklaplanja in naraste potreba po varovanju podatkov med razlicnimi threadi.

Kje bi ti uporabil na tisoce threadow?

> Kje vidis da mesam ljudi? Prejsnji post? Prvi stavek se nanasa nate (avtorja citiranega besedila), v drugem se pa tudi direktno obrnem na cloveka, ki je zacel s to temo in podal ime forTS. Ali si mislil kaksno drugacno mesanje?

Ah ok. Sem naredil context switch med paragrafom, ne med stavkoma :).

> No lightweight threadi so ze vredu. Pri velikem stevilu threadov pa tako ali tako ze rabis dokaj pameten scheduler ce zelis imeti korist in ne izgube.

Ta problem je zelo odvisen od modela paralelnosti, ki ga uporabljas. Ne recem, da obstajajo neke 100% resitve, ampak se da gotovo veliko narediti. Moj pogled na to je, da so threadi, mutexi, message que-ji, condition variables (kaksen je slo izraz za to?), ipd. nekaksen assembler paralelnega programiranja, pa se to tak grd CISC.

> Kje bi ti uporabil na tisoce threadow?

Bom podal primerjavo med javo, in java like jezikom L, ki bi rabil toliko threadov:

Java: objekt (kos rama + metode)
L: asinhron objekt (kos rama + metode + thread)

Java: sinhron klic metode, ki vedno blokira
L: asinhron message z ali brez "prihodnosti" (qlisp style future), ki predstavlja rezultat operacije, klici ne blokirajo, handlajo se v threadu objekta zaporedno (erlang)

Java: kot posledica java (jvm) uporablja stack za temporary lokalne spremenljivke
L: uporablja queue za temporary qlisp prihodnosti, take "heavy weight" spremenljivke

Koristi:
- program se da izvajati prakticno gledano toliko paralelno, kolikor dopusca tvoja resitev problema (v kontrast si predstavljaj rocno hendlanje stotine med sabo odvisnih threadov v javi)
- robustnost, to je posledica neblokiranja na nivoju metod, cel program se obnasa bolj "organizem", kjer odpoved enega dela ne povzroci celotne odpovedi. V javi lahko mimogrede zastrikas komplet program z enim samim deadlockom, starvationom, etc.

Tezave:
- transakcije, v tako hudo paralelnem okolju je tezko videti kaj se res dogaja in v kaksnem vrstnem redu (to se da verjetno v splosnem resiti, ni pa easy)
- niso vsi problem lepo resljivi s takim programiranjem, ekvivalentno z razliko med message passing in shared memory modelom paralelnosti

Vesoljec: exactly :). L je eden izmed moznih jezikov za tak racunalnik.

> Slisi se zanimivo. Vse kar bi za zacetek rabili je nek CPU, sestavljen iz kaksne 1024 enostavnih RISC procesorckov (po moje povsem izvedljivo iz tehnicnega vidika, verjetno pa ne iz ekonomskega) ter tak L jezik (je ta L ze definiran ali je bilo to popolnoma teoreticno razmisljanje?).

To je v bistvu erlang, samo da ima L tudi qlisp futures. Pure message passing, kot ga zganja erlang, je tecen za splosno paralelno programiranje.

Drugace RISC procesorcki :), "native" jezik je pa occam
Transputer

> Mhm, morda bi bilo dobro dodati se strojno podporo za critical sectione oz. mutexe in to je to. Seveda bi bilo programiranje tegal sistema smiselno le na ozki mnozici problemov, morda pa bi se izkazalo, da se arhitekturo bolj splaca siriti v tej smeri kot pa v smeri visana frekvence in dodajanja kompliciranih ukazov.

Mutexi in critical sectioni so potrebni samo v shared memory modelu. (Pure) message passing ne rabi explicitne sinhronizacije. Res pa je, da potem moras na visjem nivoju implicitno simulirati "sinhronizacijo". To trenutno se malo raziskujem.

Glede sirine problemov... se mi zdi, da so ljudje do sedaj resevali probleme, ki so bolj "shared memory narave". Sedaj pa vedno bolj postaja popularno mrezno neodvisno programiranje, se celo MS je to zaznal in implementiral web services. Ironicno glede na to, koliko je trajalo v 90s, da je MS "pokopcal" internet.

Se ena zanimivost: internet. To je najvecji message passing sistem na zemlji, zelo zanesljiv - ce en node pade dol, se vedno celota deluje. In guess what, internet nima mutexov, pa cisto fajn deluje :).

Zakaj ne bi tudi jeziki te paradigme direktno podprli?

tale L, kakšen odzivni čas bi imel? 10^-3 sekundna skala zna biti prevelika za nekatere desktop aplikacije na 10ⁿ cpu enotah.

Ce bi se operacijski sistemi bolje podprli light weight taske, potem pa sploh.

Fora pri lightweight taskih ali threadih je v tem, da niso podprti s strani OSja, ker je vsak klic OS funkcij prehud penalty glede performanc.

Vseeno ne vem, zakaj bi morala biti podpora s strani OSa (najprej se mi je zdelo, da se to nanasa na primer ko imas le en procesor, zdaj pa ne vem vec kaj tocno si mislil). Ce imas en proc, potem si sam schedulas lightweight niti (ker ce jih pustis OSu, ne bojo vec lightweight). Ce imas pa dva ali vec, si pa naredis vec niti in OSu nekako poves, da bi rad, da vsaka tece na svojem procu (mislim da je to ze sedaj mozno). Nato si spet sam schedulas svoje lightweight niti znotraj od OSa dobljenih heavyweight niti.

Ze to je tezko narediti zadovoljivo hitro, kaj sele, da bi kake message posiljal OSu (se sploh ce so to windowsi).

> Vseeno ne vem, zakaj bi morala biti podpora s strani OSa (najprej se mi je zdelo, da se to nanasa na primer ko imas le en procesor, zdaj pa ne vem vec kaj tocno si mislil). Ce imas en proc, potem si sam schedulas lightweight niti (ker ce jih pustis OSu, ne bojo vec lightweight). Ce imas pa dva ali vec, si pa naredis vec niti in OSu nekako poves, da bi rad, da vsaka tece na svojem procu (mislim da je to ze sedaj mozno). Nato si spet sam schedulas svoje lightweight niti znotraj od OSa dobljenih heavyweight niti.

U bistvu mas prav, kaj vec kot to niti ne rabis. Malo sem zabluzil :). Vecino casa nisem ravno prevec razmisljal o konkretni implementaciji schedulerjev, bolj o jezikih, ki bi sploh izkoristili na programmer friendly way paralelnost v resitvi problema.

> Ze to je tezko narediti zadovoljivo hitro, kaj sele, da bi kake message posiljal OSu (se sploh ce so to windowsi).

FreeBSD & NetBSD delata tako - M:N threading model.

Dejstvo je, da to kar trobite, sploh ne bi tako pomagalo.

1. Računala so danes zato tako hitra, ker že veliko stvari zračuna še preden si mi tega zaželimo in zaradi predpomnilnika, ki je tako hiter kot procesor. Navaden pomnilnik NI. Ko se spraviš dodeljevat posamezne elemente procesorjem, tam zgubiš najmanj toliko časa, kot ga z večimi procesorji pridobiš. Kaki programi pa to že izkoriščajo, npr. gcc, ki kompajla na večih hkrati. Ali pa abcde (CLI cd ripper, ki je sposoben pognat več kodiranj wav v ogg naenkrat). Ampak da pa bi lomil for zanko ... to je polomija, drugače bi to že kdo počel.

2. Pa kaj potem, če ne uporabljaš programa, ki bi ti papal dva procesorja. Bodo pa na enem tekli sistemski procesi in kake malenkosti, recimo winamp, na drugem pa procesorsko zahtevna nit.

3. Ta večjedrna osnova bo podlaga za razvoj prepoznave govora. En procesor ti bo obremenjevala prepoznava govora, drugega pa ostalo. In še kaka druga zadeva v tej smeri, recimo prepoznavanje gledanja oči, da ti potem miškin kazalec ustrezno premika.

jest tudi, batch (grupiranje operacij ter podatkov) je tisto kar največ šteje! MT naj nastopi po tem...

Okey, mogoce zdaj vidim kaj hoce hruska reci :)

Glede konkretne implementacije L-ja in problema iz 1., mozni pristopi:
1. "oznacis" kodo, da das compilerju hint, kjer naj se koda zares paralelno izvaja (seli na druc proc.), to je dokaj rokodelsko, ampak se vedno obcutno lazje kot odpiranje threadov etc.
2. static analiza algoritma - ce tukaj kdo kaj zares uporabnega najde, bo to cs breakthrough :)
3. dinamicno analiza - subset tega je runtime profilanje na tipicnih vhodih, pred casom sem zasledil paralelni c compiler, ki je za relativno zapleten problem (ni bil ocitno paralelen) z delno rocno pomocjo izpeljal scheduling, ki je imel na 8-way kisti 7x pospesek, skratka uber :). zal se ne spomnim vec linka, takrat so me te zadeve sele zacele zanimati.

Kolikor jaz vem, vektorski compilerji delajo mikrooptimizacijo za zanke. Ce opazijo kak lusn for-loop, bodo to prevedli v vektorski strojni ukaz, ja? Se vedno pa rabis en makrooptimizer (sam rocno, ali pa runtime profiler), da ti pozene 10 takih mnozenj vzporedno na svojih procesorjih, ce se to splaca seveda.

Jap, tudi jaz sem to slisal, nekaj v zvezi z open multi...nekaj.. c extension. Ce te ne zanima splosni paralelizem, ampak v vecji meri premetavanje stevilk, je ta pristop seveda boljsi.

množenje matrike 2k x 2k bi se verjetno dalo razbiti na več cpu enot, ampak jest gledam na to rahlo drugače...
"the program", ki bi laufal na takih mašincah verjetno ne bi računal samo množenje matrik. to je le en sub problem, sicer velik (no ja ) ampak vseeno. meni se bolj smisleno zdi računati več parov matrik na večih enotah. če en tak loop ne razbijamo, s tem imho samo pridobimo. work sharing v pravem pomenu. to je tko kot bi poslal dva delavca kopat na isto mesto. zakaj? nej vsak svojo luknjo koplje...

MT sicer ponuja zelo lep ampak tešžak pristop k rešavanju problemov. v idealnem sistemu, bi na eni cpu enoti laufala samo ena nitka, ki jo filamo s streamom podatkov. ni lepžšega ne? zaenkrat to še ne gre, tko, v praktične namene.

kot kaže pa se strinjamo, da ima delinik dela precejšen pomen v takem sistemu. to pa lahko izvedemo v širši sliki na dva načina. prek jezika, ali pa prek "žive" aplikacije, ki poskuša pametno razdeliti delo. kaj je boljše je imo brezveze razglabljat, pač za vsako kuro se svoj žebu najde (ne poznam pregovorov ).

osebno mi je bolj všečen drugi pristop, ki pa ima določene zahteve... namreč aplikaciji in algoritmu znotraj, je potrebno funkcionalnost programa predstaviti v takem formatu, da jo on/ona zna razporediti.

> množenje matrike 2k x 2k bi se verjetno dalo razbiti na več cpu enot, ampak jest gledam na to rahlo drugače...

Mislil sem sicer primer, ko imas 10 takih mnozenj za narediti, ampak pustimo to.

> osebno mi je bolj všečen drugi pristop, ki pa ima določene zahteve... namreč aplikaciji in algoritmu znotraj, je potrebno funkcionalnost programa predstaviti v takem formatu, da jo on/ona zna razporediti.

Tocno tako je deloval tisti pristop s profilerjem. Sekljali so originalno zaporedni algoritem v c-ju, dokler ni stvar delovala ucinkovito paralelno - profiler je pa sam nasel pot, kako izkoristiti paralelnost. Ciljni rezultat je bil paralelni algoritem, ki ga clovek se ni izumil.

kar bi "mi" radi je prednost nitk, ampak brez njih samih

Kaj cem rect na ta z argumenti podprt post... strikci so za to, da si zenske najlonke obesijo gor.

Zato ker se cela tema ni sla o takih threadih, kot verjetno ti mislis (heavy weight & semaforji & other crap).

stdout stream(i) lahko tecejo v svojem threadu (light weight tasku?). Izpis dosezes tako, da posljes "output" message temu threadu. Recimo:

int main() {
output("Hello world\n") -> stdout;
return 0;
}

Objekti z lightweight taski so obicajno zaporedni (sami za sebe). Nekje se moras ustaviti :).