Ako imas manje jezgara od niti, neces dobiti na brzini. Paralelnost je prividna.

Onda danas multithreading na osobnim racunalima nema puno svrhe...
A sto je sa Hyper Threading racunalima? Jeli na njima ima ikakvih poboljsanja performansi?

Multithreading ima svrhe, ali primena nije za ubrzanje alpikacija vec za.. uh, razne stvari.. mozda je bolje da procitas neki clanak o tome jer bih trebao prilicno da pisem :)
Na HTT P4 procesorima bi mozda mogao da postignes bolje performanse ali mislim da ce to zavisiti od toga sta program radi.

Podjelu posla, realne simulacije, lakse programiranje event based aplikacija... jasno mi sve to vise manje, ali opet se svodi na skracivanje vremena potrebnog za obradu nekog posla.

Mislim da pogresno gledate na stvar. Poenta threadinga u home-computing-u nije da se ubrza neki process, vec uglavnom da se poveca responsivness aplikacije koja barata sa dugotrajnim sinhronim procesima. Ukratko, trenutno je praksa da svrha zivota sekundarnih threadova bude da su blokirani umesto glavnog thread-a.

Vecina kucnih (personalnih) kompjutera nema dual-core/chip, i za takve masine gornja primena threadova je jedina smislena primena. Deliti neki pod-process na N sekundarnih threadova nema smisla ako ne postoji N potpuno nezavisnih execution pipe-ova. Takve aplikacije se u ovom trenutku rade iskljucivo za multi-core/chip servere koji mogu da iskoriste taj pristup. Sam program zahteva odredjene kompromise u dizajnu i kodu kako bi se osiguralo da tih N threadova sto manje blokiraju jedan drugog uz obavezan eksplicitni processor affinity.

Narafski, pustiti takvu aplikaciju na single-core/chip masini ce rezultovati sporijim izvrsenjem procesa (ako uopste i krene da radi) nego da je sve linearno odradio jedan sekundarni thread, ako ni zbog cega drugog, onda zbog overhead-a koji pravi context switching. Proci ce jos neko vreme dok dual-core ne postane kucni standard pa ce se tek tada poceti pojavljivati prave MT aplikacije za kucnu primenu. Za sada su prvi nagovestaji u high-end kucnoj primeni (citaj kod strastvenih gamer-a ), gde se vec najavljuju prve igrice koje ce moci da iskoriste dual-core processing.

Ima prednosti u korišćenju multithreading-a...
Evo primer sa dual-core 3GHz CPU (poređenje za isti posao, samo broj threadova je različit):

Samo jedan thread
vreme: 3.840829 s
vreme: 3.850101 s
vreme: 3.854960 s

6 radnih threadova + menadžer + glavni thread
vreme: 1.961273 s
vreme: 1.937290 s
vreme: 1.981021 s

12 radnih threadova + menadžer + glavni thread
vreme: 1.943986 s
vreme: 1.965481 s
vreme: 1.939631 s

U ovoj aplikaciji optimalno je imati 12 radnih threadova iako je samo dual-core u pitanju. Kada se povećava broj radnih threadova performanse postaju lošije. Npr. 16 radnih threadova ima slične performanse kao i 6.

Pa tu je suština u "dual core", zar ne?

Da, ali zasto na DualCore 12 niti radi brze od 6, logicno bi bilo da samo do 2 niti daju bolje performanse, ostalo samo stvara overhead?

Pretpostavljam da uspevaju da ukradu malo vise CPU vremena od ostalih aplikacija...

bkaradzic, da li si probao da podesis veci prioritet za threadove? Npr probaj jedan thread sa vecim prioritetom vs. dva threada sa normalnim.

Zdrava logika kaze da pod pretpostavkom da je jedan CPU i svi threadovi imaju isti prioritet onda 1 thread je brzi od n threadova (n>1) jer CPU ne trosi vreme na prebacivanje izmedju threadova.

Takodje ja imam jedno prakticno pitanje, pretpostavka da se radi rekurzivna pretraga *hard diskova, da li je bolje:
1. jedan thread da pretrazi sve hardove po principu kad zavrsi prvi prelazi na sledeci
2. svaki hard disk dobija svoj thread koji radi paralelno sa ostalima

Pod uslovom da su svi ostali parametri isti u obe operacije, sta ce se pre izvrsiti?

*mislim na fizicke hard diskove a ne na particije u okviru jednog koje sistem vidi kao razlicite uredjaje

Sve zavisi od primene. Ako se upotrebljava u IO operacijama (koje su ionako spore) slobodno kreiraj onoliko threadova koliko ti treba. U primeru sa pretrazivanjem diska slobodno kreiraj N threadova (gde je N broj diskova koje pretrazujes).

Preveliki broj threadova moze da "ugusi" OS pa da perfomance budu losije od ocekivanih. Zamislite primer web servera koji bi za svakog klijenta odvajao po jedan thread. Ne postoji OS koji moze da se izbori sa 2000 aktivnih threadova u istom trenutku. OS ce potrositi mnogo CPU vremena na menadzment threadova. Zato se koristi thread-pool, tj. iskoriscavanje threadova dok nista ne rade. Princip je jednostavan... kreira se obicno 2*broj_jezgara threadova i svi su uspavani. Onda u pool ubacujes poslove i jedan po jedan thread se budi i pocinje izvrsavanje posla. Na ovaj nacin se najbolje iskoriscava vise hiper-jezgara ili pravih jezgara. Moguce je kreirati jos nekoliko threadova koji ce uskociti da rade ako uleti neki posao viseg prioriteta, a svi workeri su trenutno zauzeti. Najprostiji thread pool ne garantuje redosled izvrsavanja poslova!

