Hoće mi netko objasniti kave veze ima latencija sa SMT paradigmom na HT-enabled CPU?

PS: Meni nikad nije bilo jasno zašto svi kenjaju po HT kao ne vide se odmah veelike razlike kad je očito da aplikacije na kojima testiraju nisu napisane da iskorištavaju HT! Idealno napisana multithreading aplikacija bez dijelova koda koji reserijaliziraju tok izvođenja može ići i do 40% brže!

Uostalom za par godina kad svi budu imali multicore CPU-ove odmah će se vidjeti razlika između dobro i loše napisanih programa, hehe.

Slazem se sa Sundance-om :-)

Aplikacije koje su dizajnirane tako da iskoriste HT rade primetno brze - a svaka moderna multimedijalna Win aplikacija je obicno optimizovana i za HT - pogotovu authoring i playback softver, o renderingu i sl.. da ne pricamo.

Ono sto je divota je da se sa HT-om vide svi problemi lose dizajniranog softvera - thread unsafe i, najvise "kvazi thread safe" (TS sa ponekim propustom tipa promakla globalna varijabla ili lose uradjena sinhronizacija niti) iz prve ne radi na HT-u - dok na ne-HT singlecore sistemima kvazi-TS moze i da se provuce bez primetnih problema.

A sto se pomenute diskusije koju je caboom linkovao tice - klasicni Linux story: ne poznajemo o cemu se radi, ali posto Linux nije bas dobar sa tim onda cemo da pljuckamo i pricamo kako je nebitna. Kako se neke stvari beskonacno puta ponavljaju :)

pa tesko da ce ti neko objasniti osim linusa... covek ima univerzalne stavove po pitanju threading-a, RT-a, a evo sada i po pitanju HT-a. cesto mi se cini da je covek najblaze receno ... nekompetentan za poziciju na kojoj se trenutno nalazi. u sustini je zanimljiva i divergencija diskusije na kernel mailing listi o ovoj istoj temi.

Naravno, "silly BSD-ovci" su to odmah riješili:

ftp://ftp.freebsd.org/pub/Free...RT/patches/SA-05:09/htt5.patch

Nema ništa smiješnije nego kad netko kaže "taj napad je nemoguć", ili "to nas ne tangira", i pogotovo kad to kažu neki so-called security experti :=)

za taj patch je na linux kernel listi receno da je bullshit, a mislim da je o istom trosku receno da je za jos par implementacija pri fbsd kernelu bullshit, pa se posle N postova ispostavilo da linux ima slican problem. objektivnost pre svega...

Vrlo interesantan članak Herb Sutter-a na tu temu:

http://www.gotw.ca/publications/concurrency-ddj.htm

sustinski, ovo uopste nije nova tema osim za one koji su vezani za x86 arhitekturu. u svakom slucaju, pisanje mainstream sw-a ce postati interesantnije kada multicore arhitekture preplave korisnicko trziste.

Ne treba ti multi-core za to, godinama unazad imas (velike) SMP sisteme (do 128 procesora) ili NUMA-CC sisteme (do 2048 procesora) na kojima dobro napisane aplikacije, a narocito operativni sistemi dolaze do izrazaja. Do skora Linux nije skalirao na vise od 4 procesora, i to je cak bilo jadno. Istovremeno komercijalni Unixi imaju skoro linearno skaliranje.

Ali isto tako, malo je besmisleno pricati o Intel arhitekturi i skaliranju...

Nisam želio reći da je za SMT potreban multicore, već da je to trend u razvoju general-purpose CPU-ova (AMD, Intel)!

Jednostavno će vrlo brzo doći (tj. već je došlo + par godina da se zamaše) vrijeme kad su softveraši "ladili jaja" na račun hadrveraša, povijest uzvraća udarac žestoko i nasilno :)

Vjerojatno će se uočiti prednost .NET-a pošto tamo svaki objekt već ima dodijeljen SyncBlockIndex kojeg framework inicijalizira (CRITICAL_SECTION pod Win32), pa će nad njim biti lako implementirati neke konkurentne paradigme.

