A 22nm-es variáns felfogható egy next gen konzolnak cakkompakk?
120 fps or GTFO :D

A 22nm-es variáns felfogható egy next gen konzolnak cakkompakk?
120 fps or GTFO :D
Ezen hogy menne a krájzisz?
>> http://tinyurl.hu/i3i6/ << Referenciám| HTC Surround 7 16GB WP 7.5
32 darab in-order x86 mag? Ez valami vicc? Hatalmas pofára esés lesz ebből az egészből.
"A rendszer 16 utas, 512 bites vektoros egység úgymond etetésére vállalkozott, miközben a 8 MB-os gyorsítótár nincs bankokra osztva." Ezt nem lehet átfogalmazni? Ötszöri újraolvasásra sem vagy teljesen biztos benne, hogy azt értem, amit akartatok írni. (Milyen rendszer, a 32 x86 mag? Mi 16 utas, a rendszer vagy a vektoros egység? A gyorsítótár az kié?)
Nem vicc, csak véletlenül 32-esével vágták csak szét az Atomnak szánt wafert ![;]](/dl/s/v1.gif)
\\\\\\\\\\\\\\\\ ALLEZ AMÉLIE!!! - www.ameliemauresmo.hu //////////////// Videókazetták digitalizálása Xvid és DVD-Video formátumba olcsón, jó minőségben! Ha érdekel dobj privit!
Jól hangzik
, de majd meglátjuk mire lesz képes....az árára inkább gondolni sem merek... 
ott a kisértet a ganéná.... by: Bendegúz
Nem.

Azért az árát így látatlanba biztosan elfogadnám 

Nem vagyok mérnök, de csak láthat benne az Intel némi fantáziát, ha a Larrabee bukása ellenére továbbviszi a projectet.
Ez maga lenne a Dzsízisz Krájzisz. 
"Egylábú embert találtak egy Belga réten, a Belga állítólag arra hivatkozott, hogy neki sose kellett láb!"

alul a képen Knights Ferry van, a címben meg Fierry. valamelyik nem jó.
Mások is látnak benne fantáziát. De LordX nem.
"mely az előzeteseknek megfelelően nem jelenik meg kereskedelmi forgalomban"
Akkor nem értem a felhajtást... egyébként elsőre elméletben meggyőző, de tényleg ki kellene próbálni - lásd Fermi, Larrabe. De maga a MIC elgondolás tetszik.
[ Szerkesztve ]
PH semleges
Javítva köszi. 
A semmi az nem nincs, hanem van. Ha a semmi van, akkor nincs semmi, de ha nincs semmi, akkor valami van, de az nem semmi.
Ez akkor a 'villantunk egyet az x86-os procikból összetákolt cuccunkkal' rovat?
Ha az intelen múlna, akkor mindenben x86-os processzor lenne.
"I see the diamonds, but you only see the rock"
Persze.
Ha pedig az nV-n, akkor mindenben CUDA proci...
Mindenki azt terjeszti, amije van.
Aquatuning.de-ről rendelés hamarosan! Akit érdekel -> PÜ nekem! (Elhalasztva 1 hónappal!) 06.10-ig.
Az alapötlet (annyira) nem hülyeség (bár már kifejtettem, hogy az x86 nem erre való), de a megvalósítás jelen állapotban olyan gyenge, mint a harmat.
Valóban többször olvastam már tőled, hogy az x86 nem erre való. De az is igaz, hogy egyszer sem indokoltad, hogy miért is...
Egyébként egy 1,2 TFLOPS-ot tudó x86-os kütyü nem olyan rossz.
Az Intel 980X elméleti maximuma 0,1.

Szerintem ez sem lesz befejezve 
Sose vitatkozz idiótákkal. Lesüllyedsz az ő szintjükre, és végül úgy is legyőznek a rutinjukkal.

