AMD napovedal 16-jedrnike

kuglvinkl> BTW: Bible se ti bolj dopade? Milsm, boljš konverzija, boljši workflow?

Edini dela na mojem "službenem" operacijskem sistemu.

To samo pomeni, da bomo lahko poganjali več teh programov na enkrat, pa tudi posamezna jedra postajajo hitrejša (ne tako hitro kot so včasih, pa vseeno).

Tudi če si precej hud multitasker, imaš ponavadi kup nezahtevnih aplikacij (mp3 player, browser, mail client, IM client, text editor, ...), ki jih vse skupaj z lahkoto pomalica eno samo jedro, potem pa eno veliko, glavno aplikacijo (zahtevna igra, kako renderanje, konvertiranje videa, ...), ki je praktično edini izziv za procesiranje. Posledično tudi argument, da lahko poganjaš ohoho programov naenkrat, ni več pretirano smiseln, ker se to na desktopu precej redko počne. Posamezna jedra res postajajo hitrejša, tega ne zanikam, ampak kot osrednji napredek se izpostavlja množenje jeder, kar pa je definitivno vedno bolj zgrešeno.

Sicer pa se špekulira, da bi lahko bila odgovor na tvoj problem specilizirana jedra.
Namreč če bi imel 64 jederni CPU, bi lahko bilo zelo pametno, da bi recimo imel 2 jedra osredotočena na floating point, 2 na integer in še kaj.

Tako bi v splošnih visoko paralernih situacijah imel polno izkoriščenih v najslabšem primeru recimo 55 jeder (ostalih 9 glede na tvoj graf tako ali tako nebi bistveno pripomoglo),
V ne paralernih situacijah, pa bi program lahko tekel na tistem jedru, ki je najbolši za ta specifičen workload. Kar bi tudi zelo pospešilo izvajanje. Win Win ;)

Specializirani procesorji so v obliki grafičnih in zvočnih kartic ter floating-point koprocesorjev pred njimi že precej stara ideja, ki nima z omenjeno tematiko prav dosti povezave, so zgolj način za izboljšavo performans, ne odpravijo pa težav s paraleliziranjem.

Sej imaš že en kup raznih enot v enem jedru, nima smisla da bi imel tako zelo specializirana. Morda edino, da bi imel par jeder za grafiko, ampak niti to ni nujno, da so že vnaprej določena. Večanje števila jeder bo pa zadelo zid dosti prej, kot je zadelo zid višanje frekvence. Več kot 16 jeder res ne more imet smisla na domačem računalniku. Jih takoj zamenjam za 4, ali pa samo 2, če bi bla samo 50% hitrejša.

Res je, da imaš en kup enot v enem jedru.

Ampak če aplikacija lahko teče na samo enem jedru, potem je koristno da je čim več enot uporabnih za to aplikacijo (torej integer ali karkoli), namesto da je notri še veliko drugih enot ki se jih ne dotakne.

edit:
@jype XD

Specializirana JEDRA v procesorju, ne specializirani procesorji.

Nekako tako kot je trenutno SSE enota, FPU enota, ALU enota...? To že obstaja veš? Veliki čipi niso kul veš?

Nima smisla. Če bi imel procesor veliko FPU enot, lavfal bi pa integer...
Ali pa obratno...

ravno o tem govorim... Če bi imel na možnost 1 jedro z veliko FPU enot in 1 z veliko integer enot (predvidevam da obstajajo?), bi lahko aplikacijo assignal na tisto jedro ki ji bolje ustreza.

Je bolje, da ostanejo CPU jedra čim bolj multi-purpose.

Taki proci bi še vedno imeli veliko več splošnih jeder kot namenskih

Če pa želiš močno striktno FPU mašino pa jo daš na PCI-express režo. Imenuje se grafična kartice.

Res je, samo z napredkom CPUjev to nima veliko veze.

Nekako tako kot je trenutno SSE enota, FPU enota, ALU enota...? To že obstaja veš? Veliki čipi niso kul veš?

To bi bila ena lepot takega dizajna. Za razliko od enot, se jedra prav lepo izklapljajo če se jih ne rabi.
Čipi sami po sebi ne bi smeli biti zaradi tega nič večji. Kaj je več 64 jeder ali 60 splošnoh jeder in 1+1+1+1 namenskih jeder?

-če pa je zadeva serijska in na več kot enemu jedru ne more teči, potem je logično da bo tekla hitreje na jedru, ki je optimiziran za operacije kakršne jih rabi, kot bi na splošnem.

Recimo nekatere aplikacije delajo skoraj izključno floating point operacije, druge skoraj izklučno integer itd.

Na denašnjih CPUjih je vsako jedro enako in ima vsako jedro določen % tranzistorjev namenjen floating pointu, določen % za integer...
V prihodnosti pa bi lahko bilo eno jedro z veliko višjim % za integer kot ostala jedra in bi na tem jedru aplokacije z bottleneckom v integerju tekle hitreje.