Možda za 10 god ako većina važnijih aplikacija bude managed bude se mogla napraviti tranzicija na neke nove arhitekture relativno bezbolno, pošto će se samo trebati portati framework :)

Svi su u tom filmu, Intel i AMD su se medju poslednjima pridruzili tom trendu. Moglo im je bit, a i fora sa OC je pazljivo gajena da kod "obicnog" korisnika izgradi tu svijest o potrebi sofisticiranih rijesenja za hladjenje u PC kucistu. Kad je Prescott poceo da isijava 108 (!!) Vati, e onda je djavo odnio salu i pojavila se prica da su "ratovi frekvencija zavrseni".

Ekipa koja pravi silikon gdje ekvivalenti vodenog hladjenja uopste ne dolaze u obzir davno je vec pocela da poseze za cipovima na kojima ima vise procesorskih jezgara.

U pocetku, takve masine (zbog cijene) trosene su za specijalizovane namjene (datapath u telekomunikacijama, naprimjer), a sad je vec jasno da ce se trend prosiriti na sve primjene procesora.

MIPS jezgra su, inace, najmasovnije koristena u pocetku, a razlog je efektivna povrsina chipa koja je potrebna da se procesorsko jezgro implementira. Narocito stariji R3000 je dobar bio za te stvari.

Sve vise se prica o "termickoj barijeri" kao stvari koja bi po prvi put mogla da ugrozi Murov zakon.

Tumbanja u softverskom svijetu kad pocne da izranja hardver sa vise procesorskih jezgara ce biti, SMP ima svoje limite.

Slažem se. Ja bih radije volio da danas mogu kupiti CPU od 10 jezgara na 1GHz, nego sa 2 jezgre na po 3GHz.

Ali nažalost utrka za MHz je učinila svoje.

Stvarno je žalosno što na desktop tržištu nema nikakve konkurencije x86/amd64.

Meni je što više čitam o drugim arhitekturama to više žao što ih ne mogu isprobati u stvarnom životu.

Evo i sam koncept HyperThreadinga je Intel ukrao od Alpha EV8 procesora.

Ja bih recimo jako volio da MS isforsira za .NET da se napravi CPU sličan Sun MAJC za ili ARM Jazelle za Javu.

Be careful what you wish for.

Mislim, ta racunica je OK, cak i sa nekim "normalnim" koeficijentima iskoriscenja koje SMP daje, a na sistemima gdje su aplikacije "dobro" napisane (u smislu da forkuju gdje god se moze) ces bolje proci nego sa dva procesorska jezgra.

Problem je sto SMP ima svoje limite. A limit je sto je covjek (vjest programer) ukljucen u pricu, nivo do koga mi (kao nesavrseni stvorovi) mozemo da izvrsimo paralelizaciju, a u odnosu na efektne troskove (vrijeme) da se takvo programiranje izvrsi postavlja prakticne barijere pred narastanjem broja procesorskih jezgara a na tradicionalnoj radnoj stanici.

Neko je ovdje pomenuo sisteme sa 128 i 256 procesora. Da, to su efektni serverski sistemi, ali efektno koriscenje takvog sistema je posljedica dijeljenja resursa i cinjenice da postoji ekipa koja takav sistem moze da zatrpa poslovima (nevazno da li se o pojedinacnim taskovima ili threads prica). Na radnoj stanici, natjerati sistem sa 16 procesorskih jezgara na 200 MHz da se bolje ponasa od sistema sa 2 procesorskih jezgara na 1 GHz nije tako lako, za neku uopstenu dinamiku sistema.

Pravo, mnogo bolje rijesenje, je da se paralelizacija izvrsavanja odradi u kompajleru, da kompajler generise threads. Upravo sam dobio rezultate benchmark-a gcc 4.0 autovectorizer za Altivec (vjerovatno su ekvivalentni rezultati za intelov SSE 3 u slicnim domenima). Poboljsanja su znatna, ali skromna u poredjenju sa teoretskim maksimumom.

