Intel: 8-10 év múlva jöhet az 1000 magos processzor
A gyártó háza táján elhangzó nyilatkozatok szerint nagyjából egy évtized kell a ma még szinte elérhetetlennek tűnő fejlesztés piacra dobásához, ám az igazi kérdés, hogy lesz-e rá valós igény.
A vállalat egyik mérnöke a napokban a ZDNet UK portálnak adott hosszabb interjút, amelyben nem csak a fejlesztés és egyéb munka várható időtartamát, hanem annak értelmét is megvitatták. A cikkből megtudhatjuk, hogy nagyjából egy évtized múlva remélhető az 1000 magos processzorok megjelenése, ám a legfontosabb kérdés nem is a periódus hosszával kapcsolatos.
A 8-10 éves ciklust a Moore-törvény alapján határozták meg, nagyjából ennyi kell ugyanis ahhoz, hogy nemrég bemutatott 48 magos prototípusból kiindulva a kétévenkénti duplázással eljussunk a bűvös számhoz. Az Intelen belül többé-kevésbé egyetértenek abban, hogy a gyártósorok tartani tudják majd az ütemet a fejlesztéssel, vagyis nem lesznek komolyabb gondok a gyártói részleg oldalán. Az említett prototípus, a 48 magos single-chip cloud computer (SCC) megfelelő alapnak tűnik, hiszen ezen 24 lapka (két-két maggal) helyezkedik el, amelyek egy mesh hálózaton keresztül kapcsolódnak egymáshoz. Minden 12 mag osztozik egy DDR3-memóriavezérlőn, a gyorsítótárat pedig úgy alakították ki, hogy az ideális legyen mind a tervezés, mind pedig a fogyasztás szempontjai alapján.
Az 1000 magos csodachipek kapcsán felmerül a kérdés, hogy mi szükség lesz ezen processzorokra. Ma is kaphatunk olyan grafikus vezérlőket, amelyek több mint 1500 feldolgozóegységgel érkeznek, ezek azonban finoman szólva nem ideálisak operációs rendszerek futtatásánál, illetve olyan bonyolult és komplex feladatok végrehajtásánál, amelyeken manapság szerverekkel dolgozunk. Nem véletlen, hogy mind az AMD, mind pedig az Intel olyan hibrid chipeken dolgozik, amelyek mindkét területen jól szerepelhetnek, ezért is helyeződik át a hangsúly egyre inkább a hagyományos x86 és grafikus magot egyaránt tartalmazó fejlesztésekre.
Végeredményben a piaci kereslet, vagyis a vállalatok és a felhasználók valós igényei határozzák majd meg a fejlesztés irányvonalát. Emlékezhetünk arra, hogy az Intel 80 magos fejlesztése sosem hagyta el a cég háza táját, még külső kutatók sem vehették kézbe azt - kérdés, hogy a címben is szereplő utód hasonló sorsra jut-e majd.
Hogy a viharba ne lenne?? Végre a szomszéd wifi kódját ki lehetne iktatni aprópénzzel... :D
Viccet félretéve, mérnököknek sosem lesz elég a processzor teljesítmény. És akkor még a NASA-ról nem is beszéltem.
Végeselemes szoftverek végtelennek tûnõ véges elemszámmal, komplex összeállítások, analízisek, megoldásuk 5 percen belül. Kiértékelés, módosítás és újrafuttatás.
Mindenképp kell az egyre bivajabb gép...
A technikai és programozási részleteknél oly sok sebbõl vérzik a mondókát, és oly nagy tudatlanságra vall, hogy sikerült alaposan megmosolyogtatnod engem, és pár ismerõsömet akiknek bemásoltam a hszedet :) .
Hev fán, és tanulj még sok-sok dolgot ;) , hogy legközelebb ne azért idézzenek mert vicces, hanem mert okosat mondasz.
hát én konkrétan egy pisikszes játékhoz configoltam füstöt, ott bizony minden részecske egy alpha channeles textúrás lap volt, ami random forgott, és sok darab volt belõle, így lett meg a füst effekt.
"Egyrészt, textúrázva vannak a folyadékok is néhol"
Én a tûznél találkoztam olyan techdemoval amiben a részecskéket (lángnyelveket) textúrázták. Igy jóval kevesebb részecskét kellett használni. Viszont az a tûz csak szimplán égett. A láng keletkezésénél a lobbanást, vagy a láng elfújását ezekkel nehéz szépen megoldani.
"és ez a lényeg, nem az hogy fizikailag korrekt legyen valami, hanem hogy JÓL nézzen ki"
Ebben teljesen igazad van. Egyrészt ezért nincs értelme csak részecskemodellezést használni. Másrészt ha a grafikusod egy olyan világot álmodik meg amely fizikailag nem korrekt, esetleg paradox, akkor azt egy fizikai szimuláción alapuló megjelenítéssel nehezen fogja megcsinálni. (Pl.: végtelen önmagába záródó lépcsõn lepattogó labda.)
"intelnek sincsenek akkora trükkjei ami nvidiának ne lenne ;)" Azért van: megfelelõ méretû cache, összetett vezérlõlogika. Persze van a fermiben cache, de mennyi is? Kevesebb mint 2MB összesen, magonként ez 4kB. Mennyi van egy intel prociban? Magonként 2MB. Na ez az a "trükk" amivel az intel automatikusan legyõzi a latencyt, anélkül hogy a programozó bármit is tudna.
Ha GPU-t akarsz programozni akkor ezt felejtsd el, ott soha nem lesz magonként 2MB, mert annyi áramköri elembõl inkább csinálnak plusz X db magot. A problémát pedig oldja meg a programozó.
"Ami egy komolyabb jelenetnél 20-30 giga. (mivel elõre nem tudjuk megmondani mire lesz szükségünk."
4 db Tesla C2070 kártyán van összesen 24GB memóra. Ez egy gépbe belemegy, mellé lehet még rakni legalább ugyanennyi rendszer memóriát. Persze egy GPU nem látja az egészet, de ez ütemezésel megoldható.
"és ott az elõadások, tréningek nagy része arról szól, hogyan küzdjünk meg az architektúrával, és hogy varázsoljuk elõ a számítási kapacitás kemény 10%-át" A probléma szerintem az hogy a programozás (és a programozók nagy része) az utóbbi idõkben eltávolodott az architektúrától, és itt nem csak a java-ra gondolok. A CPU vezérlõlogikája és a fordító megoldott helyettük minden proglémát. Aztán amikor találkoznak egy GPU-val rájönnek hogy mi is az a regiszter, latency, öszefüggõ memóriaolvasás.
A memóriasebesség problémákat pedig a csipbe épített optikai komunikációval meg lehet oldani. Persze nem ma, hanem amikor majd ezek a problémák kezelhetetlenül elhatalmasodnak.
Sok mindent leírtál, alapvetõen a következõ típusú problémákat vonultattál fel:
1. Nem megfelelõ az architektúra, hw. Errõl én is beszéltem lentebb, hogy a sok mag jelenlegi memória architektúrával semmit se ér. Amíg ez a gond nem oldódik meg, addig eleve nem lesznek millió magos procik, mert nem sokat érünk 1 millió 2kHz-s órajelû maggal.
2. Nincsenek megfelelõ fejlesztõi eszközök (ki rajzolja meg). Én úgy tudom a jelenlegi textúrázott polygonokat se úgy rajzolják meg, hogy beírják a csúcsok koordinátáit input mezõkbe. Vagyis ha lesz képesség a megjelenítésre, majd készítenek eszközöket is. És amivel több idõ egy kart vagy egy lábat összerakni úgy, hogy ez csont anyag, ez meg izom anyag, és függõlegesen erõsebb a kötés (úgy vannak a rostok) mint vízszintesen, itt meg vannak a szalagok, stb, annyival kevesebb idõ lesz megcsinálni a fizikáját.
Szóval persze, igazad van, most nincs ennek realitása. Ahogy az 1000 magos procinak sincs. De nem is errõl beszélt senki se.
Mindegy, röviden összefoglalva a sok mag nem ad önmagában egyszerû megoldást... Fõleg nem renderelésben... Erre a témára meg különösen harapok, mivel itt az átlag fórumozók majmolnak 3-4 mondatot, és mindenki tényként fogadja el, közben meg fingja sincs az egészrõl ;)
Tervbe volt véve a válasz, de mással foglalkoztam eddig...
Egyrészt, textúrázva vannak a folyadékok is néhol, persze legtöbbször procedurális textúrákkal, de textúrázva vannak / lehetnek. (pl nálunk inkább kitolják nagyobb felbontásba a folyadékokat - mint tûz, füst, vér stb - de nem textúrázzák, de az is egy lehetséges megoldás lenne)
Igen a hszetekbõl itélve nincs rálátásotok erre a problémára, de ha tévedtem gyõzzetek meg róla ;) (hint - shaderprogramozással is foglalkozok)
A felmerülõ probléma... Igaz, hogy a fizikai shadelésnek iszonyú elõnyei vannak, nehéz túllõni az anyagokat, nehezebb idióta beállításokat kreálni, kevesebb AOV (kevésbé van megterhelve a pipeline...), kevesebb beállítás magán az anyagokon... Ez baromi jó, csak mire ezt elfogadtatod egy grafikussal, kétszer kihullik a hajad. Ilyeneken ügyködök 2 hete (ünnepeket kivéve ofc), hogy a klasszikus össze-vissza tweakelhetõ shader fizikai alapú megoldásra legyen lecserélve, és a legnagyobb ellenállás a shaderezõktõl jön, mert hogy megszokták a régi módszert, nem lesz nukeba elég pass stb... Én meg tépem a hajam, hogy ezt kéne, nem a régit...
Ez egy jó párhuzam a textúrára... Hiába van neked egy baromi jól mûködõ, baromi jó fizikai alapú anyagod, ami össze-vissza töri meg szórja a fényt, ha az nem igazán állítható... Mondjuk van x mért anyagod, azokat tudod beállítani, és? Pont arra lesz szükséged ami hiányzik... És ha ilyen komplex fizikai modelleket valaki kézzel állítgat, akkor szinte lehetetlen olyan kinézetet létrehozni amit a mûvész szeretne (és ez a lényeg, nem az hogy fizikailag korrekt legyen valami, hanem hogy JÓL nézzen ki). Ebbõl a szempontból a textúrázás kilövõse agyhalál az összes art directornak...
Effektíve amit te mondtál, az is arról szól, hogy a voxelek (maradok ennél a terminológiánál, érthetõbb) tartalmazzák a szineket is (ezért írtam a 3d-s textúra kifejezést), de hol találsz olyan embert aki ezt megfesti neked belátható idõn belül? Persze nem mondom, hogy nem lehet, de egyelõre az ehhez kellõ eszközök is hiányoznak.
A technikai problémákra visszatérve... Látszik, hogy nincs programozási háttér, mert mindenki arra gondol, óh szuper 1000 mag, 250szer gyorsabb (4 maghoz képest), de a valóságban az a helyzet, hogy a memória alrendszer megöl mindent... Pl a videókártyákat nem a számítási teljesítmény fogja vissza, hanem a memória rendszer (nyilván nem játékokról beszélek, ahol elég speciális trükkök vannak). A kártyákba rakott 170G/s-es memória sem elég mindig, iszonyatos latencykkel dolgoznak a shader procik... És gyakorlatilag azért, hogy el tudd tüntetni ezeket, sokszor annyi threadot kell futtatnod, ahány tényleges proci van. Valószínûleg hasonló helyzet állna fenn egy sokszáz magos procinál is, intelnek sincsenek akkora trükkjei ami nvidiának ne lenne ;) .
Ekkor meg már fellép az a probléma, oké futtassunk raytracet, de ledöglik az egész, mert önmagában ahhoz, hogy elinduljon a render lefoglalunk 5-6 giga memet (vagy még többet... hint - stack... esetleg még ha ügyködünk valami stackless módszeren is, akkor is baromi nehezen oldható meg, hogy tetszõleges shader futtathasson a render - ez pedig egy produkciós renderelõnél elsõdleges dolog...)
Aztán pedig elõjön egy halom szinkronizációs probléma... Ez abban az esetben oldódhat meg, ha van elég memóriánk betölteni minden textúrát és minden adatot statikusan a membe, hogy mindenki onnan olvasgasson. Ami egy komolyabb jelenetnél 20-30 giga. (mivel elõre nem tudjuk megmondani mire lesz szükségünk, és ha több ezer szál között elkezdünk lockolni az ronda lesz...). És ilyenkor szépen várunk perceket mire végigpörgeti a vinyót a gép... (vagy rosszabb esetben a hálózatot, és minden lerohad)
Ezzel nem azt akarom mondani, hogy szar a sokmag, sõt jöjjön nyugodtan. De a szokásos tévhittel ellentétben, ez nem úgy megy, hogy x szálon futtassuk akkor a proginkat, még ha az csúcsszuperül is van megírva. Egy bizonyos mennyiség felett, már a cpuk is hasonlóan viselkednének mint a gpu-k, és ott az elõadások, tréningek nagy része arról szól, hogyan küzdjünk meg az architektúrával, és hogy varázsoljuk elõ a számítási kapacitás kemény 10%-át (nyilván sarkítok kicsit, de remélem érthetõ a példa)...
"Mindenhol, minden model textúrázva van."
Csak a merev és a rugalmas testeket. A folyadékok (ide sorolva a képlékeny anyagokat is) és a légnemû anyagok (ide sorolva a ködöt és a füstöt) valamint a láng élethû modellezésénél részecskemodellt használak. És a részecskéket nem textúrázzák.
Ezek után a "csak a hszekbõl itélve egyikõtöknek sincs fogalma arról" mondatod elég vicces. :)
Szerintem az megteszi gyakorlati problémának, hogy nincsenek millió magos gépek kéznél. Amíg meg eszköz nincs, addig a fejlesztés is nyögvenyelõs ugyebár. Egy nem létezõ architektúrára nem fognak algoritmusokat implementálni, meg arra optimalizálni.
Szerintem azt lehet kimondani bizonyosan, hogy a textúrázott felületû papírlapokból álló világ egy vicc, a valós, fizikai tulajdonságokkal részecskékbõl álló világhoz képest. Vagyis csak azért mert te vagy én vagy per pill mindenki megoldhatatlannak látszó korlátokba ütközik, azért nem kéne elvetni az ötletet. Mert ugye a levegõnél nehezebb tárgyak se tudnak repülni.