Daj še ti malo logično razmišljaj... Če vzameš x86 CPU je to dejansko res, jedro ima določen procent tranzistorjev za floating point. 80 bit floating point FPU. Ko se pa zadovoljiš z 32 bitnimi floati ali 64 bitnimi doubli...
Kako pa misliš da ima čip implementirano floating point matematiko? 32 bit float ima 1 bit za predznak, 8 bitov eksponent, 23 bitna mantisa.
Rabiš dva floata seštet? Ustrezno bit shiftaš mantiso (tipična integer operacija), da se oba eksponenta ujemata in potem sešteješ obe mantisi (23 bitno integer seštevanje).
Rabiš dva floata množit? Množiš mantisi (23 bitno integer množenje), sešteješ eksponenta (8 bitno integer seštevanje).
ALU ima potem nekaj shifterjev, 32 bitni integer množnilnik, 32 bitni integer seštevalnik. Če ALU dobi ukaz za integer seštevanje, se routajo podatki na 32 bitni integer seštevalnik. Če ALU dobi ukaz za floating point seštevanje shifterji preshiftajo eno mantiso 32 bitni integer seštevalnik pa sešteje mantisi...
Kaj je torej profit da ene ALU-je onesposobiš za floating point in druge za integer?

Nisem govoril o onesposoblanju, govoril sem o večjem številu recimo FPUjev, ostali bi bili še vedno prisotni (v manših količinah).

Kaj bi s tem dosegel? Mogoče nič, mogoče manj kot nič, v redkih primerih pa mogoče precejšnjo pohitritev.
Point je v tem, da bi mogoče bilo vredno žrtvovat majhno količino jeder za zelo specifične operacije
Točen način izvedbe bom prepustil inžinirjem, ki se s tem ukvarjajo (btw. ta ideja ni moja...).

PS. ne mi morit z dejanskimi floating point operacijami, ker mi je slabo ko samo pomislim nanje (in čas zapravljen z njimi). Seveda mi je jasno da rabi procesor znat več kot eno operacijo...

Branch prediction ni dejanski branch, samo pove % možnost, da se bo nek branch zgodil, preden se dejansko izračuna. To ima veze s tem, kaj se naloži v pipeline pa tudi v cache (branch se glede na branch prediction naloži v sam pipeline še PREDEN je pogoj za branch izračunan).

Ne rabis mi predavat, kaj je branch prediction (imam diplomo iz racunalnistva in nekaj let delovnih izkusenj), sploh, copy/pastat. Zadeva, ki si jo skopiral ima nek rep in glavo (ceprav si to zdaj kar vrinil notri, da si se izognil odgovoru "iz glave"), tisto tvoje pisanje prej je pa nima in je golo natolcevanje.

Ko sem tisto prebral sem se kar malo nasmehnil.

Ampak?

[edit] Sem še 1x prebral svoj prvi post.

Kompajler opravi branch prediction pri zadevah, ki so staticne (v bistvu to sploh ni prediction, ampak se pogleda kaj se bo zgodilo, ukolikor je to sploh mogoce) ... veliko stvari pa je znanih sele v casu izvajanja (in nic prej) zato se morajo strategije predvidevanja uporabljat sele takrat.

Strategijo predvidevanja se mora uporabljati še PREDEN se izvedejo (ali se zapišejo v RAM ali ne nima veze), drugače je čisto vseeno, če se z branch prediction ne bi ukvarjal, ali pa bi imel čisto preprosti branch prediction, ki bi vedno slepo izbral prvo varijanto. KOlikor se meni zdi, sem že prvič čisto OK napisal.

Kaj bi s tem dosegel? Mogoče nič, mogoče manj kot nič, v redkih primerih pa mogoče precejšnjo pohitritev.

No, v večini primerov bi dosegel upočasnitev. Če specializirana jedra tam čakajo brez veze, ali pa delajo samo 10%, ker nimaš kaj pametnega za njih, si (zelo verjetno) dosegel upočasnitev. Če bi bla jedra splošna, jih bi zelo verjetno lažje izkoristil.
V zelo redkih primerih bi morda res dosegel pohitritev, ampak kaj ti pomaga...kako boš dosegel glih pravo razmerje med FPU in ALU za kar vse programe, da bo najboljše? Ker še zmeraj boš v vsakem jedru rabil oboje, samo da v specaliziranih bi blo enih enot malo več. Razmerje, ki ga imamo danes, verjetno ni nekdo iz rokava potegnil, zelo verjetno je kar dobro postavljeno, za splošne namene.

No, v večini primerov bi dosegel upočasnitev. Če specializirana jedra tam čakajo brez veze, ali pa delajo samo 10%, ker nimaš kaj pametnega za njih, si (zelo verjetno) dosegel upočasnitev. Če bi bla jedra splošna, jih bi zelo verjetno lažje izkoristil.
V zelo redkih primerih bi morda res dosegel pohitritev, ampak kaj ti pomaga...kako boš dosegel glih pravo razmerje med FPU in ALU za kar vse programe, da bo najboljše? Ker še zmeraj boš v vsakem jedru rabil oboje, samo da v specaliziranih bi blo enih enot malo več. Razmerje, ki ga imamo danes, verjetno ni nekdo iz rokava potegnil, zelo verjetno je kar dobro postavljeno, za splošne namene.