Nemamo, jos uvijek, softversku infrastrukturu da iskrocimo u takav razvoj hardvera. Teorija za "loop unrolling" i ostale fazone za paralelizaciju je odavno ispisana, prakticna rijesenja tek treba da se pojave. SMP je rijesenje samo za prvu iteraciju i treba nam proboj i na toj strani.

look Apatrid, cak i fake-SMP daje jako dobre cost-performance rezultate vec godinama unazad. teoretski maksimum je upravo to, teoretski maksimum, ali neke arhitekture se jako dobro skaliraju. pored ostalog, razvoj takvih aplikacija zahteva prilicno inzenjersko iskustvo i znanje sto otpisuje gro GPL/OS radne snage. ako pogledas, gro GPL aplikacija se katastrofalno skalira i sa tog stanovista zaista nije isplativo igrati se sa tim skupim igrackicama, ali se situacija dosta menja sa dobrim delom komercijalnog sw-a. pored ostalog, linux ce imati solidnih problema sa adaptacijom na takvom trzistu sa obzirom na kanta arhitekturu sto se tice kernel thread-inga.
btw. (almost) SMP arhitekture se zaista godinama unazad koriste veoma efikasno, ne razumem o kojoj prakticnoj implementaciji ti zapravo pricas.



IMNSHO, ovo je najgore resenje, posto ce apstrakcija threading-a cesto definise u samoj arhitekturi aplikacije i generalno ovo resava samo uski spektar problema.

Lose projektovanu aplikaciju nece spasiti nikakav "hyper-threading" ili "smp" kompajler, vec cela stvar mora biti uradjena u samoj fazi projektovanja aplikacije.

Sto je u biti vrlo dobro - jer je vrlo jasno da je buducnost razvoja procesora multi-core za PC platforme kao i hibridne arhitekture tipa TI-OMAP sa vise CPU/DSP podsistema za razlicite poslove, u domenu prenosnih uredjaja.

U takvim situacijama ce do izrazaja doci, o da, sposobnost i umece dizajnera i programera - a ne "grubi misici" kako su se mnogi nadali do pre samo par godina ;)



Loop unrolling je stvar koju svaki bogovetni kompajler danas ima, Intel i slicni koriste odavno i vektorizaciju - a sto se tice transformacije svega ovoga na multi-procesorsko polje, sama ideja je osudjena na propast bez asistencije programera u aplikativnom dizajnu - jer, koliko god mi hteli, kompajler je jedna glupa alatka - i nije u stanju da pogodi neke stvari koje se ticu sinhronizacije procesa i podataka :-)

Pricam, caboom, o implementaciji kompajlera koji radi paralelizaciju za tebe, napravi threads od "flat" koda. Ti ne moras da "forkujes", ali te nista ne sprecava da to uradis.

Stvari koje sam slusao i polozio na postdiplomskim studijama (koje nijesam zavrsio) jos 90-e, a ti se vidi koja je danas godina. Teorija za takve stvari poodavno postoji, prakticne implementacije nema, a da je ja znam. Ovaj "autovectorizer" iz GCC je prvi iskorak u prakticne implementacije iz tih domena, ja sam pricao o teoretskom maksimumu ne cipova sa vise procesorskih jezgara, vec Altivec kao jedinice za vektorsku aritmetiku.

Primjer koji sam naveo, utrpati u cip 16 procesorskih jezgara na 200 MHz, i to jace od toga, je nesto sto je sa tehnologijom od prije 5 godina moguce, ja i moji korisnici se sa takvom igrackom vec godinama nosimo.

Sto se hardvera tice, spakovati 32 procesorska jezgra umjesto 16 je relativno mali iskorak. Kod SMP-a, koeficijent iskoriscenja (za siroki spektar dinamike procesorskog load-a na general-purpose masini) sve vise i vise pada sto se povecava broj jezgara. Radi, bolje nego nista, ali nije "prava" stvar. Prava u smislu da oslobodi razvoj hardvera u tom smislu.

