Intel: 8-10 év múlva jöhet az 1000 magos processzor
Oldal 1 / 2Következő →
Jelentkezz be a hozzászóláshoz.
#65
"ám az igazi kérdés, hogy lesz-e rá valós igény."
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...
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...
#64
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.
Hev fán, és tanulj még sok-sok dolgot ;) , hogy legközelebb ne azért idézzenek mert vicces, hanem mert okosat mondasz.
shaken, not stirred
#63
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.
Nagy igazság: "A diploma a lényeg, nem a tudás" Aki darabolva tölt fel torrentet az egy hülye köcsög :)
#62
"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.
É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.
Ĥ|Ψ>≈iħ∂|Ψ>/∂t (Az ember) \"Tudásra törpe és vakságra nagy.\" \"Ami igazán lényeges, az a szemnek láthatatlan.\" Használj TE is szinkrotronsugárzást!
#61
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.
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.
#60
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 ;)
shaken, not stirred
#59
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)...
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)...
shaken, not stirred
#58
Vártam hogy válaszolj, de...
"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. :)
"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. :)
Ĥ|Ψ>≈iħ∂|Ψ>/∂t (Az ember) \"Tudásra törpe és vakságra nagy.\" \"Ami igazán lényeges, az a szemnek láthatatlan.\" Használj TE is szinkrotronsugárzást!
#57
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.
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.
#56
Mond már el hogy a részecske alapú modellezésnél milyen nem technikai jellegû problémákra gondolsz?
Ĥ|Ψ>≈iħ∂|Ψ>/∂t (Az ember) \"Tudásra törpe és vakságra nagy.\" \"Ami igazán lényeges, az a szemnek láthatatlan.\" Használj TE is szinkrotronsugárzást!
#55
Az elmélet szép és jó, ebben nem mond hülyeséget, csak a hszekbõl itélve egyikõtöknek sincs fogalma arról, hogy egy ilyen rendszer milyen gyakorlati problémákba ütközne. És ehhez nem elég az 1000 max, vagy az xsok mag.
Ki lehet mondani, hogy voxel így úgy (effektíve az sem más, mint 3ds textúra...), de ahhoz, hogy bármi ilyesmit éles helyzetben lehessen használni, a technikai problémák megoldása, csak a jéghegy csúcsa... A csúnya dolgok alatta kezdõdnek...
Ki lehet mondani, hogy voxel így úgy (effektíve az sem más, mint 3ds textúra...), de ahhoz, hogy bármi ilyesmit éles helyzetben lehessen használni, a technikai problémák megoldása, csak a jéghegy csúcsa... A csúnya dolgok alatta kezdõdnek...
shaken, not stirred
#54
Pedig nem beszél hülyeséget ám a srác. A jelenlegi modellezés a tárgyak felületét modellezi, ezért kell a textúra. De ez a módszer sokkal gyengébb, mintha a tárgyak "részecskéi" lennének modellezve, most itt egy részecske nem feltétlen 1 atom, de mondjuk 0.1 mm3-as kis kocka. Mert ez esetben valóban azok jönnének be amit ír, hogy a fizikai és képi modell egyesülne, a tárgyaknak nem csak felületi tulajdonságai lehetnének - a textúra ennyit tud - de minden egyes kis töredékének valós fizikai tulajdonságai (szín, tömeg, kötési erõ a szomszédos elemekhez (szilárdság), fényvisszaverés, fényáteresztés, fénytörés, stb). És ezzel lehetne valós törést csinálni.
A gond csak az, hogy egy 10x10cm-es tárgy ha 0.1mm pontossággal dolgozunk akkor 1 millió részecskébõl állna, amit mind külön kellene számolni, és a fizika miatt azokat is számolni kéne valamennyire, amik nem látszanak. 10x10cm-es világ meg elég kicsi...
A gond csak az, hogy egy 10x10cm-es tárgy ha 0.1mm pontossággal dolgozunk akkor 1 millió részecskébõl állna, amit mind külön kellene számolni, és a fizika miatt azokat is számolni kéne valamennyire, amik nem látszanak. 10x10cm-es világ meg elég kicsi...
#53
Lol ezeket honnan vetted te? Textúra nélküli renderelés? Sehol sem használják ezt :) . Mindenhol, minden model textúrázva van.
Valós tükrözõdések? Egyedül a rendermannal dolgozó studiók vannak kissé hátrányban (mivel ott a raytrace baromi drága), de bárki más nincsenek arra kényszerülve (pl Sony).
Minden pixel külön magon? Van fogalmad a renderelés menetérõl? Mert innen nézve nincsen...
Valós tükrözõdések? Egyedül a rendermannal dolgozó studiók vannak kissé hátrányban (mivel ott a raytrace baromi drága), de bárki más nincsenek arra kényszerülve (pl Sony).
Minden pixel külön magon? Van fogalmad a renderelés menetérõl? Mert innen nézve nincsen...
shaken, not stirred
#52
2005-ös hír:
"Elindultunk a többmagúság felé, ami ugye elõször kettõ, majd négy, de úgy számítunk, hogy viszonylag hamar, a 2010-es évek elejére sokmagúvá alakul. A sokmagúság egyes szakértõk szerint lehet akár 128 is."
"Elindultunk a többmagúság felé, ami ugye elõször kettõ, majd négy, de úgy számítunk, hogy viszonylag hamar, a 2010-es évek elejére sokmagúvá alakul. A sokmagúság egyes szakértõk szerint lehet akár 128 is."
#51
"nembaj majd egymilliárdszor egymilliárd pixeles textúrája lesz a lágyan lengedezõ százmillió polygonos fûszálnak"
Ha olyan nagy szamitasi kapacitas van, akkor at lehet terni a raytracing-re es a fixikai modellre alapulo szimulaciora, tehat mar nem textura es polygon van hanem 3D-s tomor targyak es valos turkozodesek. Manapsag meg csak a filmtrukkok kisebbik reszet keszitik igy, de par ezer procival mar talan kis felbontasban meg lehet csinalni hasznalhato sebesseggel valos idoben, de tobb szazezer mag jobb lenne. Es az egeszben az a jo, hogy raytrace-nel ugyanaz a primitiv program fut minden magon, csak nagyon sok iteracio kell, ezert a legjobb ha minden pixelnek van sajat magja. Tehat egy jo programozo mar most ki tudna hasznalni egy 2 megacore-os gpu-t. (2 millio magost) Ha ezt megoldjak, akkor a kornyezet atalakithatova valik, tehat pl. eltorheto egy targy es nem egy elore kezzel gyartott szabvanyos 'torott' modell kerul a helyere, hanem pl. egy tukor egy nyilvesszo becsapodasi helye szerint reped meg es a fenyvisszavero tulajdonsagai is e szerint valtoznak meg. Vagy egymas melle rakott kristalypoharakkal el lehet terinteni az ablakon beszurodo feny utjat, ami a prizma hatas miatt szabalyosan bomlik komponenseire. Es az algoritmus mar kesz van hozza tobb millio magra is, csak nincs olyan hardver ami elbirja valos idoben. Szoval en nem aggodnek a miatt hogy nem fogjak ertelmes modon kihasznalni az akar 1 millioszor nagyobb kapacitast is.
Ha olyan nagy szamitasi kapacitas van, akkor at lehet terni a raytracing-re es a fixikai modellre alapulo szimulaciora, tehat mar nem textura es polygon van hanem 3D-s tomor targyak es valos turkozodesek. Manapsag meg csak a filmtrukkok kisebbik reszet keszitik igy, de par ezer procival mar talan kis felbontasban meg lehet csinalni hasznalhato sebesseggel valos idoben, de tobb szazezer mag jobb lenne. Es az egeszben az a jo, hogy raytrace-nel ugyanaz a primitiv program fut minden magon, csak nagyon sok iteracio kell, ezert a legjobb ha minden pixelnek van sajat magja. Tehat egy jo programozo mar most ki tudna hasznalni egy 2 megacore-os gpu-t. (2 millio magost) Ha ezt megoldjak, akkor a kornyezet atalakithatova valik, tehat pl. eltorheto egy targy es nem egy elore kezzel gyartott szabvanyos 'torott' modell kerul a helyere, hanem pl. egy tukor egy nyilvesszo becsapodasi helye szerint reped meg es a fenyvisszavero tulajdonsagai is e szerint valtoznak meg. Vagy egymas melle rakott kristalypoharakkal el lehet terinteni az ablakon beszurodo feny utjat, ami a prizma hatas miatt szabalyosan bomlik komponenseire. Es az algoritmus mar kesz van hozza tobb millio magra is, csak nincs olyan hardver ami elbirja valos idoben. Szoval en nem aggodnek a miatt hogy nem fogjak ertelmes modon kihasznalni az akar 1 millioszor nagyobb kapacitast is.
#50
....nembaj majd egymilliárdszor egymilliárd pixeles textúrája lesz a lágyan lengedezõ százmillió polygonos fûszálnak , amiböl persze francot nem veszel észre,
de jól fogja a gépet<#smile>
de jól fogja a gépet<#smile>
#49
Ez eddig is így volt. Eddig sem tudták tartani az iramot.
Mivel elõbb a hardvernek kell kijönnie hogy el tudjanak kezdeni programozni rá.
Mivel elõbb a hardvernek kell kijönnie hogy el tudjanak kezdeni programozni rá.
#48
Talán a gyártósorok tudják majd tartani az iramot, de vajon a programozók, és az alkalmazások fejlesztõi fogják tudni? Erõsen kétlem.
#47
Ja, és persze ugyanúgy rakhatsz Windowst és Linux-ot is a Mac-ekre, ebbõl kifolyólag. <#wink> Csak persze 4-5x annyiba kerül egy alap Mac, mint egy PC...
Valamint fordítva is megy, vagyis ugyanígy rakhatsz OsX-et PC-re.
Valamint fordítva is megy, vagyis ugyanígy rakhatsz OsX-et PC-re.
Ryzen 5 3600X | ASUS RX570 OC | MasterLiquid Lite 240 | DELL U2312HM In theory, there is no difference between theory and practice. But, in practice, there is. /Jan L. A. van de Snepscheut/
#46
Látom a nagy fanatizmusod közepette még nem jutott el a tudatodig, hogy a Mac-ekben Intel proci ketyeg már pár éve. :D Ekkora égést...
Ryzen 5 3600X | ASUS RX570 OC | MasterLiquid Lite 240 | DELL U2312HM In theory, there is no difference between theory and practice. But, in practice, there is. /Jan L. A. van de Snepscheut/
#44
ja csak mac 4szer annyiba kerül és nem is lehet rajta játszani ^^
________________ /\\/\\/\\/\\/\\/\\/\\/\\/\\/\\/\\/\\/\\/\\/\\/\\/\\ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
#43
Az erõs proci választás nem elég. Legalább ennyire fontos, hogy milyen az alaplap illetve milyen RAMot teszel mellé!
286/20Mhz; 1Mb; WD Paradise 512Kb; 40Mb; Mono VGA; ...Wolfeinsten 3D priman fut rajta 1.2 rendszerfloppyrol :>
#42
Az energia forrása és amiben tárolod az energiát sokszor elkülönül, és gyakran mindkettõ szennyezõ. Pl: elektromos autó, hõerõmû. De a belsõ égésû az mindenképpen szennyezni fog, az elektromosnál meg van arra esély, hogy ne hõerõmûben termeld meg hozzá az áramot, hanem mondjuk atomerõmûben. Azért az mégse lenne jó, ha autókba nukleáris reaktorokat raknának:-)
#41
Lehet félreérthetõ voltam - napi szinten 3 nyelvet használok, és ebbõl egyik se gépi kódra fordít. Egyszerûen azért, mert ezekkel lehet hatékonyan (értsd kevés idõ alatt) megoldani a problémákat, amiket meg kell oldanom. Persze a végeredmény ezeknél lesz leglassabb, de hát ezt fizetik meg...
Viszont én még valamilyen szinten képben vagyok - akkor is ha 10 éve foglalkoztam a témával behatóbban - azzal, hogy mi zajlik a processzorban, és nem úgy állok hozzá, hogy "felveszek még 100 threadet, és kipróbálom mi lesz a virtuális szerveren".
Viszont én még valamilyen szinten képben vagyok - akkor is ha 10 éve foglalkoztam a témával behatóbban - azzal, hogy mi zajlik a processzorban, és nem úgy állok hozzá, hogy "felveszek még 100 threadet, és kipróbálom mi lesz a virtuális szerveren".
#40
Mondott az intel ennél nagyobb baromságot is már.
#39
szar pécé akkorra a macekben már 10000 magos lesz és mind 8ghz-n fog futni, ugyanis az apple a leginnovatívebb fantasztikus cég.
apple az isten! csaak irigykedik a sok scsoro és azért! iMac 27\", MacBook, iPad3G, iPhone 4 nekem van ti csorok meg megelegszetek a recsegos gagyi mianyag gagyikal!!
![[HUN]FaTaL](https://media.sg.hu/forum/avatars/10557508481320070594.gif)
#38
"3. a szoftverek által megoldandó problémákra igaz, hogy elméletben jelentõs része nem párhuzamosítható, ám gyakorlatban szinte bármi, amit egy windows-ban láttok párhuzamosítható"
Persze, minden párhuzamosítható csak a szálak szinkronizálása miatt marhára nem biztos, hogy gyorsabb is lesz.
Persze, minden párhuzamosítható csak a szálak szinkronizálása miatt marhára nem biztos, hogy gyorsabb is lesz.
http://goo.gl/gd6Zi5
#37
"sziasztok!
nem tudom jó helyre teszem fel a kérdésem, de kerestem egy Intellel foglalkozó fórumot..."
Nem jó helyre tetted fel a kérdésed. Ez nem az a topic. A világ legnagyobb bunkóságba, beesni valahová, és a legelsõ utunkba kerülõ helyre beböfögni a problémánkat.
Van itt az SG-n kismillió+ gamer pc-vel foglalkozó topic, keress egyet a keresõvel, és oda írd be a kérdésed. Ez egy, az oldalon megjelent hírnek a topicja. Itten nem építünk gépet.
nem tudom jó helyre teszem fel a kérdésem, de kerestem egy Intellel foglalkozó fórumot..."
Nem jó helyre tetted fel a kérdésed. Ez nem az a topic. A világ legnagyobb bunkóságba, beesni valahová, és a legelsõ utunkba kerülõ helyre beböfögni a problémánkat.
Van itt az SG-n kismillió+ gamer pc-vel foglalkozó topic, keress egyet a keresõvel, és oda írd be a kérdésed. Ez egy, az oldalon megjelent hírnek a topicja. Itten nem építünk gépet.
A szenvedés az az, amitõl az ember jobbá válik. Csak túl kell élni.
#36
sziasztok!
nem tudom jó helyre teszem fel a kérdésem, de kerestem egy Intellel foglalkozó fórumot...
Na szóval. Már nagyon kicsi a processzorom az új játékokhoz, meg már öreg is és nem olyan fürge mint fénykorában...
Szeretnék venni egy újat, csak az a kérdés, hogy szerintetek melyik a jobb.
Egy pl: Intel Core i5 (2,0-2,4 GHz) (2 magos), vagy egy Intel Core i3 (2,4-3,0 Ghz) (4 magos)...
Szeretnék jó procit (gyors,erõs...) inkább játékra használom...
Max.:30.000-40.000 Ft-ot szeretnék szánni rá...
Kérlek segítsetek
Adhattok tippeket is, hogy milyen lenne jó...
Ja igen és: szerintetek mi számít jobban a magok száma, vagy a GHz?
nem tudom jó helyre teszem fel a kérdésem, de kerestem egy Intellel foglalkozó fórumot...
Na szóval. Már nagyon kicsi a processzorom az új játékokhoz, meg már öreg is és nem olyan fürge mint fénykorában...
Szeretnék venni egy újat, csak az a kérdés, hogy szerintetek melyik a jobb.
Egy pl: Intel Core i5 (2,0-2,4 GHz) (2 magos), vagy egy Intel Core i3 (2,4-3,0 Ghz) (4 magos)...
Szeretnék jó procit (gyors,erõs...) inkább játékra használom...
Max.:30.000-40.000 Ft-ot szeretnék szánni rá...
Kérlek segítsetek
Adhattok tippeket is, hogy milyen lenne jó...
Ja igen és: szerintetek mi számít jobban a magok száma, vagy a GHz?
#35
A hardver eléggé a játékok elõtt jár, így most sem kell évente gépet cserélni. 3 éves hardveren is jól fut a Crysis Warhead. Az más kérdés, hogy 2011-ben mondjuk a Crysis 2 is megmozdul-e rajta. De ettõl még tény marad, hogy 2007 óta nem kellet semmit venni, és minden játék futott. Így a rókabõr lehúzás kissé sántít. A természetes progresszió, hogy amint van valami új egybõl dobják is.
Kelly Sue Deconnick Heather Anthos Gail Simone Anita Sarkeesian Vita Ayala Sana Amanat Sam Maggs Kathleen Kennedy Leslye Headland Lauren Hissrich Lindsey Weber Alex Kurtzman JJ Abrams
#34
Ez a sûrített levegõs autó témába vág, de a levegõ sûrítéséhez használt energiát mibõl nyerik, már a levegõn kívül :) Ez a módszer se nem környezet barát, se nem ésszerû, mivel energiát pazarolnak a sûrítéshez aztán az így nyert nyomást mozgási energiává alakítva triciklit hajtanak!?! Vagy talán nagy nyomású lelõhelyeket találtak a föld minden pontján???
Ez egy teljesen értelmetlen interjun alapuló cikk mégértelmetlenebb átvétele volt. Szeneslapáttal kell agyonvágni azokat az embereket, akik ilyen semmitmondó foschsal lopják a napot.
Munkaállomás: C64 64K RAM 5,25\" floppy & Dataset Szerver: XT8086 640K RAM 10 MB MFM HDD 12\" Hercules Monitor DOS 1.0 Megy rajta a Crisys, mint az állat!
#32
Miért érzek az interpretált nyelvekkel/enterprise fejlesztõkkel szembeni ellenérzéseket a kommentjeidben, kolléga?
(Adott problémakörben az ellenérzés amúgy jogos :D)
(Adott problémakörben az ellenérzés amúgy jogos :D)
#31
Én a magam részérõl örülnék, ha kijönne akármilyen teljesítménnyel, mert én mindig jó tíz évvel késõbb tudok hozzájutni mindenhez. Szal, ha ez 2020ban köztudatra kerül, akkor végre tudok venni magamnak egy négymagost bagóért.
Már nekem is van galériám: wearwolfff.elementfx.com
#30
"-sûrített levegõvel mûködõ autó"
kb 5 eve van. franciak csinaltak, aztan megvette a TATA
http://www.mdi.lu/english/
egyebkent 60 eve is volt mar.
kb 5 eve van. franciak csinaltak, aztan megvette a TATA
http://www.mdi.lu/english/
egyebkent 60 eve is volt mar.
#29
nem az a kerdes h kell e 10 ev mulva 1000 magos proci.
Az a kerdes, h ha 2020ra 1000magos proci lesz, akkor mi lesz 2050ben, 2070ben vagy 2120ban (esetleg 2320ban?) ?
Az a kerdes, h ha 2020ra 1000magos proci lesz, akkor mi lesz 2050ben, 2070ben vagy 2120ban (esetleg 2320ban?) ?
#28
Hát a memóriáknak is kell fejlõdés hogy ki is lehessen használni, igazi gyorsulás a busz rendszer, memória, és a sok magos CPU-val együtt hozza el a változás szelét.
Majd mikor az alkalmazások is meg kívánjak az 1000 magot akkor használjuk majd õket és az elavult Quad Core CPU-s rendszereket kidobjuk, vagy a kávéfõzõbe, hûtõbe, TV-be, integráljuk. Vagy az óránkba :)
Majd mikor az alkalmazások is meg kívánjak az 1000 magot akkor használjuk majd õket és az elavult Quad Core CPU-s rendszereket kidobjuk, vagy a kávéfõzõbe, hûtõbe, TV-be, integráljuk. Vagy az óránkba :)
Nem minden feladat párhuzamosítható és nem csak a procik határozzák meg egy alkalmazás sebességét, így az 1000 proc nem 1000* gyorsabb... A raytrace viszont tipikusan ilyen cucc, és jó lenne már látni egy realtime raytrace game-t.
#26
Szobahõmérsékeleten szupravezetõ....? Linkeld már!
A történelem nagy tragédiája, hogy az Aurora helyett a Titanic süllyedt el. (Meg az, hogy a világot elárasztották a konteóhív?k...) i5-2400S 2.5GHz, HD7850 2GB, 8 GB RAM
#25
Ja, virtuális szerver, pfff. Errõl beszéltem.
#24
""De a CPU ezt nem fogja kiszopni az újából, hogy "a" változó ilyen, "b" meg olyan, és a jelenlegi gépikód nem tartalmaz olyan utasítást, amivel ezt meg lehetne neki súgni."
Az intelnek hala van. Csak a legtobb programozo nem tud rola, mert az elmult 10 evben kerultek be es ezert nem tanitjak magyar iskolakban. Attol meg letezik es az intelligensebb forditoprogramok berakjak ezeket a buta programozok helyett."
Megnéztem az intel instruction setjének doksiját, és én csak olyat találtam, amivel azt lehet szabályozni, hogy cachelje-e a memória területet vagy sem. Viszont ez nem elég, mivel a maghoz dedikált cache, meg a közös cache egészen más filozófia, másra jó. A jó az, ha 1x berakjuk a cache - lehetõleg minél gyorsabba - az adatot, ott piszok sok mûveletet végzünk rajta, míg elfajul odáig a helyzet, hogy vissza kelljen írni memóriába. A memória kommunikáció, a magok közötti kommunikáció - mind-mind fáj. Jelen architekturában ha sok mag használ egy területet akkor az nem lesz gyors. Márpedig globális változók vannak - egy számítási segédtáblát pl nem szokás lemásolni minden egyes szálhoz. Attól, hogy sok mag használ egy memória területet sokszor sokkal gyorsabb futást eredményezne, ha minden mag tudná cachelni ugyanazt a területet. Pl az elõre számolt segédtáblázatok tipikusan ilyenek: a program futásának elsõ idõszakában RW, és akkor legfeljebb közös cache-be kerülhet, utána meg RO, és lehet minden magban másolat róla, mivel úgyse fog módosulni. De ahhoz hogy ez mûködhessen a programnyelvek részérõl is kellene változás: nem elég az, hogy egy adatterület változó/konstans, hanem kellene egy olyan is, ami változóként indulhat, és utána konstans lesz (tömbre, bonyolultabb strukturákra, azok elemeire is). A procinak meg meg kellene tudni mondani azt, hogy ez egy olyan adatterület, ami RO, vagyis akár 1000 mag mind becachelheti, ha minden második mov errõl szól a kódban. Mert ha nem, akkor várhatja majd a 8-10 ciklusokat, mire hozzá bír férni.
"Egyebkent 1000-szer annyi mag az akkor jelent 1000x-es teljesitmenynovekedest, ha a memoria ki birja szolgalni es a szalak nem nyulkalnak bele allandoan egymas adatteruleteibe. Ha ez teljesul, akkor mukodik."
Na igen, csak sok itt a ha. A jelenlegi DDR3 memóriák 9-10ns körül vannak. Az EDO ram meg 10-15 éve 60-70ns volt. Persze tudom, a DDR akkor penge, ha sok adatot kell túrnia, de én nem láttam még olyan asm kódot, ahol minden csupa rep volna. Vagyis persze, gyorsabb a DDR3 mint egy 10ns EDO lenne de messze nem 40x, amit a max sávszélesség mutat. Hanem mondjuk 15-20x, jóindulattal. Vagyis a mai szupergyors DDR3 jobban fog egy 6 magos 2Ghz procit, mint egy EDO fogott 5x86-ot. Persze biztos tudnának gyorsabb memóriát is csinálni, gondolom csak passzióból várakozik 2x annyit ütemciklus százalékában egy proci jelenleg mint 10 éve.
Az intelnek hala van. Csak a legtobb programozo nem tud rola, mert az elmult 10 evben kerultek be es ezert nem tanitjak magyar iskolakban. Attol meg letezik es az intelligensebb forditoprogramok berakjak ezeket a buta programozok helyett."
Megnéztem az intel instruction setjének doksiját, és én csak olyat találtam, amivel azt lehet szabályozni, hogy cachelje-e a memória területet vagy sem. Viszont ez nem elég, mivel a maghoz dedikált cache, meg a közös cache egészen más filozófia, másra jó. A jó az, ha 1x berakjuk a cache - lehetõleg minél gyorsabba - az adatot, ott piszok sok mûveletet végzünk rajta, míg elfajul odáig a helyzet, hogy vissza kelljen írni memóriába. A memória kommunikáció, a magok közötti kommunikáció - mind-mind fáj. Jelen architekturában ha sok mag használ egy területet akkor az nem lesz gyors. Márpedig globális változók vannak - egy számítási segédtáblát pl nem szokás lemásolni minden egyes szálhoz. Attól, hogy sok mag használ egy memória területet sokszor sokkal gyorsabb futást eredményezne, ha minden mag tudná cachelni ugyanazt a területet. Pl az elõre számolt segédtáblázatok tipikusan ilyenek: a program futásának elsõ idõszakában RW, és akkor legfeljebb közös cache-be kerülhet, utána meg RO, és lehet minden magban másolat róla, mivel úgyse fog módosulni. De ahhoz hogy ez mûködhessen a programnyelvek részérõl is kellene változás: nem elég az, hogy egy adatterület változó/konstans, hanem kellene egy olyan is, ami változóként indulhat, és utána konstans lesz (tömbre, bonyolultabb strukturákra, azok elemeire is). A procinak meg meg kellene tudni mondani azt, hogy ez egy olyan adatterület, ami RO, vagyis akár 1000 mag mind becachelheti, ha minden második mov errõl szól a kódban. Mert ha nem, akkor várhatja majd a 8-10 ciklusokat, mire hozzá bír férni.
"Egyebkent 1000-szer annyi mag az akkor jelent 1000x-es teljesitmenynovekedest, ha a memoria ki birja szolgalni es a szalak nem nyulkalnak bele allandoan egymas adatteruleteibe. Ha ez teljesul, akkor mukodik."
Na igen, csak sok itt a ha. A jelenlegi DDR3 memóriák 9-10ns körül vannak. Az EDO ram meg 10-15 éve 60-70ns volt. Persze tudom, a DDR akkor penge, ha sok adatot kell túrnia, de én nem láttam még olyan asm kódot, ahol minden csupa rep volna. Vagyis persze, gyorsabb a DDR3 mint egy 10ns EDO lenne de messze nem 40x, amit a max sávszélesség mutat. Hanem mondjuk 15-20x, jóindulattal. Vagyis a mai szupergyors DDR3 jobban fog egy 6 magos 2Ghz procit, mint egy EDO fogott 5x86-ot. Persze biztos tudnának gyorsabb memóriát is csinálni, gondolom csak passzióból várakozik 2x annyit ütemciklus százalékában egy proci jelenleg mint 10 éve.
#23
Gondolom 1000 magos lesz a 2020ban bemutatkozó playstation 5, és erõben verni fogja a pcket egészen 2022ig ^^
A
#22
minek 1000mag mikor a játékot 1200magra optimizálják? ASD ekkora .... vagy azt hiszik,hogy 1szerre 80játékot fogunk futtatni?
________________ /\\/\\/\\/\\/\\/\\/\\/\\/\\/\\/\\/\\/\\/\\/\\/\\/\\ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
#21
A válasz a kérdésre, miszerint lesz-e rá szükség, abban rejlik, hogy mit gondoltunk a 40 MHz-es 386-osok idejében arról hogy lesz-e szükség 1-2-3 GHz-es gépekre. Ezek akkor szuperszámítógép-kategóriába estek, mégis itt vannak és használjuk õket.
10 év múlva talán holografikus kijelzõk lesznek, amelyben 3D-környezet fog megfelelni a munkaasztalnak (akkor már helyesen: munkaszobának). Az ezermagos hordozható Izészámítógépek nyilván akkor is ki fogják majd használni ezt a kapacitást, ahogy ma is kihasználják a 10 évvel ezelõtt még szuperszámítógépnek számító teljesítményeket.
10 év múlva talán holografikus kijelzõk lesznek, amelyben 3D-környezet fog megfelelni a munkaasztalnak (akkor már helyesen: munkaszobának). Az ezermagos hordozható Izészámítógépek nyilván akkor is ki fogják majd használni ezt a kapacitást, ahogy ma is kihasználják a 10 évvel ezelõtt még szuperszámítógépnek számító teljesítményeket.
#20
1. az intel azért csinál egyre több magot, mert máshogy nem lehet már egy processzor gyorsabb, tehát ha nem lehet hozzá fejleszteni, akkor is ez az út van, amit vágnak, és elméletileg ki lehet használni.
2. egy jó programozó úgy gondolkodik, ahogy tanult gondolkodni, nem úgy, ahogy ti elképzelitek.
3. a szoftverek által megoldandó problémákra igaz, hogy elméletben jelentõs része nem párhuzamosítható, ám gyakorlatban szinte bármi, amit egy windows-ban láttok párhuzamosítható
2. egy jó programozó úgy gondolkodik, ahogy tanult gondolkodni, nem úgy, ahogy ti elképzelitek.
3. a szoftverek által megoldandó problémákra igaz, hogy elméletben jelentõs része nem párhuzamosítható, ám gyakorlatban szinte bármi, amit egy windows-ban láttok párhuzamosítható
#19
nem egy embert ismerek aki 9 - 10 éves gépen is viszonylag jól elvan. Nem játszik csak netezget meg elolvas 1 - 2 doksit megnéz egy DVD -t vagy egy AVI filmet.
Az én gépem most 4 éves, de internetre teljesen jó. Még játszogatni sem olyan rossz pedig csak egy 7900 GTO van. Biztosan vannak olyan területek ahol kelleni fog ez a számítási kapacitás, de én inkább azt szeretném, ha jóval kisebb lenne a villanyszámlám és nem esne vissza teljesítmény.
Jó lenne ha az otthoni gépek masinák ebbe az irányba fejlõdnének.
Az én gépem most 4 éves, de internetre teljesen jó. Még játszogatni sem olyan rossz pedig csak egy 7900 GTO van. Biztosan vannak olyan területek ahol kelleni fog ez a számítási kapacitás, de én inkább azt szeretném, ha jóval kisebb lenne a villanyszámlám és nem esne vissza teljesítmény.
Jó lenne ha az otthoni gépek masinák ebbe az irányba fejlõdnének.
#18
a kutatóknak és a hadseregnek nagyon jól jön a sok mag, de keress rá pl. az fpga processzor alkalmazására (más proci de a lényeget megtalálod hogy mire jó az a sok mag)
HP+
#17
Félelmetes, hogy az amatõrök mekkora baromságokat tudnak leírni.
Szerinted viccbõl csinálunk minden kódot alapból párhuzamos futásra???
100 process 99-szer gyorsabban fut le, mint 1 process. Az overhead kb. 1%.
Kimaxoljuk a hardware-t kb. 80-90% load-ra, mert akkor fut a leggyorsabban.
A 100 process egyébként nem 1 gépen fut, hanem egy virtuális szerveren, aminek a HW-ét én nem is ismerem, csak kimérem, hogy mekkora terhelést bír.
Szerinted viccbõl csinálunk minden kódot alapból párhuzamos futásra???
100 process 99-szer gyorsabban fut le, mint 1 process. Az overhead kb. 1%.
Kimaxoljuk a hardware-t kb. 80-90% load-ra, mert akkor fut a leggyorsabban.
A 100 process egyébként nem 1 gépen fut, hanem egy virtuális szerveren, aminek a HW-ét én nem is ismerem, csak kimérem, hogy mekkora terhelést bír.
#16
Mi a fasznak ennyi mag? Nem lehet mindent párhuzamosítani, fõleg ennyi felé...
http://goo.gl/gd6Zi5
Oldal 1 / 2Következő →