No končno nekdo, ki zgleda razume kaj mislm :), zgleda sem res nekoliko ne razumljiv :(

Anyway, tale cela saga se vsej deloma nanaša na tole in seveda na argumente da je brez veze delati procesorje s toliko jedri, ko pa ne moremo izkoristiti več kot dveh (v določenih primerih).

Upočasnitev bi bila verjetno minimalna oz. bi MOGOČE bila vredna glede na povratek v tistih redkih primerih. Zadeva bi postala smiselna šele ko bo res veliko jeder v vsakem CPUju.

"kako boš dosegel glih pravo razmerje med FPU in ALU za kar vse programe"
Ne boš. Saj tudi zdaj ni. Za večino jeder bi razmerje itak ostalo. Lahko pa bi bilo smisleno dati malo jederom drugačna razmerja, ki se bi nekaterim (ne vsem) programom bolje prilegala.

Uravnoteženost bi se ohranila:
zamisli si 90% jeder z istim razmerjem, ostalih 10% pa bi se razdelilo. (uporabil bom barve da se ne bom zaštrikal z enotami)

racimo 3.3% jeder dvojno rdeče berve (in pol manj ostalih), 3.3% dvojno modre in 3.3% dvojno rumene. Skupno razmerje barv bi v tem primeru ostalo enako ;)

Verjetno mi ne misliš povedati, da se ne da narest procesorja(jedra) ki bi bil bolj osredotočen na neke dejavnosti?

Seveda se da naredit specializiran procesor (GPU zelo dober primer). Ampak delit jedra na "tista, ki znajo floating point" in "tista, ki znajo integer aritmetiko" je pa tako kot pošiljat okrog policaje v dvojicah zato ker zna en pisat in drugi brat (razen, če res misliš da so tako neumni?)!
Današnji x86 CPU-ji sploh nimajo več FPU-ja kot neke posebne črne škatlice, tako kot je bilo to recimo v časih 80286, ko je obstajal še koprocesor 80287 za floating point. FPU kot tak sploh ne obstaja vač! Če i7 pride v programu na ukaz za množenje integerjev bo to zasedlo iste ALU-je kot če bo naletel na ukaz za množenje floatov (x87 del ukaznega nabora) ali pa na SSE ukaz za množenje 4 floatov...
Če hočeš specializacijo moraš najt eno nalogo, ki jo lahko z neko fiksno logiko implementiraš bistveno hitreje kot bi to naredil programsko. Če vzamem en zelo tipičen primer iz sveta GPU-jev: TMU (texture mapping unit). Dandanes lahko na GPU-jih s shaderji (splošno namenska logika) brez problema narediš vse kar dela TMU. Ampak te bo to stalo tolk performanc, da se je še Intel za Larrabee odločil vključit posebne TMU-je. Zato, ker so enote za to ozko usmerjeno opravilo bistveno cenejše (glede površine jedra), kot če bi poskušal stlačit gor dovolj veliko splošno namenskih ALU-jev.

Intel bo naredil multicore procesor z nekaj Core i7 jedri in večjim številom manjših Larrabee jeder.

Zahtevne računske operacije, ki jih je lahko paralelizirati, - tj. grafika, avdio/video, zahtevne matematične simulacije - bo teklo na LRB jedrih z močnimi float in integer performansi (glej LRBni).

Sicer pa, za katera opravila je danes en Quad Core2 3GHz procesor prepočasen?
Ali je za ta opravila pohitriti bolje:
a) dodati še štiri Core2 jedra?
b) dodati 32/64 Larrabee jeder?

Dober primer velike količine zelo počasnih jeder je uporaba Niagara SPARC za SQL. Mogoče Larrabee za SQL?

Bistri007> Sicer pa, za katera opravila je danes en Quad Core2 3GHz procesor prepočasen?

Se hecaš? Za en bogi hemoglobin v milijonu molekul vode simulirat jih rabiš vsaj 50 (procesorjev, 4 krat več corov torej) da si vsaj približno pri realtime.

jype, ja za simulacijo hemoglobina...
Moje vprašanje je bilo, za katera opravila je danes en Quad Core2 3GHz procesor prepočasen?

In potem dve povprašanji:
ali je za ta opravila pohitriti bolje:
a) dodati še štiri Core2 jedra?
b) dodati 32/64 Larrabee jeder?

Kaj je torej bolje za simulacijo hemoglobina? Dodatna Core2 jedra ali več manjših jeder z močnimi vektorskimi ukazi? Čeprav sem imel v mislih Desktop/Workstation, ne ravno clusterja.

To je nekaj podobnega kot Cell: eno splošno jedro, za dispatcher, in več manjših SPE za dejanske računske operacije.

MrStein, in kaj je za to bolje dodati še Core2 jedra ali dodatna GPU/Larrabee jedra?

CyberLink PowerDVD 8/9 ima HW pospeševanje za HD video