E pa cuj, ako cemo tom logikom da idemo, nista ne moze da se nosi sa dobro optimizovanim asemblerskim kodom. Postavlja se pitanje sto je prakticno, a sto ne.

ovo nema veze sa asemblerskim kodom Apatrid, ovo ima veze sa >> arhitekturom << aplikacije - kompajler ne moze da ti optimizuje losu arhitekturu. pored ostalog, dobre SMP performanse se ne postizu hack & thread implementacijama koje npr. mozes da vidis kod mysql-a, vec pazljivim projektovanjem. dakle, to ukljucuje 2 stvari, da znas sta zelis da postignes i da znas kako da postignes. apsolutno niko ne kaze da je pisanje high-performance threaded aplikacija jednostavno, cak stavise, ali to je stvar u kojoj ti kompajler ne moze pomoci, vec samo (donekle) profajleri. kompajler moze da ti odradi samo grube optimizacije, zapravo, poredjenje koje si dao je zapravo izrazito lose.

Na ovoj fazi da, ali je recimo cilj kod Suna da se prevazidje jaz izmedju brzine procesora i memorije. Arhitektura na kojoj oni rade nije jednostavno ubacivanje 16 jezgara, nego i asinhroni memorijski kontroler tako da se dodje do maksimuma iskoriscenosti procesorskog vremena i memorije.

Doduse, ovakvo generalizovanje je veoma opasno jer arhitektura mora da bude u skladu sa prirodom problema. Broj procesora sam po sebi ne znaci apsolutno nista ako u prici nemas odnos procesora medju sobom, sa memorijom, kesom, itd. Na primer, odredjeni tipovi problema se efikasnije resavaju na SMP (shared memory processor) masinama, dok se neki drugi bolje resavaju na najobicnijim Beowulf klasterima.

U svakom slucaju, broj jezgara po procesoru samo treba da poboljsa odnos price/performance i u tome uspeva.

I da se nadovezem na cabooma. Performanse se postizu i poznavanjem hardverske arhitekture za koju se pise aplikacija. Dakle sve te stvari su veoma usko povezane i zapostavljanje jedne od tih cinjenica se zavrsava losim performansama.

_{[Ovu poruku je menjao neetzach dana 01.06.2005. u 18:24 GMT+1]}

problem sa cluster-ima je sto je trenutno jak hype po pitanju paralelnog procesiranja, pa se cesto prave veoma povrsni i losi kompromisi i clusteri koriste u kranje bizarno zamisljenim resenjima + ocajnom realizacijom, uostalom imao si prilike da vidis. ;)

To je svakako slucaj, i zato sam napomenuo da se mora obratiti paznja na prirodu problema. Npr. Beowulf klaster je sasvim prirodno resenje za racunanje matrica. Isto tako bi ta arhitektura bila pogudbna za npr. baze podataka.

_{[Ovu poruku je menjao neetzach dana 01.06.2005. u 18:36 GMT+1]}

Ispravi me ako gresim, Apatrid - ali moderni Intel kompajleri (> 6, danas 8.1) imaju i vektorizaciju preko SSE registara, i loop unrolling i optimizaciju pipeline izvrsavanja, kao i baznu hyperthreading optimizaciju - i jos podosta prilicno modernih tehnologija optimizacije.

Tako da GCC nije izmislio nikakvu toplu vodu, a sve to postoji u komercijalnim kompajlerima za takve sisteme i arhitekture (tipa Alpha) jos ohoho odavno.

Ono o cemu je ovde rec, je da kompajler ne moze (i to uz pomoc bilo kakve teorije) da bude uporediv sa dizajnom (ne pricamo o implementaciji, pa je asemblersko poredjenje neprimereno) aplikacije gde se vodilo racuna o ciljnoj arhitekturi a u pogledu optimizacije programskih modula i niti.