Véletlen automatikusan "hulladék generációt" olvastam 
A tudomány tegnap délutáni állása/tyúkhúr elmélet szerint igazán művelt csak az lehet, akin végigment egy nehézeke, tehát: Ha nem rendelkezel az említett képesítéssel: NE OKOSKODJ!:)
Nem, nem igaz, kifejtettem.
Az x86 utasításkészlet alapvetően egy skalár utasításkészlet, ami kapott pár vektor-kiegészítést (SSEx). Az 1980-as években tervezték. Skalár problémák megoldására. És foltozgatták, hogy aktuálisabb problémákra többé-kevésbé használható legyen. Soha, de soha nem lesz olyan hatékony vektorműveletekre, mint egy effektíve erre tervezett utasításkészlettel rendelkező processzor (pl. egy GPU). Kis körültekintéssel egy GPU elméleti számítási teljesítményének 70-80%-át könnyedén ki lehet használni - egy HT-s P4 esetében ez a szám nem nagyobb mint 30%, ha hülyére optimalizálod a kódot, de azóta fejlődött a tudomány, legyen 40. Még mindig 2x akkora TFLOPS-ot kell papíron kitolnia magából, hogy ugyanott legyen egy nem-benchmark programban, mint egy Fermi. De mivel inorder, kötve hiszem, hogy hozza ezt a szintet.
De ne legyen igazam.
Az is problémát jelenthet, hogy GPU-kra inkább feladat-párhuzamosan programoznak. A Larrabee koncepciója inkább az adatpárhuzamosságra épül. 30+ magnál annyi szál van, hogy a CPU-nál alkalmazott programozási módszerekkel baromira nehéz felügyelni a chipben zajló folyamatokat. Ezért is alkalmaznak a fejlesztők a GPU programozására más módszereket.
A semmi az nem nincs, hanem van. Ha a semmi van, akkor nincs semmi, de ha nincs semmi, akkor valami van, de az nem semmi.
Ugyan mitől hatékonyabb egy kód GPU-n, mint egy CPU-n? 
Miért hatékonyabb a HW-es tesszelálás, mint a szoftveresen emulált? Hisz maga a futtatott kód egyforma.
[ Szerkesztve ]
Aquatuning.de-ről rendelés hamarosan! Akit érdekel -> PÜ nekem! (Elhalasztva 1 hónappal!) 06.10-ig.
Hogy ez miért is nem jó példa:
- a HW-tesszelálás nagyságrendekkel több erőforrást használ
- emulációnál rengeteg adatmozgatásról is gondoskodnia kell a kódnak

Klasszikus Abu-cikk, ha a felét értem sokat mondok...
(Persze a szöveg része tiszta, csak a számok kevésbé, no offense)
és ez a fórum hozzászólásokra is igaz, tanulnom kell még, na 
[ Szerkesztve ]
Si tacuisses, philosophus mansisses.

Amikor megláttam azt az Intel VGA-t, akkor olyan érzés fogott el, amilyet még ember is ritkán vált ki belőlem. Olyan furcsa és ijesztő is egy kicsit, de mégis kíváncsi vagyok rá, hogy mi az 

