News.com - Komaj se je polegel prah okrog dvojedrnih procesorjev, je Intel prejšnji teden na International Solid-State Circuits Conferenc (ISSCC) predstavil štirijedrnega Xeona, izdelanega v 65 nanometrski tehnologiji. Procesor, s kodnim imenom Clovertown, bo kupcem na voljo najverjetneje na začetku leta 2007. Po Intelovih podatkih naj bi arhitektura tega procesorja omogočala izdelavo kar 32 jedrnega procesorja. Na enaki arhitekturi bodo bazirani tudi prihajajoči dvojedrniki, Merom za prenosnike in Conroe za namizne računalnike, ki bodo predstavljeni proti koncu letošnjega leta.
Predstavljeni štirijedrnik bo namenjen vgradnji v dvoprocesorske strežnike, kar je po zmogljivostih primerljivo z današnjimi osemprocesorskimi strežniki. Za strežnike s štirimi ali več procesorji pri Intelu razvijajo Clovertown-u podoben procesor s kodnim imenom Tigerton.
Uslužbenec Intela, Justin Rattner, je dejal, da do konca tega desetletja lahko pričakujemo že desetjedrne procesorje, v desetih letih pa bo razvoj šel tako daleč, da bodo procesorji imeli več sto jeder.
Izvorna novica na News.com: klik!
Novice » Procesorji » Intel predstavil štirijedrni procesor
Izi ::
Glih ene 20 let je odkar sem kupil (takrat mi ga je kupil še oče 
) moj prvi PC.
Bil je prva 286-ka na 4 MHz
In kot so od takrat naprej rasli megaherci bo od sedaj naprej ralslo število jedr.
Kot imam sedaj 2600 MHz bom imel čez 20 let verjetno 2600 jedrni CPU
Ali bo to Intel ali AMD ali pa kakšen tretji bomo pa še videli.
) moj prvi PC.Bil je prva 286-ka na 4 MHz
In kot so od takrat naprej rasli megaherci bo od sedaj naprej ralslo število jedr.
Kot imam sedaj 2600 MHz bom imel čez 20 let verjetno 2600 jedrni CPU
Ali bo to Intel ali AMD ali pa kakšen tretji bomo pa še videli.
_Matej_ ::
Vse skup me spominja na 3dfx, namesto da bi naredili boljše jedro, so na kartice nalimalu kup jeder, 8 komadov al kolk že?
WarpedGone ::
Ja, 1 jedro bo delalo, 99 jeder bo pa off.
Blue cristals anyone?
Blue cristals anyone?
Zbogom in hvala za vse ribe
Vesoljc ::
> namesto da bi naredili boljše jedro
si že slišal za fizikalne zakone?
si že slišal za fizikalne zakone?
Abnormal behavior of abnormal brain makes me normal...
Matevžk ::
Blue cristals anyone?
Kaj, a da bomo poj samo plug-and-play ven-in-not šibali master control crystals?
lp, Matevžk
Spc ::
izdelavo kar 32 jedrnega procesorja
Pa bomo dobili datacenter server specifikacije v enem samem procesorju.
Pa bomo dobili datacenter server specifikacije v enem samem procesorju.
Zgodovina sprememb…
- spremenil: Spc ()
Looooooka ::
bolse jedro...
mislm da sta amd in intel ze pocas dosegla najvec kar jima trenutno na enojedrnem procesorju lahka rata.
dokaz je ze poraba stroma in gretje.
skrajn cajt da nardijo neke 10 jedrne procesorje...pa pol se na graficne to nalimamo pa mamo real-time movie rendering efekte v par letih =)
mislm da sta amd in intel ze pocas dosegla najvec kar jima trenutno na enojedrnem procesorju lahka rata.
dokaz je ze poraba stroma in gretje.
skrajn cajt da nardijo neke 10 jedrne procesorje...pa pol se na graficne to nalimamo pa mamo real-time movie rendering efekte v par letih =)
opeter ::
KO že govorimo o porabi elektrike... bi mi lahko kdo od vas povedal koliko elektrike porabi 4 jedri procesor? Kaj pa procesor s 32 ali 100 jedri?
Ker če razmišljamo z današnjimi procesorji in porabo, potem en štirijedrnik rabi vsaj 1/4 kW, ali se pa motim?
Bomo res morali graditi nove hidro-elektrarne na Savi, samo zaradi mulcev, ki želijo špilati Doom X na 64 jedrnem Pentiumu X Extreme Edition V10?
Ker če razmišljamo z današnjimi procesorji in porabo, potem en štirijedrnik rabi vsaj 1/4 kW, ali se pa motim?
Bomo res morali graditi nove hidro-elektrarne na Savi, samo zaradi mulcev, ki želijo špilati Doom X na 64 jedrnem Pentiumu X Extreme Edition V10?
Hrabri mišek (od 2015 nova serija!) -> http://tinyurl.com/na7r54l
18. november 2011 - Umrl je Mark Hall, "oče" Hrabrega miška
RTVSLO: http://tinyurl.com/74r9n7j
18. november 2011 - Umrl je Mark Hall, "oče" Hrabrega miška
RTVSLO: http://tinyurl.com/74r9n7j
Zgodovina sprememb…
- spremenil: opeter ()
GregaST ::
Mislm da so s tranzistorji dosegli vse kar se je dalo. Pomojem je prihodnost v Cell procesorjih.
Azrael ::
@crnapika:
Ne skrbi za porabo štroma, ni problem, če že samo pri današnjih procesorjih malo znižaš takt. Ker pa bodo verjetno v naslednjih letih pogruntali oz. bolje rečeno spravili v proizvodno nove dosežke, bo verjetno 32 jedrni procesor kuril isto ali manj kot sedanji.
Lep dokaz so notesniki, kjer vse skupaj kuri zelo malo, zmogljivosti imajo v rangu namiznih strojev, res pa je vse skupaj dražje.
15 let nazaj so pri napovedi izjemno zmogljivega 486 50MHz, krožile zgodbe, da bo moral za ta CPU vsak mlinček imeti najmanj LN2 hlajenje, danes pa vemo, da hlajenje teh zadev ni bil noben problem, večinoma je šlo lepo brez vsakega hladilnika...
@GregaST:
Misliš, da v Cell procesorjih ni tranzistorjev? Da so notri majhni možički, ki premikajo stikala ? Hecam se. Cell je samo druga zasnova procesorja, ki se bo ali pa tudi ne obnesla, kar bo pokazal šele čas.
Ne skrbi za porabo štroma, ni problem, če že samo pri današnjih procesorjih malo znižaš takt. Ker pa bodo verjetno v naslednjih letih pogruntali oz. bolje rečeno spravili v proizvodno nove dosežke, bo verjetno 32 jedrni procesor kuril isto ali manj kot sedanji.
Lep dokaz so notesniki, kjer vse skupaj kuri zelo malo, zmogljivosti imajo v rangu namiznih strojev, res pa je vse skupaj dražje.
15 let nazaj so pri napovedi izjemno zmogljivega 486 50MHz, krožile zgodbe, da bo moral za ta CPU vsak mlinček imeti najmanj LN2 hlajenje, danes pa vemo, da hlajenje teh zadev ni bil noben problem, večinoma je šlo lepo brez vsakega hladilnika...
@GregaST:
Misliš, da v Cell procesorjih ni tranzistorjev? Da so notri majhni možički, ki premikajo stikala ?
Hecam se. Cell je samo druga zasnova procesorja, ki se bo ali pa tudi ne obnesla, kar bo pokazal šele čas. Nekoč je bil Slo-tech.
Poldi112 ::
Dvomim da se bo poraba zmanjševala (razen mogoče v laptop modelih). Vsako leto poraba zraste enostavno zato ker lahko (ker napreduje tudi tehnologija hlajenja).
In multicore ni edini način. Je pa trenutno najlažji (oz. ima najboljše razmerje med ceno razvoja, izdelave in performancami), zato so šli v to smer.
In multicore ni edini način. Je pa trenutno najlažji (oz. ima najboljše razmerje med ceno razvoja, izdelave in performancami), zato so šli v to smer.
Where all think alike, no one thinks very much.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
OwcA ::
Opozoril bi samo, da gre tu za povsem novo arhitekturo (Merom/Conroe), ki je že od vsega začetka bila zasnovana z "mnogojedrsvom" v mislih.
Otroška radovednost - gonilo napredka.
Utk ::
To je zelo smiselno za strežnike, kjer imaš gor še zmeraj vsaj 10× več uporabnikov kot je jeder. Z več kot 4 jedri pa ne boš nič boljše igral dooma kot z recimo dvema ali štirimi. Lahko pa boš zraven dooma igral na drugem monitorju še kaj drugega:) Zadnji čas, da pride do tega. Še zmeraj bo pa nujno potrebno tudi posamezno jedro izboljševat.
billy ::
Azrael, kateri prenosnik pa uporablja cell tehnologijo...zaenkrat ASAIF še ga čakamo da pride ;)...
edino xbox ima cella za zdaj not.
edino xbox ima cella za zdaj not.
keber ::
Zakaj N-jedrni procesorji niso hitrejši od enojedrnih za N-krat ampak samo 10 ali 20%? Mogoče bi morali to malo izpiliti
Izi ::
>>Zakaj N-jedrni procesorji niso hitrejši od enojedrnih za N-krat ampak samo 10 ali 20%?
Krivda ni v procesorjih ampak v programih in operacijskem sistemu, ker (še) ne zna izkoristiti vseh procesorjev naenkrat. Se pa to hitro izboljšuje.
V bistvu bo potrebno čisto vse programje napisati popolnoma na novo, da bo na koncu N-krat hitrejše.
Sploh pa to ni namenjeno samo za strežnike ampak čisto za vsa področja.
Spet bodo največ od tega imela prav igre. Nekatere že poskušajo uporabljati tudi ostale procesorje, sicer še ne v popolnosti ampak ene 10% pa pridobiš na hitrosti iger že danes, če dodaš popravke za podporo večim procesorjem.
Krivda ni v procesorjih ampak v programih in operacijskem sistemu, ker (še) ne zna izkoristiti vseh procesorjev naenkrat. Se pa to hitro izboljšuje.
V bistvu bo potrebno čisto vse programje napisati popolnoma na novo, da bo na koncu N-krat hitrejše.
Sploh pa to ni namenjeno samo za strežnike ampak čisto za vsa področja.
Spet bodo največ od tega imela prav igre. Nekatere že poskušajo uporabljati tudi ostale procesorje, sicer še ne v popolnosti ampak ene 10% pa pridobiš na hitrosti iger že danes, če dodaš popravke za podporo večim procesorjem.
Zgodovina sprememb…
- spremenil: Izi ()
Gizmo_X ::
Kolikor je meni jasno, je problem zaradi navezljivosti enega ukaza na drugega - v procesu.
Npr.:
x=1 //1. ukaz
x=x+5 //2. ukaz
y=x+3 //3. ukaz
z=x+y //4. ukaz
1. jedro izvaja 1. ukaz, istočasno naj bi 2. jedro drugi ukaz, 3. jedro 3. ukaz, 4. jedro pa 4. ukaz. Vendar ne gre tako.
Medtem, ko 1. jedro izvaja 1. ukaz, 2. jedro ne ve, koliko je x, da bi ga povečal za 5. Čakati mora. da 1. jedro opravi svoje. Ko pa to opravi pa lahko kar 1. jedro izvede naslednji ukaz.
Tudi 3. jedro ne more nič, saj ne ve, koliko je x, da bi mu prištel 3 in shranil vrednost v y.
Sploh pa ne 4. jedro, ki ne ve niti vrednost x-a, niti vrednost y-a.
Aplikacije pa se lahko napiše tudi tako, da so sestavljene iz več 'niti' (ne vedno, kdaj pa vseeno). Npr.:
x=1
x=x+5
y=5
y=y-3
z=5+3
z=z-2
To se lahko izvaja istočasno, ker se spremenljivke ne navezujejo ena na drugo. Seveda je to slab primer, ker je preveč poenostavljen, pa še istega rezultata ne da, kot gornji.
Boljši primer bi bil kakšen praktičen, npr. za igre.: Ena nit bi bla fizika, druga nit grafika, tretja nit zvok.. In namesto da jedro preračunava za vsako sličico FizikaGrafikaZvok, FizikaGrafikaZvok, FizikaGrafikaZvok, ... , lahko vsako jedro poskrbi za eno izmed teh stvari za eno sličico. Tako je npr. potrebno čakati za sličico 3x manj, kar je 3x večji fps. Teoretično. Ko bomo imeli 10-jedrne procesorje, bodo pač niti še povečali. Npr. fizika igralca, fizika okolja, fizika drugih igralcev, grafika za vsakega posebej, zvočni efekti za vsakega posebej. Vse le zato, da se druga jedra ne 'dolgočasijo' in pomagajo zraven.
S tem bi rad povedal le to, da je izboljšanje programov in OS-ov delo programerjev.
Lahko pa vsako jedro opravlja svoje procese, istočasno. Medtem, ko 1. jedro odpira Word, lahko 2. jedro predvaja glasbo, 3. jedro predvaja film, 4. jedro pa odpira internetne strani.
Torej: imam prav, ali brcam v meglo?
Npr.:
x=1 //1. ukaz
x=x+5 //2. ukaz
y=x+3 //3. ukaz
z=x+y //4. ukaz
1. jedro izvaja 1. ukaz, istočasno naj bi 2. jedro drugi ukaz, 3. jedro 3. ukaz, 4. jedro pa 4. ukaz. Vendar ne gre tako.
Medtem, ko 1. jedro izvaja 1. ukaz, 2. jedro ne ve, koliko je x, da bi ga povečal za 5. Čakati mora. da 1. jedro opravi svoje. Ko pa to opravi pa lahko kar 1. jedro izvede naslednji ukaz.
Tudi 3. jedro ne more nič, saj ne ve, koliko je x, da bi mu prištel 3 in shranil vrednost v y.
Sploh pa ne 4. jedro, ki ne ve niti vrednost x-a, niti vrednost y-a.
Aplikacije pa se lahko napiše tudi tako, da so sestavljene iz več 'niti' (ne vedno, kdaj pa vseeno). Npr.:
x=1
x=x+5
y=5
y=y-3
z=5+3
z=z-2
To se lahko izvaja istočasno, ker se spremenljivke ne navezujejo ena na drugo. Seveda je to slab primer, ker je preveč poenostavljen, pa še istega rezultata ne da, kot gornji.
Boljši primer bi bil kakšen praktičen, npr. za igre.: Ena nit bi bla fizika, druga nit grafika, tretja nit zvok.. In namesto da jedro preračunava za vsako sličico FizikaGrafikaZvok, FizikaGrafikaZvok, FizikaGrafikaZvok, ... , lahko vsako jedro poskrbi za eno izmed teh stvari za eno sličico. Tako je npr. potrebno čakati za sličico 3x manj, kar je 3x večji fps. Teoretično.
Ko bomo imeli 10-jedrne procesorje, bodo pač niti še povečali. Npr. fizika igralca, fizika okolja, fizika drugih igralcev, grafika za vsakega posebej, zvočni efekti za vsakega posebej. Vse le zato, da se druga jedra ne 'dolgočasijo' in pomagajo zraven. S tem bi rad povedal le to, da je izboljšanje programov in OS-ov delo programerjev.
Lahko pa vsako jedro opravlja svoje procese, istočasno. Medtem, ko 1. jedro odpira Word, lahko 2. jedro predvaja glasbo, 3. jedro predvaja film, 4. jedro pa odpira internetne strani.
Torej: imam prav, ali brcam v meglo?
Don't pay the BILL at the big GATES.
Izi ::
>>Torej: imam prav, ali brcam v meglo?
Vse ni čisto tako, ampak v bistvu imaš prav
Za vsak proces, ki ga zaženeš lahko sam ročno izbereš katero jedro naj ga izvaja.
Če pa ne določiš nič, pa ga OS po defaultu dodeli v izvajanje vsem procesorjem hkrati.
Tudi, če je program napisam samo eno nitno, ga ne bo izvajal samo prvi procesor ostali pa bodo počivali, ampak vsak od procesorjev, ki so na razpolago prevzame določen del izvajanja prograna.
Problem je da naprimer pri dveh jedrih vsak procesor lahko prevzame samo polovico izvajanja in rezulatat je da vsak procesor deluje samo z 50% obremenjenostjo in program ne deluje nič hitreje kot na enojedrnem PC-ju, samo računalnik je manj obremenjen.
Torej če imaš 10 jedrni računalnik bo vsako jedro prevzelo desetino izvajanja programa.
Če pa je program napisan večnitno pa lahko vsak procesor prevzame celotno nit in jo izvaja z 100% obremenjenostjo.
Seveda bo z večanjem števila jeder potrebno tudi v programih večati število niti, da bo lahko vsak procesor vedno lahko izvajal svojo nit. Tako, da bodo programerji od sedaj naprej vedno morali nanovo pisati programe za optimalno delovanje na večjem številu procesorjev.
Če je program napisan v dveh nitih, bo na dvojedrnem procesorju deloval optimalno, ker bo vsak procesor 100% obremenjen, na 4-jedrnem sistemu pa si bosta spet morala dva procesorja deliti eno nit in bodo torej vsi štirje procesorji delovali z 50% obremenjenostjo. Torej bo treba program spet posodobiti in napisati štirinitno.
Zadnje čase sicer nisem več neki programer, vendar vseeno vem, da je dvonitno programiranje dvakrat bolj komplicirano kot normalno programiranje.
Pri štirinitnrm programiranju je vse skupaj štirikrat težje in se mimogrede izgubiš, ker vseskupaj postane hudo nepregledno.
Kdo bo programiral 10 in več nitno mi pa ni jasno, ker se mi zdi, da človek tega ni sposoben.
Verejtno bo potrebno v prihodnosti narediti neki program, ki bo normalne programe sam spreminjal v večnitne.
Teoretično bi torej lahko na N-jedrnem procersorju dosegli n-kratno hitrost, ampak to se ne bo pomoje nikoli zgodilo, ker program ne bo nikoli tako dobro napisan.
Bolj verejtno bodo programirali tako, da bodo program pisali v več ločenih delih kot je to omenil Gizmo zgoraj in potem dodelili izvajanje določenih delov na druge procesorje, kar pa še zdaleč ni optimalno, ker ti deli ne bodo nikoli obremenjevali vsak procesor enakomerno.
Vse ni čisto tako, ampak v bistvu imaš prav
Za vsak proces, ki ga zaženeš lahko sam ročno izbereš katero jedro naj ga izvaja.
Če pa ne določiš nič, pa ga OS po defaultu dodeli v izvajanje vsem procesorjem hkrati.
Tudi, če je program napisam samo eno nitno, ga ne bo izvajal samo prvi procesor ostali pa bodo počivali, ampak vsak od procesorjev, ki so na razpolago prevzame določen del izvajanja prograna.
Problem je da naprimer pri dveh jedrih vsak procesor lahko prevzame samo polovico izvajanja in rezulatat je da vsak procesor deluje samo z 50% obremenjenostjo in program ne deluje nič hitreje kot na enojedrnem PC-ju, samo računalnik je manj obremenjen.
Torej če imaš 10 jedrni računalnik bo vsako jedro prevzelo desetino izvajanja programa.
Če pa je program napisan večnitno pa lahko vsak procesor prevzame celotno nit in jo izvaja z 100% obremenjenostjo.
Seveda bo z večanjem števila jeder potrebno tudi v programih večati število niti, da bo lahko vsak procesor vedno lahko izvajal svojo nit. Tako, da bodo programerji od sedaj naprej vedno morali nanovo pisati programe za optimalno delovanje na večjem številu procesorjev.
Če je program napisan v dveh nitih, bo na dvojedrnem procesorju deloval optimalno, ker bo vsak procesor 100% obremenjen, na 4-jedrnem sistemu pa si bosta spet morala dva procesorja deliti eno nit in bodo torej vsi štirje procesorji delovali z 50% obremenjenostjo. Torej bo treba program spet posodobiti in napisati štirinitno.
Zadnje čase sicer nisem več neki programer, vendar vseeno vem, da je dvonitno programiranje dvakrat bolj komplicirano kot normalno programiranje.
Pri štirinitnrm programiranju je vse skupaj štirikrat težje in se mimogrede izgubiš, ker vseskupaj postane hudo nepregledno.
Kdo bo programiral 10 in več nitno mi pa ni jasno, ker se mi zdi, da človek tega ni sposoben.
Verejtno bo potrebno v prihodnosti narediti neki program, ki bo normalne programe sam spreminjal v večnitne.
Teoretično bi torej lahko na N-jedrnem procersorju dosegli n-kratno hitrost, ampak to se ne bo pomoje nikoli zgodilo, ker program ne bo nikoli tako dobro napisan.
Bolj verejtno bodo programirali tako, da bodo program pisali v več ločenih delih kot je to omenil Gizmo zgoraj in potem dodelili izvajanje določenih delov na druge procesorje, kar pa še zdaleč ni optimalno, ker ti deli ne bodo nikoli obremenjevali vsak procesor enakomerno.
Zgodovina sprememb…
- spremenil: Izi ()
snow ::
Izi
lahko da je 1000 nitno enako težko kot 2 nitno.
Recimo da imaš nek problem in ga lahko razbiješ na N enakih delov, kot je naprimer vsota števil od 1 do 1000.
Vsaka nit izračuna delno vsoto za 1000/N števil in na koncu se zadeva posumira v končno vsoto. Enako lahko delajo npr. kakšni grafični programi ala Photoshop. Maš en npr. blur in X * Y pikslov. Zdej pač si niti lepo pošteno() razdelijo delo med sabo.
Alpa če se gremo mal bolj hardcore zadevo.. mamo en evolucijski algoritem in lahko populacijo razdelimo na subpopulacije.... itd. itd.
So pa taki pristopi veliko bolj zapleteni kot enonitni ja ;)
lahko da je 1000 nitno enako težko kot 2 nitno.
Recimo da imaš nek problem in ga lahko razbiješ na N enakih delov, kot je naprimer vsota števil od 1 do 1000.
Vsaka nit izračuna delno vsoto za 1000/N števil in na koncu se zadeva posumira v končno vsoto. Enako lahko delajo npr. kakšni grafični programi ala Photoshop. Maš en npr. blur in X * Y pikslov. Zdej pač si niti lepo pošteno(
) razdelijo delo med sabo.Alpa če se gremo mal bolj hardcore zadevo.. mamo en evolucijski algoritem in lahko populacijo razdelimo na subpopulacije.... itd. itd.
So pa taki pristopi veliko bolj zapleteni kot enonitni ja ;)
Random mutation plus nonrandom cumulative natural selection - Richard Dawkins
Zgodovina sprememb…
- spremenilo: snow ()
Matevžk ::
Ja, ko sem začenjal z učenjem programiranja (samoiniciativno tako nekako pri manj kot 10 letih), sem v neki knjigi (Delphi od začetka do aplikacije - Uroš Mesojedec) prebral, da je pač večnitno programiranje izredno zahtevno in zaradi tega tudi error-prone. Kot vzoren primer je bil podan MS Word 95, ki je menda (ravno zato, da ne bi programerji naredili preveč napak) vseboval samo dve niti -- tiskanje je imelo svojo nit, vse ostalo pa je bilo skupaj. Zato je Mesojedec večnitno programiranje odsvetoval, razen če RES pomaga in sta nalogi izredno ločeni.
In včasih je to popolnoma držalo.
Dandanes pa mislim, da so programski jeziki (in pripadajoče knjižnice) toliko napredovali, da je večnitno programiranje ob ustreznem vnaprejšnjem načrtovanju zelo enostavno. Primer lahko podam iz Jave (kjer sem se že nekaj ukvarjal s tem), kjer obstajajo objekti, ki jim podamo Runnable objekte, ki vsebujejo naloge za izvedbo, potem jih pa določeno število predpripravljenih niti (da ni za vsako nalogo inicializacije) obdela po vrsti (FIFO, prioritetno, ali kako drugače). Obstaja seveda še 100 drugih pristopov.
Pri igrah ste že ugotovili, da je ločitev nalog dokaj očitna (torej nima smisla delati z omenjenimi vrstami, ampak kar z namenskimi nitmi), le "glavna" nit mora počakati, da ostale niti dokončajo svoje delo, kar se v modernih jezikih prav tako naredi z blazno preprostostjo.
Da, da, prihodnost je svetla, pa ne samo v igrah
In včasih je to popolnoma držalo.
Dandanes pa mislim, da so programski jeziki (in pripadajoče knjižnice) toliko napredovali, da je večnitno programiranje ob ustreznem vnaprejšnjem načrtovanju zelo enostavno. Primer lahko podam iz Jave (kjer sem se že nekaj ukvarjal s tem), kjer obstajajo objekti, ki jim podamo Runnable objekte, ki vsebujejo naloge za izvedbo, potem jih pa določeno število predpripravljenih niti (da ni za vsako nalogo inicializacije) obdela po vrsti (FIFO, prioritetno, ali kako drugače). Obstaja seveda še 100 drugih pristopov.
Pri igrah ste že ugotovili, da je ločitev nalog dokaj očitna (torej nima smisla delati z omenjenimi vrstami, ampak kar z namenskimi nitmi), le "glavna" nit mora počakati, da ostale niti dokončajo svoje delo, kar se v modernih jezikih prav tako naredi z blazno preprostostjo.
Da, da, prihodnost je svetla, pa ne samo v igrah
lp, Matevžk
chaos_AK ::
Npr.:
x=1 //1. ukaz
x=x+5 //2. ukaz
y=x+3 //3. ukaz
z=x+y //4. ukaz
1. jedro izvaja 1. ukaz, istočasno naj bi 2. jedro drugi ukaz, 3. jedro 3. ukaz, 4. jedro pa 4. ukaz. Vendar ne gre tako.
Medtem, ko 1. jedro izvaja 1. ukaz, 2. jedro ne ve, koliko je x, da bi ga povečal za 5.
Kolikor vem, zanekrat ne obstaja tak računalnik, ki bi znal enonitne programe razdeliti večim procesorjem. S tem razdeljevanjem (oz. out-of-order execution-om) ima probleme že eno samo jedro.
Vendar v tvojem primeru lahko tisti x izračuna po poljubnem vrstnem redu: lahko najprej izvede ukaz 1, nato prediction v procesorju vidi, da lahko izvede ukaz 3, brez da bi vedel rezultat prejšnje operacije in na koncu izvede še ukaz 2. Rezultat bo na koncu isti.
...
z=5+3
z=z-2
To se lahko izvaja istočasno, ker se spremenljivke ne navezujejo ena na drugo.
...
Tudi to se ne bo avtomatsko izvajalo na večih procesorjih, ker scheduler operacijskega sistema tega ne bo razdelil na več niti.
Problem je da naprimer pri dveh jedrih vsak procesor lahko prevzame samo polovico izvajanja in rezulatat je da vsak procesor deluje samo z 50% obremenjenostjo in program ne deluje nič hitreje kot na enojedrnem PC-ju, samo računalnik je manj obremenjen.
Ene same niti ni preveč pametno prestavljati iz enega procesorja na drugega, ker je to povezano z velikim stroški (zato se da programom določiti cpu affinity, da se skoz izvajajo na enem procesorju) - če jo pustiš na enem procesorju, se bo hitreje izvedla.
Če pa je program napisan večnitno pa lahko vsak procesor prevzame celotno nit in jo izvaja z 100% obremenjenostjo.
Ni rečeno, da vsaka nit obremeni procesor enako. Tako bi lahko npr. en procesor izvajal nit, kjer mora recimo vsako 1ns sešteti x in y.
Drug procesor bi pa v drugi niti moral zračunati x+y+x/y*x*z*123*nevemkaj, v glavnem nekaj računsko precej bolj zahtevnega. Tako bi procesor 1 že zdavnaj končal z delom, ko bi drugi še kar računal.
Niti ne moreš 'ustvariti' kar iz lepega, moraš imeti nek problem, ki se ga da dobro paralelizirati. Vsega se ne da, zato nikoli 10-jedrni procesor ne bo enak enemu, ki je 10x hitrejši.
Programirati z nitmi sploh ni problem (vsaj na unixih
), problem je računanje razdeliti na n enakih delov, da bodo vsi procesorji približno enako obremenjeni in bodo naenkrat končali z delom. Kaki filtri za slike ali video recimo se dajo zelo lepo paralelizirati .Res pa je tudi, da na nekem osebnem računalniku operacijski sistem izvaja večje število programov, tako da ni ravno problem enakomerno porazdeliti dela med več procesorjev.
Tako da če bi mi kdo podaril enega Athlona X2, ga ne bi (takoj) vrgel stran
You must die ... I alone am best!
64202 ::
Matezvk: niti v javi so v osnovi* izvedene skoraj popolnoma enako nevarno kot win32 api leta 95 :). Moderni jeziki/runtime-i za paralelizacijo dokaj avtomatsko pohendlanjo:
- alociranje threadov
- zascito podatkov (nic ni treba mutexov, torej deadlocki vecinoma odpadejo)
- sinhronizacijo (skoraj nic ogabnih semaforjev/ipd.)
- ...
Popolnoma mozno je napisat cisto varne programe, ki laufajo stotine threadov.
Vse skupaj je podobno kot garbage collector vs rocno hendlanje rama.
* ima pa layer preko ostrih robov: Package java.util.concurrent. Se en C# video: Concurrency and Coordination Runtime
- alociranje threadov
- zascito podatkov (nic ni treba mutexov, torej deadlocki vecinoma odpadejo)
- sinhronizacijo (skoraj nic ogabnih semaforjev/ipd.)
- ...
Popolnoma mozno je napisat cisto varne programe, ki laufajo stotine threadov.
Vse skupaj je podobno kot garbage collector vs rocno hendlanje rama.
* ima pa layer preko ostrih robov: Package java.util.concurrent. Se en C# video: Concurrency and Coordination Runtime
I am NaN, I am a free man!
Gizmo_X ::
x=1 //1. ukaz
x=x+5 //2. ukaz
y=x+3 //3. ukaz
z=x+y //4. ukaz
Vendar v tvojem primeru lahko tisti x izračuna po poljubnem vrstnem redu: lahko najprej izvede ukaz 1, nato prediction v procesorju vidi, da lahko izvede ukaz 3, brez da bi vedel rezultat prejšnje operacije in na koncu izvede še ukaz 2. Rezultat bo na koncu isti.
Po izvršitvi ukaza 1:
x=1; y=0; z=0
Po izvršitvi ukaza 3, brez 2:
y=x+3=1+3 // y=4
Potem šele ukaz 2:
x=x+5=1+5 // x=6
Ukaz 2 je res vseeno, kdaj se izvede. Recimo, da se je izvedel drugi. Torej x=6; y=0; z=0. Potem pa tretji:
y=x+3=6+3 // y=9 (prej pa 4, kako je lahko rezultat na koncu isti?)
z=5+3
z=z-2
Tudi to se ne bo avtomatsko izvajalo na večih procesorjih, ker scheduler operacijskega sistema tega ne bo razdelil na več niti.
Avtomatsko se res ne bo izvajalo kar na večih procesorjih ali jedrih. Je pa tukaj možnost, da programer to ustvari kot posebno nit, ki se ne navezuje na ostali 2 niti. Čeprav slab primer, je pa le enostaven.
Ni rečeno, da vsaka nit obremeni procesor enako. Tako bi lahko npr. en procesor izvajal nit, kjer mora recimo vsako 1ns sešteti x in y.
Drug procesor bi pa v drugi niti moral zračunati x+y+x/y*x*z*123*nevemkaj, v glavnem nekaj računsko precej bolj zahtevnega. Tako bi procesor 1 že zdavnaj končal z delom, ko bi drugi še kar računal.
Se strinjam. Ni enostavno razdeliti problem na niti, ki bodo enako obremenjevale procesor.
Moja misel/rešitev, čeprav mogoče malo neumno:
Primer iger - streljačine. Vsak igralec ima svoj nit. Vsaka nit za posameznega igralca izračunava fiziko, grafiko, zvok, ipd. Prva nit bi morala opraviti s fiziko, grafiko ter zvokom prvega igralca, druga nit z vsem tem za drugega igralca.. Tako bi bilo vsaj približno enako porazdeljeno.
Moja 2. misel/rešitev:
Npr. 4 jedra, 8 igralcev: 4 jedra najprej fiziko 4 igralcev. Ko neko jedro konča fiziko igralca, gre naprej računat fiziko naslednjega igralca (da ne čaka drugih jeder). Ko zmanjka fizike za igralce, potem hitro še na grafiko, potem pa še na zvok. V bistvu 3*8=24 niti. Jedra pa po končanju ene niti začnejo opravljanje druge niti. Tako bi bilo res zelo izkoriščeno. Imam prav?
Niti ne moreš 'ustvariti' kar iz lepega, moraš imeti nek problem, ki se ga da dobro paralelizirati. Vsega se ne da, zato nikoli 10-jedrni procesor ne bo enak enemu, ki je 10x hitrejši.
10-jedrni procesor res ne bo nikoli enak enemu, ki je 10x hitrejši. Bo pa mogoče cenejši. Da ne omenjam 2 5-jedrna procesorja, ali 3 4-jedrni procesorjev.
Programirati z nitmi sploh ni problem (vsaj na unixih ), problem je računanje razdeliti na n enakih delov, da bodo vsi procesorji približno enako obremenjeni in bodo naenkrat končali z delom. Kaki filtri za slike ali video recimo se dajo zelo lepo paralelizirati.
Tudi z 10 nitmi ni problem programirati? Kako praktična/izvedljiva pa je moja (2.) rešitev (razdeliti vse skupaj na veliko manjših niti, da en procesor/jedro ne čaka na drugega?
x=x+5 //2. ukaz
y=x+3 //3. ukaz
z=x+y //4. ukaz
Vendar v tvojem primeru lahko tisti x izračuna po poljubnem vrstnem redu: lahko najprej izvede ukaz 1, nato prediction v procesorju vidi, da lahko izvede ukaz 3, brez da bi vedel rezultat prejšnje operacije in na koncu izvede še ukaz 2. Rezultat bo na koncu isti.
Po izvršitvi ukaza 1:
x=1; y=0; z=0
Po izvršitvi ukaza 3, brez 2:
y=x+3=1+3 // y=4
Potem šele ukaz 2:
x=x+5=1+5 // x=6
Ukaz 2 je res vseeno, kdaj se izvede. Recimo, da se je izvedel drugi. Torej x=6; y=0; z=0. Potem pa tretji:
y=x+3=6+3 // y=9 (prej pa 4, kako je lahko rezultat na koncu isti?)
z=5+3
z=z-2
Tudi to se ne bo avtomatsko izvajalo na večih procesorjih, ker scheduler operacijskega sistema tega ne bo razdelil na več niti.
Avtomatsko se res ne bo izvajalo kar na večih procesorjih ali jedrih. Je pa tukaj možnost, da programer to ustvari kot posebno nit, ki se ne navezuje na ostali 2 niti. Čeprav slab primer, je pa le enostaven.
Ni rečeno, da vsaka nit obremeni procesor enako. Tako bi lahko npr. en procesor izvajal nit, kjer mora recimo vsako 1ns sešteti x in y.
Drug procesor bi pa v drugi niti moral zračunati x+y+x/y*x*z*123*nevemkaj, v glavnem nekaj računsko precej bolj zahtevnega. Tako bi procesor 1 že zdavnaj končal z delom, ko bi drugi še kar računal.
Se strinjam. Ni enostavno razdeliti problem na niti, ki bodo enako obremenjevale procesor.
Moja misel/rešitev, čeprav mogoče malo neumno:
Primer iger - streljačine. Vsak igralec ima svoj nit. Vsaka nit za posameznega igralca izračunava fiziko, grafiko, zvok, ipd. Prva nit bi morala opraviti s fiziko, grafiko ter zvokom prvega igralca, druga nit z vsem tem za drugega igralca.. Tako bi bilo vsaj približno enako porazdeljeno.
Moja 2. misel/rešitev:
Npr. 4 jedra, 8 igralcev: 4 jedra najprej fiziko 4 igralcev. Ko neko jedro konča fiziko igralca, gre naprej računat fiziko naslednjega igralca (da ne čaka drugih jeder). Ko zmanjka fizike za igralce, potem hitro še na grafiko, potem pa še na zvok. V bistvu 3*8=24 niti. Jedra pa po končanju ene niti začnejo opravljanje druge niti. Tako bi bilo res zelo izkoriščeno. Imam prav?
Niti ne moreš 'ustvariti' kar iz lepega, moraš imeti nek problem, ki se ga da dobro paralelizirati. Vsega se ne da, zato nikoli 10-jedrni procesor ne bo enak enemu, ki je 10x hitrejši.
10-jedrni procesor res ne bo nikoli enak enemu, ki je 10x hitrejši. Bo pa mogoče cenejši.
Da ne omenjam 2 5-jedrna procesorja, ali 3 4-jedrni procesorjev. Programirati z nitmi sploh ni problem (vsaj na unixih ), problem je računanje razdeliti na n enakih delov, da bodo vsi procesorji približno enako obremenjeni in bodo naenkrat končali z delom. Kaki filtri za slike ali video recimo se dajo zelo lepo paralelizirati.
Tudi z 10 nitmi ni problem programirati? Kako praktična/izvedljiva pa je moja (2.) rešitev (razdeliti vse skupaj na veliko manjših niti, da en procesor/jedro ne čaka na drugega?
Don't pay the BILL at the big GATES.
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Prihodnost Itaniuma znana 26. aprila?Oddelek: Novice / Procesorji | 4351 (3834) | MrStein |
| » | Apple končno predstavil Mac Pro z 8 jedriOddelek: Novice / Procesorji | 5395 (3851) | Jst |
| » | Informacije o Intel KentsfieldOddelek: Novice / Procesorji | 3640 (2655) | kopriwa |
| » | Intel: Core 2 Duo in znižanje cen 23. julijaOddelek: Novice / Procesorji | 6899 (4123) | bond007 |
| » | Novice iz Intelovih logovOddelek: Novice / Procesorji | 3481 (3011) | elasto_mania |