Komolytalan#116
"No nézzük. Elõször is nem lesz külön egyedi konzol, mert ha ugyanaz fut mindenhol, akkor minek. Másodszor egy asztali gép vagy HTPC mindig (legalábbis még sokáig) jóval nagyobb teljesítményû lesz, mint akár egy laptop, nem beszélve a handheldekrõl."
Komolyabb teljesítmény, jobb minőség, gyengébb teljesítmény, gyengébb minőség. Ma is vannak olyan játékok, ahol az "amin még elmegy" és "amit ki bír használni" teljesítménye között több mint 10x különbség van. A lényeg, hogy az alapot ilyenre írják meg, ami nagyon tud skálázódni.
"Amíg nem fejlõdtek oda a PC-k, hogy Windows alatt is elfogadható minõségben futottak a dolgok (és ehhez képest DOS alatt sem volt már annyival jobb), addig a Wines game csak érdekesség volt. Szóval, megnézném, mikorra fejlõdnek odáig a dolgok, hogy egy akár PC-n (telefonokról és társaikról nem beszélve) futtatott virtuális környezetben ugyanolyan jól fusson egy game, mint egy aktuális spéci célhardveren..."
Ha DOS-os korszakot nem ismerted, akkor azt sem tudhatod, hogy már régesrég Win95 volt, mikor a DOS-os játékok még sokkal jobb minőségűek voltak, mint a W95-ös gámák. A két piac egy az egyben futott egymás között, a DOS-os gyorsabb/szebb volt. A DOS végzete csak és kizárólag az lett, hogy a VESA 3.0 szabványt, amely a 3D gyorsítás szabványosítására jött volna létre megfúrta az MS, és így kb annyi maradt az eredeti VESA 3.0 szabványból, hogy energy management, oszt jónapot. Az MS tudta, hogy ha DOS alatt is képesek lesznek szabványosan kezelni 3D kártyákat (ahogy ezt a 2D-nél lehetővé tette a VESA 1.2 majd a VESA 2.0), akkor a windowsos játékoknak meszeltek. Szóval alapvetően az, hogy a jövő egy hardwarefüggetlen (virtuális) platform, vagy célgépek, és minden procira újraírni/optimalizálni a jövő hetet is, az csakis akarat kérdése.
""Ha egy függvény hosszabb mint egy képernyõ, akkor valami el van rontva."
Hát nem tudom, te milyen témában nyomod, de pl. játékokban simán lehet sokkal hosszabb."
Vallási vitákba nem megyek bele inkább.
"Értettem, amit az VM-be pakolt funkciókról írtál, de nem hiszem, hogy ez teljeskörû lehet, másrészt sematikussá teszik a dolgokat. Egy adott setbõl kell majd dolgozni, nem lehet majd új megoldásokat kitalálni, mert azokat magadnak kell megírni, ami túl lassan futna..."
Ez így van. Azt azonban ne felejtsd el, hogy most is csak 1 féle sémából válogathatsz, van az a fránya x86/cell/akármi adott processzor, van pár utasítása, és azokból tudsz választani. Ha valamit kézzel kell megírnod (pl 1000 pontosságú lebegőpontos számok ábrázolásai, és műveletei), az bizony piszok lassan fog futni. Nem is ír ilyeneket épeszű ember.
"No ha nem is várható, hogy valami nagy központi gép futtassa nagyrészt a dolgokat, akkor végképp nem írnám le a spéci hardver elõnyét még jó ideig."
Ha a spéci gépen 10x annyiba fog kerülni a fejlesztés - mint ahogy 10x annyiba kerül jelenleg - akkor én nem írnám le azt a pár 100 milliárd USD megtakarítást sem, ami elérhető VM-ek alkalmazásával. Ugye asm-ben se sokan fejlesztenek ma játékot, holott pl a párhuzamosság optimalizációja máshol nem nagyon oldható meg. Még P1-en foglalkoztam ilyennel (pair nevű programmal), hogy adott asm kód leggyorsabban fusson, úgy cserélni az utasításokat, hogy az U és a V cső is egyszerre működjön. Mit ne mondjak, el lehetett tökölni 1 100 soros asm rutinon fél napot mire a kezdeti 25% kihasználtságról a 2. cső felment 80%-ra. Ez ugye 30-40% gyorsulás a kódon így első blikkre. Használja ma valaki ezt a módszert? Fenéket.