Sajna régen tanultam ezekről, de valamicske tudás maradt. Jelen esetben az inorder, amit a cikk is emleget egy baromi rossz ötlet. Ilyen arhitektúrára baromi nehéz jó fordítót írni. LordX elmondta miért nem életképes egy x86-os mag grafikus megjelnítésre. Egy példát én is adhatok. Ráncosabb homlokú kollegák emlékezhetnek a Delta Foce c. FPS-re. Az egy 3D gyorsítást mellőző program volt, az akkori x86-os arhitektúrák nagy részét egyszerűen berohasztotta. Tudom nem a legjobb példa, de talán innen is látszik kicsit a CPU-GPU képességeinek különbsége.
Másrészről, a FERMI egy marha jó tehnológia, de nem ezért a felárért. Irtózatos nyers ereje van általános számításokra. De sajna már látsznak a jelek a chip butítására, mint pl.: GF108.
S ha már csak a feldolgozó szálak számával számolunk. Látom keresel AMD X6-ost. Az a CPU 6 feldolgozószálon képes műveletet végrehajtani, a most fellelhető nem profi és nem alkalmazás célú szoftverek, azaz a játékok, nem képesek kihasználni. Vegyünk egy AMD GPU-t, csak a márka kedvéért, egy 4670 es kártyánál (csak tippelek bocsi) van 32 feldolgozószál. Ha mondjuk egy nyers videófájlt kell átdolgozni akkor a 32 feldolgozószállal dolgozó GPU-ra írt kódolók gyorsak és hatékonyak is. Ellenben a 6 szállal dolgozó CPU-nál.
De mint írtam a hsz. elején sajna régen tanultam ezeket. Kéretik szólni ha valamit rosszul írtam.
István
Kockák előre!!! :D
Nem a kód hatékonyabb, hanem az erőforrások kihasználása. Egy CPU az általános célú, mindenre van egy-egy végrehajtó egysége (vagy több mikroutasításra bontják, és több lépésben oldják meg), sőt, legacy cuccokat is kell támogatni valamivel, ami kb. soha nem fog csinálni semmit, de a "papíron FLOPS"-ba beleszámít.. Ha épp egy speciális feladatot hajtasz végre, akkor a többi részegység nem csinál semmit. Egy szuperskalár processzorban nagyon nem triviális (konkrétan NP teljes) az, hogy milyen sorrendben kell az utasításokat kiadni, hogy várható értékben minél nagyobb legyen a részegységek kihasználása, a legdurvább fordítók sem végeznek tökéletes munkát, sokszor kihagynak olyan lehetőségeket, amit egy járatos ASM programozó azonnal meglát.
Egy GPU egy végrehajtóegysége ellenben olyan mint egy faék, pl. az Evergreen családban egy processzorban 5 ALU van, sőt az nVidia G200 processzora skalár, azaz EGY darab ALU. Előbbinél a kihasználtság csak annak a kérdése, hogy hány darab független utasításod van egyszerre, utóbbinál meg mindig 100%, csak tudd elég adattal etetni.
Mátrixszorzó algoritmus (és eddigi tapasztalataim alapján jóóóó sok mátrixszorzást végeznek "tudományos célra") van CUDÁra ami a GPU teljesítményének 95%-án működik, CPU-n nem láttam még olyat, ami a elméleti teljesítmény felét tudná (én ne dobná magát hanyatt, ha a mátrix nagyobb, mint a L2 cache). Ellenben egy feltételes ugrásokkal teletűzdelt kód kb. rémálom egy GPU-nak, addig egy CPU >80% pontossággal bebecsüli melyik úton kell továbbhaladni és már akkor elkezdi végrehajtani, amikor még ki se derült az eredmény.
TL: DR: Az x86 másra való.
Értem én az Intel marketingjét, hogy mivel megy rajta x86, az eddigi kód futtatható (max újra kell fordítani, hogy legyen AVX is a kódban, lásd a mellékelt fordítót), de hogy a régi x86 kód nem fog gyökeres módosítások nélkül 32 vagy 640 vagy akármennyi ami több mint 2 szálon futni, az hót ziher. Akkor meg már tök mindegy, hogy x86, vagy nem.
[ Szerkesztve ]

lájkolom
"A 22 nm-es gyártástechnológiát használó MIC architektúra több mint 50 processzormagot alkalmaz, ami elméletben borzalmas nyers erőt jelent."
Vagyis borzalmasan fog teljesíteni? 
jancsiga
Hát ... nem így értettem, de hogy ne érje szó a ház elejét átírtam. ![;]](/dl/s/v1.gif)
A semmi az nem nincs, hanem van. Ha a semmi van, akkor nincs semmi, de ha nincs semmi, akkor valami van, de az nem semmi.

sli-be megy a cucc?, mert ha beteszek 8 fermit egy alaplapra leszedi az egrol a csillagokat 
Ha valaki linkelne Knights Ferry eredményeket, azt megköszönném. 
Az előbb egy ilyet találtam: High Performance and Scalable GPU Radix Sorting
quad core i7 -> 240M 32-bit key/s
Knights Ferry -> 560M 32-bit key/s
GTX480 -> 1005M 32-bit key/s

Knights Ferry-Fermi összehasonlítás: Compilers and More: Knights Ferry Versus Fermi
[ Szerkesztve ]