Slashdot - Obrnjeno večnitenje, v originalu reverse multi-threading, je nov trik, ki ga, če gre verjeti Reg Hardwaru in Slashdotu, raziskujejo AMD-jevi inženirji. Ideja je preprosta. Intel je s pomočjo svojega večnitenja operacijski sistem prepričal, da ima na razpolago dva procesorja, kar je blagodejno vplivalo na hitrost in učinkovitost. AMD namerava storiti nasprotno. Jasno je, da dva procesorja nista ekvivalentna enemu procesorju z dvakrat višjo nazivno frekvenco. Toda AMD pravi, da jih utegne nova tehnologija, ki jo razvijajo za procesorje generacije, ki bo sledila K8, k temu približati. Kakorkoli že, preden (in če sploh) bo ta tehnologija zapustila razvojne laboratorije, bo preteklo še mnogo vode, programska industrija pa se bo dodobra navadila večnitenja. Vprašanje je, če bodo hoteli nazaj.
Za gamerje super, vendar pa nekateri potrebujemo čimveč različnih opravil hkrati. Že HT je bil super, če si ga izkoristil; večjedrni procesorji še boljše. To, kar dela AMD, bi pa jaz rekel: Limited Usability.
Če bi zadevo naredili hitro, bi nekako lahko prevzeli krono nazaj, četudi jim pade s Conrojem z glave. Glede na to, da trenutno večprocesorskih/večjedrnih sistemov ne podpira ravno veliko programske opreme, bi na ta način pridobil kar lep del uporabnikov. Je pa vprašanje, koliko časa bodo zadevo pacali in nenazadnje to, kako hitro se bo uporaba multithreadinga razširila v svetu iger in ostalega softwera. Jo bo upanje na tako tehnologijo upočasnilo? Je to samo nateg?...
HT je že kul, ampak tole pa je še bolje če jim bo uspelo ven iztisnit željen performance. Tud za HT rabiš običajno posebej spisan software (tako kot za dvojedrnike). Reverse HT pa se bo požvižgal na to in bo izkoristil večji potencial moči tud pri nepatchanih programih. Zna bit zanimivo. Upam da bojo poleg te zasukane stvari uporabil tud normalni HT (pač pod drugim trejdmark imenom kot Intel).
Točno o tem sem že pred leti razmišljal. V bistvu so mi ukradli idejo
Nima veze kako se bo multi-threading že uveljavil. Če se bo reverse multi-threading izkazal za boljšega ne vidim ovire zakaj ne bi takoj prevzel prestola. Največji problem sedanjega multi-threadinga je, da morajo biti vsi programi napisani nanovo, da v celoti podprejo dvojedrnike. Za štiri jedrnike jih bo potrebno spet napisati popolnoma nanovo, da bodo v celoti izkoristili vsa štiri jedra.
Pri reverse multi-threadingu pa vse to odpade. Že današnji prograni bi v celoti izkoristili vsa jedra ne glede na to koliko bi jih bilo.
Če ne bo AMD kaj zavozil pri razvoju si upam staviti, da je v reverse multi-threading prihodnost.
Hja, nobena huda revolucija tole. U akademskih že krogih dolgo znana zadeva. Tam so temu pač rekl 'hardware multithreading'.
Namesto da se programer matra in razbija softver na nitke etc, se v čip vdela enota ki to dela on the fly. Iz ukaznega toka ekstrahira medsebvoj neodvisna zaporedja ukazov - niti. Profit je, da tudi čisto običajno programi profitirajo z večjedrnimi CPUji. Če pa je že software več niten pa še tolk bolš.
Največji problem sedanjega multi-threadinga je, da morajo biti vsi programi napisani nanovo, da v celoti podprejo dvojedrnike. Za štiri jedrnike jih bo potrebno spet napisati popolnoma nanovo, da bodo v celoti izkoristili vsa štiri jedra.
Ni nujno res.. za štirijedrnike ne bo treba spisati vecina programov popolnoma na novo oz. sploh jih ne bo treba kaj dosti prilagajati stirijedrnikom, ce je ze pred tem primerno paraleliziran. Najtezji del je opravilo (program) paralelizirati saj se nekatera opravila tezko ali pa sploh ne da paralelizirati. Ko je enkrat opravilo paralelizirano in program napisan ustrezno paralelno pa vec ni potrebno dosti truda, da se ga prilagoditi za stevilo procesorjev v racunalniku. Seveda pa tak kot vedno obstajajo izjeme - recimo ce se opravilo ne da razbiti na vec kot 2 dela.
Ja, dost je da podpirajo večnitno procesiranje. Se pravi če znajo sukat 2 procesorja/jedra bojo najverjetneje znal pognat tud 16 procov/jeder. Seevda če niso program naredil s fixno hardcodano podporo samo 2 simultanima nitima. Ampak če so pametni tega niso storil...
Hja, no jaz sem misli, če bi en sedanji program razdelili na dve niti, bi na dvojedrniku delal z polno hitrostjo, na štirijedrniku pa samo z polovično hitrostjo.
Seveda, če ga že na začetku razbijejo na 10 niti bo dobro deloval vse do desetjedrnika. Ne spoznam se toliko na večnitno programiranje, ampak a ni tako, da kolokor več niti toliko bolj komplicirano je programiranje? Zato sem si predstavljal, da bodo sedaj programe prirejali samo na dve niti, ker je to precej bolj enostavno. In nato lahko za vsako podvojitev niti spet izdajo novo verzijo, ki jo spet prodajajo za polno ceno
To je podobno kot SLI pri grafičnih karticah (dva procesorja delata kot eden) pohitritev je lahko tudi do 80%. Komaj čakam kakšen quad core v 2x "sli" ... bye bye conroe...
Seevda če niso program naredil s fixno hardcodano podporo samo 2 simultanima nitima. Ampak če so pametni tega niso storil...
Čevljar razglablja o umetnosti peke kruha...
Redkoredki so problemi, kjer je možno rešitev implementirat v obliki poljubno mnogo medsebojno neodvisnih nitk. Pa še to so v veliki večini čisto akademske sorte. Zgolj v ilustracijo da se da, v realnem pa so neuporabni.
Realni problemi majo to smotano lastnost da so "serijsko odvisni", količina "serijsko neodvisnih" operacij je vedno omejena. Pri vsakem problemu prideš do koraka, ko moraš vedet rezultat prejšnjega koraka, da se lahko odločiš kako in kaj naprej. In v tem trenutku ti večnitnost pomaga 0 (nič). V realnih programih ni ravno mnogo stvari, kjer se splača zanje delat posebno nitko. Včasih se da, vendar ti nato ves overhead požre ves morebiten profit, pa še zgubo ti lahk nabije - vse skupaj teče počasneje, kot če bi se stvar izvajala v le eni ali par nitkah.
To je podobno kot SLI pri grafičnih karticah (dva procesorja delata kot eden) pohitritev je lahko tudi do 80%. Komaj čakam kakšen quad core v 2x "sli" ... bye bye conroe...
Grafika je en tak poseben problem, kjer je vzporednost obdelave "name of the game". Lepota je, da barva enega piksla običajno ni odvisna od barve sosednjega piksla. Če lahko naenkrat obdelaš 2x več pixlov, boš končal v polovici časa. Greš iz 16 na 32 cevovodov in pohitritev je občutna. So zram še detajli, ki zameglijo to enostavnost, vendar ideja v osnovi drži.
Pri CPUjih to ne drži. Splošni problemi so serijski. Še en procesor zram ti nič ne nuca, če že ta ku ga maš večino časa čaka da se bo trenutna operacija končala in da bo lahk njen rezultat pofutral naslednji operaciji.
WarpedOne: Pri CPUjih to ne drži. Splošni problemi so serijski. Še en procesor zram ti nič ne nuca, če že ta ku ga maš večino časa čaka da se bo trenutna operacija končala in da bo lahk njen rezultat pofutral naslednji operaciji.
Kaj nisi mal zamešal? Tukaj naj bi bila dva jedra videna in uporabljena kot ENO... torej bo verjetno dodan še kakšen vhodno-izhodni kontroler kot pri hyperthreadingu le da bo imel obratno nalogo... Jaz vidim tukaj možnost precejšnje pohitritve.
Maš tudi dosti paralelnih problemov pri CPUjih. Recimo kakšen CFD, kjer imaš računsko mrežo razdeljeno na celice, ali pa molekulsko modeliranje, kjer lahko do neke mere razbiješ zadevo na pararaleno računanje... pa grafična obdelava slik itd. itd.
Random mutation plus nonrandom cumulative natural selection - Richard Dawkins
Coolbits: Nism zamešal. Je pa verjetno, da se nisma dobr razumela.
Snow: Nism reku da "paralelizabilnih" problemov ni. Reku sm da so v manjšini. Večina je serijskih.
Na kratko: glavni profit tele ideje je, da se programerjem ni treba tolk ubadat, kako problem razbit na neodvisne kose, da bo to delu kr HW sam. Programerji pa bodo/bomo lahko programiral po starem, tko kot to znajo/znamo.
Včasih so moral programerji sprot skrbet za upravlanje s hardware-om in IRQji etc, pol so pršl drajverji in OS. Včasih so moral direkt pedenat ram, pol je pršu navidezn pomnilnik. Včasih so moral ves alociran pomnilink vračat, pol je pršu garbage-collection. Zdej morjo na roke sekat probleme na posamezne nitke, prihaja pa hardware multithreading. Kar je dobra stvar (tm).
Tole je, kakor jaz razumem, ena velika neumnost. Namesto dveh neodvisnih jeder s tremi izvajalnimi enotami dobiš enega s šestimi izvajalnimi enotami Če bi to pohitrilo delovanje procesorja za faktor dva, bi že zdavnaj imeli procesorje z osmimi+ izvajalnimi enotami. Pa jih nimamo.
Lahko pa drugi procesor uporabiš za branch prediction; samo pri agresivnem branch prediction gre veliko energije v nič. Zakaj torej imeti dvojedrni procesor, pri katerem eno jedro skrbi za izvajanje, drugo pa za branch prediction in s tem le dodatno npr. 30% učinkovitost za 100% več porabljene energije???
Največja napaka desetletja je bila narejena 4. novembra 2008
Oni so goljufali in Alah je goljufal, Alah je najboljši prevarant. (Koran 3:54)
Citiraj svetega očeta Benedikta XVI. in postani "persona rudis"...
Kaj to. Naj raje naredijo proc ekvavilent Cell-a, pa bo moč ala PS3.
Zakaj se mora v vsaki temi najt eden laik, ki primerja desktop procesor po zmogljivosti z Cellom (ki ga sploh še ni med uporabniki) in potem seveda predlaga da AMD/Intel/whoever raje razvije Cell zaradi superiornih zmogljivosti.
Cell ga suxxa, neuporaben za namembnost PCja in predvsem po zmogljivostih neprimerljiv. Kar se pa tiče programiranja zanj, pa naj ti kaj povedo kolegi razvijalci iger.
Tako kot je rekel warped... Stvari, ki bi jih lahko paraleliziral ni tako veliko stevilo. Nekaj jih je ampak ne prav dosti. Pohitritve bodo pa najbrz precej minimalne.
Multithreading je pa kar ok, primer tipicne igre je, en thread za zvok, drug za zvocne efekte, eden za komunikacijo in eden za user input in tako naprej.
Pa se tukaj je potrebno biti pazljiv, ker ti lahko kaka sinhronizacija kje odleti...
Po mojem zelo dobra ideja, če bo splavala dovolj hitro. Zadevo se bi lepo vklopilo ali izklopilo v BIOSu, tako da bi lahko, če bi procesor uporabljal za igranje enonitne igre funkcijo omogočil in recimo dobil 50 - 80% pohitritev (Če bi bila pohitritev 80% bi bilo to verjetno že precejšen dosežek, sam ne bi pričakoval preveč), ko pa bi želel isti sistem nameniti spletnemu strežniku, ali kaki večnitnosti bolj prijazni zadevi, pa bi se funkcijo izklopilo. Po mojem dobra zadeva, vredna pozornosti, samo od izvedbe pa bo vidna tudi dejanska uporabnost.
No, meni se pa zdi, da se ravno tatežki problemi dajo dobro paralelizirati. Od raznih (pre)kodiranj video/avdio posnetkov (kjer enostavno vsak procesor obdeluje svoj del), do recimo raznih simulacij, kjer se okolje običajno razbije na celice (spet več procesorjev si celice razdeli)... Drugače pa to z avtomatsko paralelizacijo je lahko rešeno tudi programsko... Ravno zadnjič sem bral, da zna tazadnji MSIL JIT prevajalnik že samodejno razbiti enostavne zanke, ki izvajajo neodvisne preračune, na več niti (nisem pa šel preizkušat)... Ne vem, če ni to vseeno enostavnejše in boljše kot v hardver vgrajevat... Se mi pa zdi, da bo tu hitro (po več kot par jedrih) postal problem dostop (oziroma vodilo) do pomnilnika...
> Multithreading je pa kar ok, primer tipicne igre je, en thread za zvok, drug za zvocne efekte, eden za komunikacijo in eden za user input in tako naprej.
mnja, trenutni sistemi tezijo k temu, da imas en master thread, in pa skupino worker/slave threadov. razbijanje posameznih taskov na posamezne threade se bojda ni tako dobro izkazalo. bad design imho :p
Abnormal behavior of abnormal brain makes me normal...
Tole je, kakor jaz razumem, ena velika neumnost. Namesto dveh neodvisnih jeder s tremi izvajalnimi enotami dobiš enega s šestimi izvajalnimi enotami
Jaz tudi tak vidim. Naredili so CPU z N enotamo namesto M. Kar poznamo že 10 let. Kaj je tu sploh novega, razen, da je stvar nekako modularna in lahko dodaš nove enote, ne da bi čist nov CPU naredil ?
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!
Jaz sem bral nekaj o tem na tujih forumih, samo na splošno nimajo lepih besed o tej tehnologiji. Vprašanje je, kaj je boljše: več energije nameniti za bolj spekulativen branch prediction za eno nit ali za dejansko izvajanje dveh niti.
Mislim, da s slednjim v istem času in z isto energijo več narediš; Samo compilerje je treba tako prilagoditi, kot sem že enkrat debatiral ne temu forumu: da se for(each) zanko označi, ali so posamezne iteracije neodvisne med seboj ali pa naslednje potrebujejo rezultate prejšnjih. Če so neodvisne, jih lahko compiler/OS spremeni v posamezne niti, če s pomočjo RDTSC benchmarkov ugotovi, da se izplača.
Največja napaka desetletja je bila narejena 4. novembra 2008
Oni so goljufali in Alah je goljufal, Alah je najboljši prevarant. (Koran 3:54)
Citiraj svetega očeta Benedikta XVI. in postani "persona rudis"...
Zanimiv clanek. Nekaj podobnega sem ze pocel v TBORP (text based online rpg... ;> ), ko ti vec threadov procesira razlicne dele igre in pripravi podatke za 'master thread', ki podatke posilja igralcem.
Sam uživam v njem že 2.5 leti:) Conroe pa mislim da bo končno spodobna menjava za moj P4c :P 