Ja sam u mom programu imao potrebu za paralelizacijom izracunavanja, ali imao sam dva problema. Prvi je da neki poslovi treba da se izvrsavaju po redu kojim pristizu u pool, a drugi nemoraju da se izvrsavaju po redu. Malo dodatne logike u threadpoolu mi je omogucilo da koristim isti pool za obe vrste posla. Performanse su odlicne a brzina obrade se skalira sa brojem procesora u sistemu. (probano na 1, 2 i 4 CPU-a)

U svakom slucaju.. preveliki broj threadova ne valja, premali ne iskoriscava hw koliko moze. Treba balansirati.

Imam osjecaj da je multithreading danas nekako obskurna tema, a toliko stvari bi se moglo poboljsati s njim.
Jednostavno me fascinira tako jednostavni oblik ubrzanja - podjelom posla.

Nema stvarno smisla da mi parsirate, vrlo vjerojatno je velika razlika u nasim godinama. :)

Hvala svima na informacijama, ako ima tko sto dodati, slobodno.

Nije obskurna tema - vec program treba izkodirat sa najvecom mogucom efikasnoscu threadinga. A to nekad zahtjeva dosta dodatnog vremena, pa se pisci manjih programa okrecu klasicnom jednonitnom programiranju. Medjutim - radi se na tom polju dosta. Intelov HT standard nije tu da napravi grandiozan pomak u procesiranju threadova, svi znamo da je to hardverska implementacija emulacije paralelnosti. HT osigurava programerima lakse odrzavanje multithreaded koda, i tjera programere da kodiraju visenitnost kako treba.

Dok se ne pojavi vise vise-jezgrenih racunala u siroj zajednici ovo ce biti obskurna tema jer vecina programera neci ni imati potrebu da koristi threadove.
Mozete pojasniti ako imate vremena.

Pa to se već dešava. Uskoro neće biti procesora sa jednim jezgrom za personalne računare u prodaji.

Za server-side višeprocesorski računari su odavno realnost. Od 2000-te pa naovamo uvek sam morao da uzmem u obzir "thread-safety", jer se kod koji pravim tipično koristi na višenitnim serverskim aplikacijama. Program koji sad razvijam "trči" na 8-procesorskom serveru.

Igre ce ponajvise zakocit razvoj dual-corea. Klasicne jednonitne aplikacije.

Naprotiv, sve novije igre se rade sa threadingom na umu, obavezno.
Svi komercijalni engine-i koji vrede neshto danas su ili potpuno napisani od nule sa podrshkom za threading ili dodaju tu podrshku postepeno. I to je uslovljeno koncepcijom modernog hardvera (chitaj: PS3, Xbox360).
Recimo, Black&White 2 je multi-threaded (pathfinder je, izmedju ostalog, u posebnom threadu), igre koje radi Creative Assembly takodje, i verovatno mnoge druge vec objavljene (ovih sam mogao da se setim u trenutku)

LOL!!! :)
U ovoj poruci http://www.elitesecurity.org/p1232987 test je vršen na multithreading sistemu pisanom isključivo za igru. BTW, isti sistem radi na Win32 (bez obzira na broj jezgra), PS3 (8 asimetričnih jezgra, 1 PowerPC + 7 SPU), X360 (3 simetrična jezgra, 3 PowerPC).

Pročitaj ovaj tekst:
http://www.gotw.ca/publications/concurrency-ddj.htm

Ima još interesatnih linkova u ovoj temi:
http://www.elitesecurity.org/t90742-0#583502

Nakon mitinga:

http://www.artima.com/cppsource/threads_meeting.html

slijede sočni komentari:

http://enfranchisedmind.com/blog/archive/2006/10/21/163

i rješenje:

http://radio.weblogs.com/01039...manProgramming/2006/12/25.html

Kako je konkurentnost riješena u superiornim jezicima:

http://research.microsoft.com/~simonpj/tmp/beautiful.ps

Nakon ovakvih tekstova toplo mi je oko srca...

Nije meni sasvim jasno sto se tolika frka digla oko svega ovog?

Ako neko moze da mi objasni sta oni zapravo pricaju, bio bih jako zahvalan ...

Ja sam do sada vise puta implementirao multi thread aplikacije (windows) i koristio kojekakve critical sectione i
multireadsinglewritesynchonizere (cudo je taj VCL u CBuilder-u :)

Pravio message queue-ove i na taj nacin komunicirao medju thread-ovima ...

I sve to jako lepo radi ...

I sto se to sada ne bi moglo lepo upakovati u neku standardnu bibljoteku pa da bude cross platform i ostalo
po standardu?

Samo zbog brzine?
Citava ta atomic prica meni ovde zvuci kao da je brzina u pitanju - i da stvarno bi
bilo sumanuto praviti Critical section za dva thread-a koja citaju jednu zajednicku promenljivu tipa int

Osim toga nedavno sam naleteo na neki atomic read/write opcode text ...

Zar se ne bi moglo lepo napraviti da se to koristi u slucaju takvih "prostih" tipova a za sve ostalo ... zna se
Critical section ...