To ni jedan kompajler ne moze da uradi bez asistencije coveka, i to veceg dela posla na covekovoj strani - iz prostog razloga sto kompajler ne moze da nasluti izvrsnu logiku ili redosled racunanja nekih parametara u vise niti - to ne ide, niti je iko normalan radio na tako necemu (mozda za neki bogus Ph.D)

Evo ti prost primer - imas dupli DSP / dual corei, recimo, video enkoder - zavisnost frejmova jedan od drugog (predikcije), problem zavisnosti jednog algoritamskog bloka od drugog i sl... jednostavno cine kompajler nemocnim u optimizaciji osim povrsnih optimizacija.

Ako dobar projektant onda preuredi algoritam tako da a-priori bude poznato da ima vise jezgara i podele se zadaci i sinhronizuje posao izmedju jezgara - takav proizvod ce trcati mnogo brze nego puki pokusaj kompajlera da grubo nesto opimizuje.

Naravno, ima softverskih aplikacija koje pukim forkovanjem mogu da budu brze, tipa HTTP serveri, ali i tu moze da se ucini dosta boljim dizajnom koji kompajler ne moze da nasluti... e sad, pitanje je da li tebi treba takav boost u performansama, ili ces se samo osloniti na "kupi jaci hardver" ... to zavisi od tvoje poslovne politike.

"loop unrolling" je i tehnika za optimizaciju, ali i tehnika za elementarnu paralelizaciju.

Ne znam za vektorizaciju u Intel kompajlerima, nijesam pratio razvoj njihovog kompajlera. Za nase procesore nema, Ivane. Postoji ekipa koja je zaduzena za Altivec i prati te domene non-stop, ljudi decidirano rekli da je samo jedan pokusaj implementacije vectorizer-a bio i da nije doslo do "market traction".

Inace, ova primjedba da kompajler ne moze da prepozna paralelizam na visem nivou je OK, ja nijesam rekao da ce upotreba "fork" (ili ekvivalenata) nestati, niti da ce nestati potreba za dobrim programerom :).

Realnost je da, sto se "dobro napisanih aplikacija" tice, broj onih koje nijesu "dobro" sa tog aspekta napisane, (ali jos uvijek rade koristan posao) veci od onih drugih, koje generisu dovoljno threads da iskoriste sistem maltene bilo kog stepena paralelnosti.

Ja sam primjer sa asemblerom naveo zbog razlike u utrosenom trudu, te prakticnosti primjene tehnologije. Slusaj, "dobro napisana aplikacija" ce postici jedan nivo paralelizma, recimo, grubog primjera radi, 13 paralelnih threads u bilo kom trenutku. Ako kompajler izgenerise jos 4-5, ukupni efekt je jos bolji, zar ne?

Kompajler ne moze da mi optimizuje arhitekturu cijelog sistema i odradi bolji posao od vjestog covjeka (otud analogija sa asemblerom, nema kompajlera koji moze da se nosi sa rucno optimizovanim kodom), ne moze da zamijeni vjestog programera, ali kompajler moze da "iscijedi suvu drenovinu" i da bilo kojoj lose napisanoj aplikaciji da "boost", ma kako malen bio.

apsolutno ne, ovo je veoma opasna i manipulativna implikacija. naime, suvo razbacivanje samim thread-ovima moze rezultovati time da ti aplikacija trosi previse resursa na sam context switching. stvar kao sto je balans u sinhronizaciji je u ne-trivijalnim slucajevima cesto veoma zeznuta i kompajler moze da ti iscedi samo trivijalno malo performansi u slucaju dobro napisanih aplikacija. sto se tice lose napisanih aplikacija, one su naprosto to - lose napisane aplikacije.
stvar je u tome da ti naprosto gcc sa threading optimizacijama nece genrisati SMP ready aplikaciju iz mnogo razloga.

To sto ti pricas, caboom, ja ne osporavam. Da, sve je to tacno kad dizajniras sistem gdje ti mozes/moras stvari da drzis pod kontrolom.

