36
-
dez #36 "A larrabee-k eseten annyi memoria buszt tesznek ra amennyik akarnak. A jelenlegi nvidia chipeken is 2-8 fuggetlen csatorna van. Igy akar mindegyik cpu tomb kaphat egy vezerlot."
Ezt a Cellel is meg lehet tenni. Annál is inkább, mert XDR vezérlője van, amihez sokkal kevesebb vezeték kell. Most is többcsatornás.
"A forditoprogramokat erre talaltak ki. A forditot megirja egy ember, aztan hasznalja tobb szazezer."
Na ne mondd, tényleg? Akkor mondanál egy olyan fordítót, ami automatikussá teszi a cache-manipuláció optimizálást? Csak mert én nem tudok ilyet. Mellesleg a Larrabee-ban a megszokottnál spécibb utasítások vannak erre.
"A masik, hogy ha nem akar valaki jo kodot irni, akkor egyszeruen kihagyja az optimalizalast. Lehet, hogy nem lesz tul gyors a program, de elkeszul idore. Ez utobbi fontosabb a kiadok szamara, mint az optimalizalas."
Az is fontos, hogy ne legyen használhatatlan a kód, szóval elkerülhetetlen az optimizálás. Pontosabban, eleve ezt figyelembe véve kell megírni a kódot. Más szóval, a hagyományos kódok bár elfutnak rajta, de igencsak lassacskán.
"Nem igaz, ez csak az adatok lokalitasatol fugg."
De igaz, egy adott szóhoz tartozó cache-line mindig hosszabb, mint maga a szó, hiszen különféle kiegészítő adatokat is tárolni kell.
"Pont az ami a cell-nel kotelezo, az x86-osok eseten pedig csak a teljesitmenyt novelo opcionalis megoldas."
Mi kötelező? Nem tudom, mire gondolsz.
"Ezert van a jelenlegi rendszereknel 1 orajeles cache es ezert van a larrabee-ben smt, hogy amig az egyik szal var az adatra, addig a masik szal dolgozik."
Igen, a HW SMT kompenzálja az in-order rendszert. Azonban, ennek megvan az ára is: párhuzamosan végrehajtható szálanként külön regiszterbank, ami igencsak megnöveli a magméretet. A Larrabee-nél ráadásul 4 párhuzamos szál van, és gondolom 512 bitesek a regiszterek is.
"Es mindezt teljesen automatikusan, a programozo szamara gondot nem jelento modon teszi."
A gond ott van, hogy az amúgy sem nagy cache-t is 4-felé kell osztani.
"(tehat akar arra is kepes, hogy egy utasitast az egyik szalbol, egyet a masik szalbol hajtson vegre, ezt cell-el nem lehet megoldani, mert csak szoftveres szal valtas van az spe-kben, ami jopar utasitast igenyel)"
Nem baj, mert nincs is rá szükség. A double-bufferes feldolgozás viszont minden további nélkül megoldható, elhanyagolható overheaddel.
"A larrabee-ben pont ezert van smt, hogy ez elony legyen ne hatrany"
Ezt az SMT nem igazán befolyásolja, mivel az a 16 db művelet párhuzamosan hajtódik végre.
"tovabba az osszes gpu-ban is ezert van 16-os parhuzamositas az spu-k 2-es megoldasa helyett."
Nem, egyátalán nem ezért. Hanem azért, mert túl sok helyet igényelne, ha több ütemező és branch unit lenne. Azaz ez egy kompromisszum.
Az SPU-k 4db SP FP vektorműveletet tudnak párhuzamosan.
"Kar, hogy ehhez ujra kell irni, de legalabb ujraforditani a szoftvert. Ezzel szemben az x86-os kod annyi szalat hasznal amennyit akar, aztan ha van eleg mag, akkor mindegyik kap sajatot, ha nincs akkor futnak kevesebben, multitask-ban. Igy a lassabb gepeken is fut a kod, de ha veszunk egy ujat, akkor magatol gyorsabb lesz minden regi program."
Lásd amit fent írtam. Megfelelő tervezés és optimizálás nélkül itt is lassú lenne a kód. -
kvp #35 "- Az egy dolog, hogy a közvetlen memóriacímzés által egy átlag C kód fordítható és futtatható rajta, de ha ezt tesszük, nagyon gyorsan beleütközünk a memória-sávszélesség korlátaiba. És akkor ugyanúgy neki kell állni optimalizálni, a minimumra csökkenteni a memóriahozzáférések számát."
A larrabee-k eseten annyi memoria buszt tesznek ra amennyik akarnak. A jelenlegi nvidia chipeken is 2-8 fuggetlen csatorna van. Igy akar mindegyik cpu tomb kaphat egy vezerlot.
"De mivel itt cache van, tele kell tenni a kódot prefetchekkel, flushokkkal, stb. stb. Akkor már sokkal átláthatóbb, ha van minden maghoz egy belső, címezhető ramunk..."
A forditoprogramokat erre talaltak ki. A forditot megirja egy ember, aztan hasznalja tobb szazezer. A masik, hogy ha nem akar valaki jo kodot irni, akkor egyszeruen kihagyja az optimalizalast. Lehet, hogy nem lesz tul gyors a program, de elkeszul idore. Ez utobbi fontosabb a kiadok szamara, mint az optimalizalas.
"- Cache memóriából 256 KB sokkal kevesebb hasznos adatot v. kódot tud tárolni (mert egy adat-szót tartalmazó és azonosító cache-line sok szó önmagában), mint 256 KB lokális RAM."
Nem igaz, ez csak az adatok lokalitasatol fugg. Pont az ami a cell-nel kotelezo, az x86-osok eseten pedig csak a teljesitmenyt novelo opcionalis megoldas.
"- Mindkettő in-orderes, de a Larrabee-nél ez jóval többször jelenthet várakozást, mivel az SPU-k alapvetően a cache-sebességű lokális memóriába dolgoznak, ahol ez nem számít."
Ezert van a jelenlegi rendszereknel 1 orajeles cache es ezert van a larrabee-ben smt, hogy amig az egyik szal var az adatra, addig a masik szal dolgozik. Es mindezt teljesen automatikusan, a programozo szamara gondot nem jelento modon teszi. (tehat akar arra is kepes, hogy egy utasitast az egyik szalbol, egyet a masik szalbol hajtson vegre, ezt cell-el nem lehet megoldani, mert csak szoftveres szal valtas van az spe-kben, ami jopar utasitast igenyel)
"- Nem hátrány, hogy az SPU-kban 128 bites vektoregység van: 1. kevesebb párhuzamos műveletre esik 1-1 ugrási egység, így kevesebbet is fog vissza, ha ugorni kell, 2. így kisebb is a mag."
A larrabee-ben pont ezert van smt, hogy ez elony legyen ne hatrany, tovabba az osszes gpu-ban is ezert van 16-os parhuzamositas az spu-k 2-es megoldasa helyett.
"- Az SPU-k kisebbek: több fér el. Azonos csíkszélességen mindig több SPU fog elférni."
Kar, hogy ehhez ujra kell irni, de legalabb ujraforditani a szoftvert. Ezzel szemben az x86-os kod annyi szalat hasznal amennyit akar, aztan ha van eleg mag, akkor mindegyik kap sajatot, ha nincs akkor futnak kevesebben, multitask-ban. Igy a lassabb gepeken is fut a kod, de ha veszunk egy ujat, akkor magatol gyorsabb lesz minden regi program. -
dez #34 Csak éppen sokkal lassabban. -
dez #33 Elég alacsony színvonalú "elemzés". Ami nem jutott el az agyáig (bár tiédig sem, mert ugye hiába is írtam már le ezeket neked, de most hátha):
- Az egy dolog, hogy a közvetlen memóriacímzés által egy átlag C kód fordítható és futtatható rajta, de ha ezt tesszük, nagyon gyorsan beleütközünk a memória-sávszélesség korlátaiba. És akkor ugyanúgy neki kell állni optimalizálni, a minimumra csökkenteni a memóriahozzáférések számát. De mivel itt cache van, tele kell tenni a kódot prefetchekkel, flushokkkal, stb. stb. Akkor már sokkal átláthatóbb, ha van minden maghoz egy belső, címezhető ramunk...
- Cache memóriából 256 KB sokkal kevesebb hasznos adatot v. kódot tud tárolni (mert egy adat-szót tartalmazó és azonosító cache-line sok szó önmagában), mint 256 KB lokális RAM.
- Mindkettő in-orderes, de a Larrabee-nél ez jóval többször jelenthet várakozást, mivel az SPU-k alapvetően a cache-sebességű lokális memóriába dolgoznak, ahol ez nem számít.
- Nem hátrány, hogy az SPU-kban 128 bites vektoregység van: 1. kevesebb párhuzamos műveletre esik 1-1 ugrási egység, így kevesebbet is fog vissza, ha ugorni kell, 2. így kisebb is a mag.
- Az SPU-k kisebbek: több fér el. Azonos csíkszélességen mindig több SPU fog elférni.
Persze lehetnek feladatok, ahol az egyik, és olyanok, ahol a másik alkalmazása a hatékonyabb.
Egyébként a GPU-k blokkjait ne nevezd magoknak, mert a processzor mag fogalmába jóval többminden tartozik, mint ami 1-1 ilyen blokkban van. Azok csak "egyszerű" ALU-k blokkjai. Az ütemező, és sokminden más külön funkcionális egységben van. -
#32
RAYTRACING ALAPOK
-
#31
2x-es pontossággal tudnak. -
tomcsa4 #30 A mai GPU-k egyszeres pontossággal tudnak számolni (lebegőpontos számítás, 32 bit). Gondolom a Larrabee ezen javít majd. De várok még több infót is. Remélem csacsognak még valamit. -
kvp #29 Hozzatennem, hogy a jelenlegi nvidia gpu-k is 16 magonkent vannak 1 valodi gpu maghoz csatolva, tehat 16 mag kap 1 elagazasi egyseget. Ez megfelel egy altalanos cpu-nak egy 16 magos simd vektor egyseggel. Jelenleg az nvidia-nal 256 magos gpu-kat gyartanak, ami kb. 16 darab azonos orajelu larabee magnak felel meg. Az egyetlen gond a ringbus-bol adodhat, ez mar a cell-eknek sem hasznalt, viszont mivel a larrabee-nel x86-okrol van szo, ezt barmikor ki lehet cserelni crossbar-ra a szofverek modositasa nelkul.
Egy erdekes osszehasonlitas, a korabban belinkelt cikkbol:
"It’s very tempting to compare Larrabee and Cell. Both use a multitude of single cores (in-order), putting the accent on vector calculation, 256 KB of dedicated memory per core, a ring bus to connect it all, etc. The similarities are numerous at first glance. Yet, the differences are also substantial: The Cell is first and foremost a CPU. Although it’s oriented toward streaming-type applications, it is not intended for rendering calculation, and consequently, there are no texture units.
Zoom
Another major difference is in the way memory is managed. On the Cell, except for the PPE, which is the only part of the processor that has a global vision of the memory space, all the SPU's memory accesses are limited to 256 KB of local store memory. So, access to main memory must be done explicitly via direct memory access (DMA) operations. Conversely, as we saw earlier, all of Larrabee’s cores have access to the entire memory space, via a cache memory whose management is transparent to the programmer, even if the programmer does have a certain form of control. Intel’s choice greatly simplifies programming and avoids having to include a more generalist core like the PPE. This heterogeneous system is one of the Cell’s handicaps, since it complicates things for the programmer. In addition to explicit management of memory, he or she must also build two executables using two different sets of instructions, which means using two different compilers.
So Larrabee’s cores are much more complete than the Cell’s SPUs, since they support all the x86 instructions. However, their performance is also better in terms vector calculation. That’s because they operate on 512-bit vectors instead of the SPUs’ 128 bits, and while the Cell should have the advantage in clock frequency (Larrabee is expected to clock at 2 to 2.5 GHz, but that’s still very hypothetical), that doesn’t compensate for such a big disadvantage.
...
What’s more, despite the flexibility GPUs have gained, their functionalities remain heavily oriented towards raw calculation. For example, there’s no question of performing I/O operations from a GPU. Conversely, Larrabee is totally capable of that, meaning that Larrabee can directly perform printf or file-handling operations. It’s also possible to use recursive and virtual functions, which is impossible with a GPU." -
#28
Mennyi lesz a fogyasztása? Csak nehogy az "erőműhöz" erőmű kelljen! -
JTBM #27 Ha valakit érdekel infó:
Toms Larrabee Review
Egyenlőre még kísérleti fázisban van, nem lehet tudni, hány mGPU-ból is áll majd össze.
Valószínűleg tényleg a Raytracing-et fogja célozni.
Amint kijött és működik, valószínűleg el kezdenek majd dolgozni az optimalizációján, megnézik, hogy az x86-os magok valójában mit használnak és a nem használt részeket kidobják belőlül.
Szóval a Larrabee II szvsz. sokkal gyorsabb lesz majd az elsőnél. -
2097 #26 Én is azt olvastam róla, hogy igazából a Raytracing és a Voxel lesz amire igazából ez jó. Valamelyik Intel nyilatkozatban is azt mondták, hogy ők is úgy 2012-14 közé teszik a technológia beérését.
Az Intel integrált grafikus chipek irodai környezetben tökéletesen megállják a helyüket, otthon internetezni és minimális multimédiára is nagyon jó, de ahogy már előttem írták is többen X4500HD HD-ra tényleg nem igazán alkalmas, mert ugyan megbirkózik vele, de nem igazán szép. -
tomcsa4 #25 45 nm-es lesz. Ez középkategóriának készül, legalábbis akkor azt állították. Gondolom majd 32 nm-re állnak a következőnél (lesz idő, mert míg bevezetik az első szériát, meg mutogatnak rajta ezt-azt meg stb, telik az idő, jön a 32 nm, ami már idén megkezdi pályafutását). -
tomcsa4 #24 Ezt írták tavaly:
A Larrabee alapegységei olyan magok, melyek az x86 utasításkészlet egy részhalmazára alapoznak, és ciklusonként két kétszeres pontosságú skalárműveletet, illetve 8–16 SSE műveletet képesek végrehajtani, valamint folyamatvezérlési feladatokat is ellátnak. Mindegyik rendelkezik egy gyors hozzáférésű, adat- és utasításcache-re osztott elsőszintű gyorsítótárral, az egymás közötti kommunikációra pedig a megosztott másodszintű gyorsítótárat használják. Ennek mérete a magok számától függ, magonként 256 kB adódik hozzá. A chipbe 16–24 mag kerül, melyek a jelenlegi x86-os processzoroktól eltérően in-order rendszerűek, vagyis nem rendezhetik át feldolgozás közben az utasítások sorrendjét.
Itt még lehet olvasgatni. -
tomcsa4 #23 whoájem17: szerinted valakit érdekelsz még? Mert engem nem igazán.
X4500HD nem rossz, de nem is jó. HD képességei nem rúgnak labdába a konkurenciával. Az a mázlija, hogy olyan áron, amin adják nincs ellenfele. (Asztaliban kb a 2400/2600Pronak felel meg.) -
Abu85 #22 Ez a HD lejátszás így leírva rendben van, de képminőségben messze elmarad az integrált GeForce és Radeon mögött.
Az, hogy az Intel adja el a legtöbb integrált grafkarit ... hát finoman szólva semmi jót nem jelent, mert meglátszik, hogy az emberek az orruknál fogva vezethetőek. Egyszerűen nem néznek utána mit vesznek. Figyelmen kívül hagyják, hogy hasonló áron mérföldekkel jobb is vásárolható. -
vasziszdasz #21 google is your friend -
vasziszdasz #20 Még mindig az intel gyártja a legtöbb grafikus csipet. -
vasziszdasz #19 szánalmas X4500HD
Aki ilyet ír, annak fingja nincs mire való az integrált videokártya. Ez a cucc pont elég arra hogy a Vista Aero Glass felületét elbírja, meg HD filmeket hardveresen dekódoljon, több nem is kell. Ami viszont kell, az a minimális fogyasztás. 8-10 órát csak ilyennel bír elmenni egy noti, nem a 9800 GTX SLI kazánokkal. Azok mellé teljesen felesleges az aksi, csak percekben mérhető az üzemidő. -
szily3 #18 Mijaza RAYTRACING ??? :D Pls. magyaráz:D -
calibra83 #17 Az intel meg a grafikus chip gyártás?! Na az ami nem lesz:) -
#16
nemtom, de elég sok mag lesz benne. meg egy CPU-GPU összehasonlítás azért nem nyerő, mert a GPU cél-csip. viszont ha x86 kompatiblis lesz, akkor pl simán lehet, hogy futasson bármiféle szoftvert GPGPU driverek meg környezetek nélkül. pl ha kell egy mag grafikázik (sima asztal) a másik x db meg winrar konvertáljon. meg én úgytom h intel ezt kifejezetten grafikára szánja, nem mint egy szánalmas X4500HD-t.
amúgy carmack is már raytracingre gyúr, és szerinte a larrabbee kiváló ugódeszka lesz a raytracing világába való átvezetéshez. -
who am I 7 #15 belegondoltam tómcsaaa 
a balzsebemben minimum 10 db "CPU 4 magos CPU " el fér!Nem semmi milyen kis helyen elfér! 
-
tomcsa4 #14 Esetleg Voxel? Mert 2015 előtt bizony leeht az kezd el terjedni (mivel abban van leehtőség). -
vasziszdasz #13 Nem ugyanaz a kategória. Az intel más irányba akarja elvinni a grafikát mint amit most nyomatnak az nvidia-ati végek. Ez inkább a raytracing megoldásokhoz lesz nyerő, arra meg a hagyományos cuccok nem jók. -
vasziszdasz #12 Jelenleg. -
Inquisitor #11 Csak nehogy olyan über jó legyen a szoftver oldali támogatása, mint az i720/740 VGA driverek ... vagy az X3100 alig 12-14 hónapot késő DX10 drivere. -
tomcsa4 #10 Lehet csak én emlékszem rosszul a magok számára. Várok még információkat. -
#9
No, akkor az nemkő'! Nagyon jól megvagyok az alaplapra integrált kártyámmal elégedve. Mindenre elég. -
Abu85 #8 Amíg a DX futószalag az uralkodó addig 48 maggal illene kezdeni, persze csak ha nem a belépőszint van megcélozva. Bár a feltételezhető magméretből ítélve a csúcskatra mennek. -
tomcsa4 #7 Pontosabban több processzormag egy nyákra integrálva. Sok rá fér, gondoljunk bele, ohgy egy CPU 4 magos CPU milyen kis helyen is elfér. Szerintem erre a Larrabee-re ráfér 16 mag is. -
#6
Olyan CPU, ami felépítésben elég közel áll a mostani GPU-khoz. -
Kovász #5 Hát lehet, hogy ma még brutális lenne, de mire kijön olyan másfél év múlva (egy év múlva még mindig max. egy prototípusuk lesz...) addigra sztem megint csak sereghajtó lesz (bár ha az nvidia továbbra is csak átnevezett 9800Gt-ket dob piacra, akkor őt azért beérheti:D) -
Abu85 #4 Elsősorban grafikus kártya, mely főleg a szoftveres rendereléshez lesz igazítva. -
#3
Az intel videocsipjei eddig is brutálisak voltak 
-
#2
én annyit vettem le hogy egy brutális videókártya lesz:D -
#1
Csak nehogy a terroristák kezébe kerüljön!!! 
Mellesleg ez mi ellen van? Mire jó? Mert ebből a sok halandzsából számomra pont a lényeg nem derült ki. Miféle "erőmű" ez?