Stvarnost je da procesori ne rade samo u embeded svijetu, gdje je, ama do zadnje, svaka linija koda pod tvojom kontrolom, vec i u workstation svijetu, "procesorima opste namjene".

Kolicina niti koja ce bit aktivna u jednom trenutku, zavisi od dinamike koju definise korisnik. Ti jednostavno ne mozes da izbacis iz igre mogucnost da ce doci do overloading-a paralelizma, jer covjek moze da pokrene N aplikacija koje ce taj, pazljivo optimizovani sistem za maksimalno iskoriscenje paralelizma da razbiju.

Problemi su ovakve prirode: imas procesor sa 64 procesorska jezgra. Kako dizajniras svoju aplikaciju, da ima paralelizam 16 (16 niti koje otprilike isto rade), 32, ili 64? Sve je veoma jednostavno ako je tvoja aplikacija jedina koja se izvrsava. Na masini opste namjene, sa dovoljnim brojem procesorskih jezgara, "pokreni niti koliko mozes (nema smisla ic' preko 64 u ovom mom primjeru) da pronadjes i staraj se da rad medju nitima podijelis da bude otprilike isti, pusti scheduler da ispegla ukupne performanse sistema dijeleci procesor izmedju niti" i nije tako hrdjava logika.

Nakarikati 64 paralelne niti u algoritmima koji su "flat" je mozda moguce, ali nije bas toliko trivijalno da kazes "svaki programer to moze da oposli". Kompajler ce pronaci paralelizam u svakoj petlji (petlji se vala odreci neces, ipak), iskoristiti ga AKO TO IMA SMISLA, i time pomoci cak i losoj aplikaciji.

Kompajler moze da prepozna kad nema smisla vijati paralelizam (e je skuplja dara nego maslo), jer se takve situacije daju precizno matematicki opisati.

Apatrid mislim da si vrlo u krivu :)

Kompajler ne zna ništa o sinkronizacijskim primitivima koje OS na odredišnoj platformi implementira. Šta kompajler zna, što je semafor, mutex, spinlock, šta on zna koji točno API uzrokuje context-switch, koji uzrokuje wait operaciju (i na koliko dugo?) -> to je sve uloga OS-a. Recimo na win Sleep(0) je interno implementiran kao SwitchToThread() -> kako će to kompajler znati? :)

A što se kompajlera tiče, recimo na NT, CRITICAL_SECTION je struktura kao i svaka druga, nema u njoj ništa magično :) Nadalje svaki objekt (proces, job, nit, semafor, datoteka, timer, događaj...na NT je to svaki objekt koji ima embeddan tzv. dispatcher objekt sa DISPATCHER_HEADER strukturom, a nove tipove objekata može stvarati i korisnički program, tako da nema nikakve šanse da kompajler "pogodi" koja varijabla može, a koja ne može biti korištena za sinkronizaciju, te i na koji način, svaki od gore navedenih objekata se "okida" na drugi način, proces kad mu se terminiraju sve niti, timer kad mu istekne vrijeme...) nad kojim se može implementirati sinkronizacijski ili notifikacijski događaj, nad njom može biti imlementirana wait operacija u raznim kompleksnim scenarijima. Ako poziva neki API koji radi I/O + neka completion rutina, stvari postaju još zabavnije :)

Ako pretpostavimo da nekim čudo sve to zna, recimo da kompajler može u stadiju semantičke analize nad svaki objekt attachati odgovarajući dependecy tree, da može algoritamski extrahirati najbolji mogući scenarij (u smislu paralelizacije) odnosa sa svim drugim objektima, da poznaje sve detalje odredišne arhitekture, opet u igru dolaze neke lude pikanterije OS-a kao što su quantum pojedine niti, broj pojedinih niti u odnosu na broj logičkih procesora, predikcija overheada poziva sistemskih fja, lag između niti koji se sinkroniziraju (proporcionalan broj logičkih CPU-ova), potencijalni runtime priority boost koji je programski implementiran od strane programera ili heuristikama OS-a, komunikacija samog thread primitiva sa OS-om i interakcija sa njim (recimo APC-ovi se izvršavaju u kontekstu pojedine niti, pošto su oni po definiciji asinkroni (jerbo se tako i zovu - Asynchrounous Procedure Calls :) nema te logike po kojoj bi kompajler mogao napraviti njihovu predikciju), te ne daj bože da niti korise neki oblik IPC-a jerbo je za kompajler sve izvan trenutne aplikacije jedna velika crna kutija....

Uglavnom, mislim da je extrahiranje thread-level paralelizma iz koda SF, i da je moguć (ako je uopće moguć), samo u scenarijima typesefe jezika koje se izvode pod virtualnom mašinom, tj. kad JIT-er zna i broj logičkih CPU-ova i detalje OS-a).

Uspoređivati instruction-level paralelizam kroz multistage pipeline sa ovakvim nečim jest totalno nerealno IMHO. To su dvije totalno različite klase problema. Nit po konceptu i jest primarna apstrakcija CPU-a sa stajališta programa, ali ovaki scenariji kad bi kompajler generirao nove niti kako mu šune bi bili mogući tek kad CPU bude imao 100 jezgara, pa krivi pogodak baš i neće puno značit....

Mislim da teka kad 90% programera bude imalo multithreaded programiranje u malom prstu (dakle nikad), kompajleri će kroz neke odgovarajuće metodologije programiranja omogućiti da im se da hint koji dio koda na koji način ovisi o kojem dijelu koda.

Sve do tada, VTune u ruke i deri :)

apatrid, nalazenje paralelizma u svakoj petlji moze da uzrokuje takodje i ozbiljne probleme sa bas onim sto sam naveo - context switching-om i opet... takva optimizacija ce ti doneti znacajnije performanse u samo nekim slucajevima. nemoguce je napraviti potpuno flat aplikaciju, ali je moguce napraviti aplikaciju koja se dobro ili lose skalira na takvim arhitekturama.
ono sto mi se ne dopada u ovom rezonu je bas taj klasicni Linux "nabudzi i pomoli se" pristup gde ocekujes da ti kompajler magicno resi problem sa lose napisanim aplikacijama. generalno, osecam veliki antagonizam prema takvim resenjima i mislim da su primenjiva samo do odr. granice i da na kraju uvek vode do mnogo veceg man/effort troska, osim u veoma trivijalnim slucajevima.

onog dana kada se to bude desilo, verovatno cemo ostati bez posla :)

To je ILP (Instruction Level Paralelism), kad sve te instrukcije izvršavaju pod _istim_ kontekstom (istim thread-om). To _nije_ multithreaded paradigma. Jedan CPU ima u _jednom_ trenutku _jedan_ execution flow.



Može za 1 execution flow te extrahirati međusobno neovisne instrukcije koje može unutar pipeline-a izvesti. Koliko ja vidim ti si spominjao da kompjaler _generira_ nove niti, kako bi ih optimizirao za multicore scenarije.

Sjećam se negdje sam pročitao da su kompajleri ograničeni na maximalno 4-way ILP (barem za Intel). Tako da ni tu nije baš najbolje :) Najbliže nekom ludom iznuđivanju kontekstualno-neovisnog paralelizma iz koda bi bilo spekulativno izvođenje niti kao npr. na MAJC, kad se stvara nova spekulativna nit izvođenja koja izvodi buduće instrukcije u sadašnjosti, te koje se spajaju kad prva nit završi čekanje. Ali opet takvo nešto je na razini CPU-a, a ne kompajlera...

Što se tiče samog ILP, na IA-32 arhitekturama sa jako _ograničenim_ skupom registara, ne možeš baš puno širiti code stream. Intelovi procesori su uglavnom bazirani na uskoj jezgri, serijski posloženim funkcionalnim jedinicama koje jako brzo izvršavaju kod. To suxa sa bilo kojeg stanovišta paralelizacije.

PS: Vjerojatno sam u svemu ovome rekao neke gluposti pa se unaprijed ispričavam :)