Új hozzászólás Aktív témák
-
lenox
veterán
Ha van valami ertekelheto adat, meres, pdf, szivesen megnezem, tudsz linket? De egyebkent a magot/cut kivulrol nezve mennyiben kulonbozik, hogy az adatot prefetch miatt kered vagy mert be akarod tolteni egy regiszterbe? Mert szerintem teljesen mindegy. Vagyis nem azon mulik, hogy prefetech vagy load.
Hol látsz te bármelyik GPU-ban multiprocesszoronként fél megabájt másodszintű gyorsítótárat?
60-70%-a van amd-nel, mint ilyen-olyan tar, nincs nagyragrendbeli kulonbseg. Szerintem sokkal fontosabb a mukodesbeli, nezd meg, hogy mukodik egy lds, ilyet tudtommal az intel nem csinal, pedig igen hatekony.
SP számítási teljesítménye két-háromszor kevesebb, mint a konkurens GPU-ké.
Inkabb csak 2-szer, es ez nem gpu, es foleg nem konkurens. De a kovetkezo genre 3-4-szer ekkora energiahatekonysagot hazudnak, szoval akar sp-ben is jo lehet. De foleg jo lehet, ha 16-32 magot beraknak egy cpu-ba.
-
Abu85
HÁZIGAZDA
Richards aki részt vett a fejlesztésben írt erről régebben sok cikket. Ő írta, hogy a legfőbb gond, hogy a prefetch nem hatékony egy ilyen rendszernél. Túl van terhelve a belső busz, így az adatok rendszeresen késnek. Ez nem egy négymagos processzor, hanem egy 60+ magos, nem ugyanazt a terhelést kapja az LLC.
A fotókon is 3 mm^2-nek néz ki a CU. A belső buszrendszer, ami sokat visz el.
Kell a tároló a CU-n belül, de az L2 az akkor is sokkal több, mint amennyi kellene, ha nem használnának x86-ot. Hol látsz te bármelyik GPU-ban multiprocesszoronként fél megabájt másodszintű gyorsítótárat?A Knights Corner iskolapélda a tervezésbeli eltéréseknek. Nagyjából 500-as pJ/FLOP mutató, vagyis egységnyi fogyasztás mellett az SP számítási teljesítménye két-háromszor kevesebb, mint a konkurens GPU-ké.
-
mrhitoshi
veterán
Szerintem egy játékból nem szabad általános következtetést levonni. Ez egy a sokból, és jó eséllyel marad egy csomó olyan játék, ahol nagyon is kell majd az erős CPU, akármennyire is jön a next-gen. Ugye PC-n hiába a nagy csodáknak, ha fizikai korlátok állnak fent. Én a helyedben hagynám az egészet, jó az az FX, nem kell bolygatni.
-
miresz
veterán
Most van lehetőségem anyagilag a lehető legjobban kiszállni ebből a vonalból. Gyakorlatilag vissza hozná azt amit bele fektettem,ezért is érdeklődöm a váltás miatt.
dezz: Igen a kalandvágy az megvan.
mrhitoshi: Igen ezen tépődöm én is. Jó lenne valami halvány információ legalább a Kaveriről,CPU erőt illetően.
-
dezz
nagyúr
Egyelőre csak tippelni lehet a Kaveri teljesítményére vonatkozólag, akár CPU, akár IGP téren, és hogy mikor jelennek meg olyan játékok (port vagy más), amik valóban aktívan kihasználják az IGP-t különféle számításokra egy diszkrét videókártya mellett.
Kell hozzá egy kis kalandvágy, vállalkozó szellem.
![;]](//cdn.rios.hu/dl/s/v1.gif)
Így fedezték fel Amerikát is...
-
miresz
veterán
Na,földi halandó nyelvre lefordítanátok nekem is?
Pl a Kaveri IGP-jének az erejét lehet-e majd kamatoztatni pl. Bf4-ben hogy van mellette egy GCN arhitectúrás kártya? Jelen esetemben egy Kaveri APU-n jobban futna,mint a mostani FX-emen? Gondolkodom Váltani FM2+ vonalra,de
teljesítményt nem nagyon szeretnék veszteni. -
lenox
veterán
Csak látványosan nem működik a prefetch egy ilyen rendszernél. Odaraktak mellé 512 kB L2-t, és a legfőbb optimalizálási útmutató, hogy maradj ezen belül.
Ezt honnan lehet tudni, probaltad, vagy van valami doksi rola? Az intel szerint mukodik, nekem nincs xeon phi-m, hogy kiprobaljam, de sima cpun szoktam hasznalni, es mukodik, nem tudom, miert kene feltetelezni, hogy nem mukodik. Esetleg ezt megnezheted. Termeszetesen az az utmutatas, hogy maradj a cache-en belul, mint ahogy nv-nel vagy amd-nel is az, hogy minimalizald a global memory hasznalatot, nincs kulonbseg kozottuk.
A számok rendben vannak.
Akkor legyszi magyarazd meg, hogy hogy jon ki a 3 mm2, a fotokon nem annyinak latszik. De a lenyeg ugyis az, hogy az allitasod, miszerint a mic-nek nagy atmeneti tarolo kell, hogy mukodjon, mig a gcn-nek nem az nem igaz, ugyanugy kell a gcn-nel is nagy terulet, csak nem l2 cache-kent hasznaljak. De a szerepe ugyanaz, minimalizalja a global memory elerest. Persze ebben semmi meglepo nincs...
A skalár ISA-nak szokták nevezni azt, ahol a rendszert a késleltetésre optimalizálják. A párhuzamos ISA az, amikor az adatpárhuzamos végrehajtás miatt a rendszert alapjaiban úgy építik fel, hogy a hatékony működés ne emésszen fel annyi tranzisztort, mint egy skalár ISA implementációja.
Tehat skalar isanak gondolod, de akkor ugye nem igaz amit irtal, lasd intel.
-
Abu85
HÁZIGAZDA
Csak látványosan nem működik a prefetch egy ilyen rendszernél. Odaraktak mellé 512 kB L2-t, és a legfőbb optimalizálási útmutató, hogy maradj ezen belül.
A számok rendben vannak. Bár a regiszterterületnél per-shader szinten számoltam, de ha összesített kell, akkor a MIC magban 8 kB van, míg a GCN CU-ban 256 kB.
A skalár ISA-nak szokták nevezni azt, ahol a rendszert a késleltetésre optimalizálják. A párhuzamos ISA az, amikor az adatpárhuzamos végrehajtás miatt a rendszert alapjaiban úgy építik fel, hogy a hatékony működés ne emésszen fel annyi tranzisztort, mint egy skalár ISA implementációja.
Én is alig várom, hogy jöjjön erre hardver.
-
lenox
veterán
Akkor miért nem látunk a MIC magokban 256 szálat, ami ideális lenne annak rendszernek. Miért van csak négy szál?
Nem ertem a kerdest, nem kell sok szal a nagy teljesitmenyhez, csak megfelelo szamu alu, es el kell tudni latni oket adattal. Azert gondolod, hogy sok thread kell, hogy amig valamelyik adatra var a memoriabol, addig valamelyik masik tudjon szamolni. De mint irtam erre kitalaltak a prefetch-t, szoval emiatt nem kell sok szal.
A szamok nincsenek rendben, ezek szerint tahitinal a 32 cu 100 mm2 a 365-bol, pedig valojaban a chip nagy reszet a cu-k teszik ki. Masreszt kimaradt 4x64 kB regiszter, szoval egy cu-ban is 300 kB folotti atmeneti tarolo van, intelnel sincs 2-szer ennyi, ha esetleg vaamelyik implementacioban 256 kB l2 cachet valasztanak, akkor tok hasonlo lesz a mennyiseg.
Ezért nem használ senki, még egyszer hangsúlyozom: Senki! skalár ISA-t az ilyen adatpárhuzamosságra tervezett rendszer fejlesztéséhez.
Az avx-512 az ugyebar egy extension, ez most neked skalarnak szamit vagy nem? Ha igen, akkor nem igaz, amit irsz, ha nem akkor meg nem ertem, hogy jon ez ide.
Ha a legnagyobb számítási kapacitásra törekednének, akkor már rég nem ölnének egy deka zsetont sem a MIC-be, mert az nagyon messze van a konkurens rendszerektől.
Hiszen csak ra kell nezni a top500-ra vagy a green500-ra. En azert kivancsian varom a kovetkezo gent, kulon kartyan is meg cpu-ban is.
Amugy vegyuk eszre, hogy a sokezer szal szuksegessegebol indult a vita, de te xeon phi fikazassa alakitottad. Szerintem megegyezhetunk benne, hogy ugyanannyi wattbol a xeon phi fele annyi sp-t es ugyanannyi dp-t tud, mint egy tahiti, de ez nem bizonyitja, hogy sokezer szalat kell tudjon kezelni valami ahhoz, hogy hatekony legyen.
-
Abu85
HÁZIGAZDA
Az nem naivitás, hogy ha azt mondom, hogy a cégek nem ülnek össze teadélutánokra, hogy megosszák egymással a fejlesztéseik leírását és működését. Az egy dolog, hogy az ipari kémkedést nehéz minimalizálni, de addig, amíg a termék ki nem kerül egy partnernek, gyakorlatilag más sem tud róla semmit. Abban a szakaszban pedig kizárt, hogy bárki bármit tudjon egy konkurens fejlesztőséről, amikor a tervezőasztalon van. Szóval a cégek által megálmodott irányt saját maguknak köszönhetik. Egyszerűen átgondolták, hogy merre lehet menni, és ugyanazt tartotta mindenki logikusnak. Tekintve, hogy mennyire egyértelműek az efféle integráció előnyei, így még egy átlag egyetemista mérnökjelölt is azt az irányt választaná.
-
Jakuu
őstag
"Öt cég teljes titokban belőtte ugyanazt az irányt, egymással nem kommunikálva erről. Valóban ők járnak tévúton?"
Abu a naivitasod engem mindig megmosolyogtat.
Szerinted a cegek, nem tudjak, hogy merre tart a masik ? Annyira azert nem hulye egyik se, hogy ne probalja kiszimatolni a masik ceg merre is probal nyitni.
Arrol nem is beszelve, hogy veletlenek nincsenek, hogy eppen egyszerre az 5 ceg sutba dobja az elozo utat amit jart es uj vizekre evez. Hat hogyne, micsoda veletlen.
Mint a VGA kartyaik piacra dobasanak datumai es sorolhatnam. -
Abu85
HÁZIGAZDA
Akkor miért nem látunk a MIC magokban 256 szálat, ami ideális lenne annak rendszernek. Miért van csak négy szál?
Csak nem mindegy, hogy mekkora és milyen elrendezésben. Egy MIC maghoz 512 kB-os gyorsítótár tartozik, ami sok. De hasonlítsd te össze a MIC magot a GCN CU-val:
MIC: 22 nm-en ~4 mm^2, 512 bites SIMD motor, 512 bájt regiszterterület, egy skalár egység, 32 kB L1i, 32 kB L1d
GCN: 28 nm-en ~3 mm^2, 2048 bites SIMD motor, 4 kB regiszterterület, egy skalár egység, 64 kB LDS, 16 kB L1d
A GCN CU azonos órajelen négyszer gyorsabb a MIC magnál, plusz a fentiekbe nem számoltam bele a MIC maghoz szükséges fél megabájtos L2-t, ami kell, tehát úgy már két CU is belefér egy MIC mag teljesítményébe, vagyis egységnyi 22 nm-es területre nyolcszor nagyobb teljesítmény építhető 28 nm-en. Ebből a teljes chipre nézve, a belső buszok kialakítása után, ugyanakkora méret mellett bőven marad négyszeres sebességelőny. Ezért nem használ senki, még egyszer hangsúlyozom: Senki! skalár ISA-t az ilyen adatpárhuzamosságra tervezett rendszer fejlesztéséhez. Ezekhez speciális ISA kell, amelyekben rejlik a fejlesztés ereje.Miért mire gondolsz? Gondolod odament az NV az AMD-hez, hogy látjátok mi a gond a hagyományos fejlődéssel? Na ti erre mit tudtok javasolni? Mindenki saját maga értékelte ki a lehetőségeket, és az opciók közül igen érdekes, hogy nagyon sokan ugyanazt az irányt választották.
Ha a legnagyobb számítási kapacitásra törekednének, akkor már rég nem ölnének egy deka zsetont sem a MIC-be, mert az nagyon messze van a konkurens rendszerektől.
-
lenox
veterán
A legfőbb gond az x86, amit nem készítettek fel arra, hogy a processzormag sokezer szálat kezeljen párhuzamosak.
Ez meg tovabbra sem igaz.
Következésképpen egy maghoz nagyon nagy gyorsítótárat kell társítani
Teljesen mindegy, hogy gyorsitotar kell, vagy lds, vagy regiszterfile. A vegeredmeny ugyanaz, tarolni kell az atmeneti adatokat a lapkan belul. Errol nem erdemes elfeledkezni.
Öt cég teljes titokban belőtte ugyanazt az irányt
Te ezt most teljesen komolyan mondod, hogy titokban?
Valóban ők járnak tévúton?
En nem mondtam ilyet, kulonbozo gyartoknak kulonbozo celjaik lehetnek. Szerintem pl. az intel nem fog a leggyorsabb gpura torekedni, ellenben fog a legnagyobb szamitasi teljesitmeny fele. A ketto nem ugyanaz.
#98: Nem, azt jelenti, hogy a mag meretehez kepest, ami magaban foglalja a l1 es l2 cachet is pl., 2%-nal kisebb. ALU lehetne benne tobb, de majd nezd meg a kovetkezo generaciot.
-
dezz
nagyúr
-
Rive
veterán
...nem a hatékony x86 emuláció lesz a fő tervezési szempont.
Kicsit alaposabban átgondolva van egy olyan érzésem, hogy ez már igazából mindegy. Egy elfogadhatóan működő JIT fordító összeütése (és OS-be integrálása) erről a pontról indulva már nem olyan kaliberű feladat, hogy előbb-utóbb ne csinálná meg valaki 'csak, mert képes rá'.
Onnantól pedig a piaci nyomás dönt majd.
-
Abu85
HÁZIGAZDA
Azt a projektet lelőtték egy ideje. Most csak a fiókban áll a hagyaték. Valóban volt erről szó, hogy ez nem rossz ötlet, de akkor, amikor Eric Demers volt a divízió vezetője. Azóta jött az egységes vISA irány, létrejött a HSA alapítvány, belépett a teljes piac nagy része, és nagyjából ennyi elég volt az alapötlet elvetéséhez. Nem mellesleg most John Gustafson vezeti a fejlesztéseket, és neki rengeteg tapasztalata van az x86-ról, mert a Larrabee/MIC egyik fejlesztője volt. Ő a tradicionális, évek óta működő tervezési elveket vallja. Tehát az AMD továbbra is viszonylag sűrűn vált majd GPU ISA-t, és nem a hatékony x86 emuláció lesz a fő tervezési szempont. Persze a sűrűn az így is 5-6 éves ciklusokat jelent, tehát még van ideje ennek az architektúrának.
-
Abu85
HÁZIGAZDA
Nem az a baj a MIC rendszerrel, hogy nem mély integráció, hanem, hogy nem hatékony. Az integráció alatt azt akarjuk, hogy a CPU és a GPU előnyei egy lapkában vegyüljenek. A MIC ezt nem teszi meg, mert maga a MIC mag nem hordozza azokat a jellemzőket, ami egy GPU-t hatékonnyá tesz. Ez persze nem feltétlenül az AVX hibája, az csak utasításkészlet. A legfőbb gond az x86, amit nem készítettek fel arra, hogy a processzormag sokezer szálat kezeljen párhuzamosak. Következésképpen egy maghoz nagyon nagy gyorsítótárat kell társítani, és mindennél jobban kell ügyelni arra, hogy a munkafolyamat a gyorsítótáron belül maradjon.
A Larrabee/MIC és ez az egész irány egy 10 éve dédelgetett álom, ami mérnökök tucatjait fogyasztotta el. Többek között az adatpárhuzamos architektúrák szempontjából legokosabbnak számító embereket, mint John Gustafson vagy a szoftveres oldalon Michael Abrash és Andrew Richards. De említhetnénk még Atman Binstock, Tom Forsyth, Mike Sartain és Pat Gelsinger személyét is. És bármennyire tetszik mindenkinek az ötlet ezek az emberek elmondták az Intelnek, hogy sohasem fog működni. Mivel az Intel nem hallgatott az intelmeikre, így otthagyták a céget.
Az azért jelent valamit, hogy jelen pillanatban fél tucat cég dolgozik aktívan az integráció elmélyítésén. Mindenkinek meg volt a lehetősége utat választani. Az Intel kivételével mindenki azt választotta, hogy vegyítik a párhuzamos és a skalár ISA-t a lapkán belül, annyira elszeparálva, hogy ne rontsák egymás működésének hatékonyságát. És ezek a cégek (ARM, AMD, NVIDIA, Qualcomm, Imagination) egyenként több GPU-s tapasztalattal rendelkeznek, mint az Intel. Öt cég teljes titokban belőtte ugyanazt az irányt, egymással nem kommunikálva erről. Valóban ők járnak tévúton? -
Rive
veterán
En csak elonyet latom annak, ha egy CU a SIMD utasitasok mellett az x86-tal elboldogul.
Irtam már valahol fönnebb, hogy az AMD-nél landolt anno a Transmeta ~ teljes hagyatéka.
Ha nagyon akarják, akkor egy következő generációhoz nagyon kevés hardverbeli változtatás kell, és - bár alacsony per-thread hatékonyság mellett - mehet párhuzamosan néhány ezer szálnyi x86 a GPU-ra.
A CPU meg eheti azokat a maradék szálakat, amiknek szálszinten is hatékonyan kell futniuk. -
lenox
veterán
-
dezz
nagyúr
Bizonyára vannak olyan feladatok, amikre a Xeon Phi a legoptimálisabb. Annyi, hogy itt jóval több tranzisztor dolgozik 1-1 SIMD művelet vérehajtása közben. (Normál CPU-nál meg még több.) Plusz ott vannak még a normál x86 kód végrehajtásához szükséges tranzisztorok is.
A GPU tranzisztorainak a nagy részét a SIMD egységek (vagy amilyen szervezésű, lényeg, hogy ALU-k "hegyei") teszi ki.
-
lenox
veterán
A CPU-s SIMD-ezés sem haszontalan, de megközelíteni sem tudja hatékonyságban a GPU-t! Előtt-utóbb az Intel is belátja majd.
A GCN is SIMD, es az Xeon Phi sem CPU-s SIMD. En csak elonyet latom annak, ha egy CU a SIMD utasitasok mellett az x86-tal elboldogul. Ez melyebb integracio, mint amit barki mas csinal, szoval akinek az integracio a vesszoparipaja, annak tetszenie kellene. Nyilvan a mai intel procikban vagy akar a xeon phiben talalhato eroforrasviszonyok nem tokeletesek minden celra, de ez legyen az intel problemaja. En komoly potencialt latok benne, mar irtam valahol, hogy szerintem hosszu tavon ez a befuto. De majd meglatjuk.
-
dezz
nagyúr
Egyátalán nem csak a "PC játékgépesítéséről" szól ez a dolog alapvetően!
(Mellesleg, ha úgy vesszük, azóta játékgép a PC, mióta beleköltözött az elsősorban játékra tervezett, közepes minőségű 3D grafikát előállító GPU.)
10+ éve téma a GPU-k jelentős - a CPU-t nagyságrendekkel meghaladó! - számítási tejlesítményének kihasználása általános, tehát nem csak grafikai célra! Ugyancsak jópár éve már úgy működnek a GPU-k, hogy nem fix funkciós egységek végzik az előre meghatározott számításokat, hanem kis programocskák futnak bennük, ALU-k százait, ezreit dolgoztatva!
Talán nem teljesen mindegy, hogy egy átlagos PC-ben pártíz GFLOPS vagy több TFLOPS számítási teljesítény áll rendelkezésre. Szerinted "ennek az informatikában semmi jelentősége"? Komolyan???
Meg egy fontos dolog van itt. Korábban azért nem foglalkoztak ezzel annyira, mert fejlődtek a CPU-k és a gyártástechnológia, ami évről évre elégséges teljesítménynövekedést tett lehetővé. De ennek lassan vége! Legalábbis, ami a szilíciumalapú félvezetőket illeti! 10-20 év múlva bizonyára jön majd valami új, de addig sem állhat meg a fejlődés. Mellesleg, abba a nagy Intel is belebukna, és még sokan mások.
Így jönnek egyre inkább képbe a CPU-nál sokkal hatékonyabban dolgozó GPU-k...
"majd ha IBM"
Igen, sok nagy jelentőségű kutatás folyik náluk, amik közül néhány eredményeivel 10 év múlva majd találkozhatunk is talán.
"Intel"
Haha. Milyen igazán jelentős dolgot tett le az Intel az asztalra az utóbbi 20 évben? Csak nehogy azt mondd, hogy Pentium 4!
Itanium? Larrabee?x86 vonalon min. 15 éve az AMD az, amely cég igazán innovatívnak nevezhető! Soroljam, mit vezettek be elsőként - amit az Intel csak nagy kelletlen-kénytelen követett?
(#50) Abu85: Szerintem az lesz, hogy bekerül majd az FPU helyére is néhány GCN CU - de nem az egész GPU. Az szépen ott lesz a CPU mellett külön egységként is.
(#57) LordX: A RISC annyit tesz: erősen leegyszerűsített + egyforma hosszúságú utasítások. A mai x86/x64 CPU-k mikro- (AMD-nél macro-) OP-jai RISC utasításoknak tekinthetők az eredeti x86/x64 összetett, változó hosszúságú CISC utasításihoz képest.
(#79): A klasszikus RISC procikban nem volt (az egyszerűbbekben ma sincs) register rename. Ehelyett több általános célú regiszterük volt, és kód-optimalizációval lehetett kikerülni az ütközéseket.
Az egyszerűbb RISC procikban a decoding nem uop-okra fordít, hanem közvetlenül vezérli a különféle részegységeket. Ez alig más, mint a scheduling.
Egyébként az AMD procijaiban először macro-op-ok "indulnak útnak", majd ezeket tovább bontja a scheduler micro-op-okra.
Jelentős különbségek: az A15 uop-jai un. klasszikus up-ok, amiket a későbbiekben már nem lehet szabadon csere-berélni. Az mai x86/x64 procikban pedig új rendszerű uop kezelés van. Bővebben.
(#76) lenox: A CPU-s SIMD-ezés sem haszontalan, de megközelíteni sem tudja hatékonyságban a GPU-t! Előtt-utóbb az Intel is belátja majd.
[ Módosította: 7 ]
-
apatyas
Korrektor
Tök jó hogy ezt is tudni fogja a kaveri, azt hittem csak a GCN és a közös memócímtér lesz benne újdonság.
De így már értem hogy hogyan adhattak kaverit a konzolt illetve portolást programozóknak.
Apropó, a 'konzol apu'knak nincs valami kódneve ami rövid és használható?
És, 'gyüjjön mán' a kaveri ! -
lenox
veterán
Meg igazából kellemetlen lenne számukra az AVX-et leégetni, amikor termékeket építenek rá.
Nehez is lenne, mivel nyilvanvaloan nem az avx miatt esik egy flopra tobb vagy kevesebb fogyasztas.
Nem is értem miért.
Talan mert DP-re volt szanva, de amugy ez egy termek, meg lehet venni, hogy lenne mar ilyen, hogy nem engedik, te is irtal az opencl eredmenyekrol, egy teljesen kontrollalatlan program alapjan (nem is ert semmit).
-
Abu85
HÁZIGAZDA
A Xeon Phi-vel az AMD nem foglalkozik, nekik ez a rendszer nem konkurencia. Meg igazából kellemetlen lenne számukra az AVX-et leégetni, amikor termékeket építenek rá.
Legtöbbször az egyetemi prezik hozzák elő ezeket az adatokat. De az NV-nek is van számos olyan anyaga, ahol ecsetelték, hogy az Intel által sokat mondogatott autovektorizálás mellett a Xeon Phi SIMD-jének átlagos kihasználása kemény 6%. Tehát ha teljesítményt akarsz, akkor mehetsz OpenCL-re, vagy Assembly szintre a Phi-n is.
Ja Linpack-ban DP GFLOPS mellett. Máshol meg nem is engedik mérni a teljesítményét. Nem is értem miért. -
lenox
veterán
De nyilvanvaloan nem ugyanugy vannak benne az eroforrasok balanszolva, es nem is ugyanarra a celra keszult, szoval ez nem annyira mervado, bar elhiszem, hogy az amd marketinganyagban ez van. Vagy valamiert azt gondoltad, hogy avx csak ilyen konfigban lehet? Amugy a top500-ban nem latszanak annyira a hatekonyabb gpu architekturak, amit latok az a K20 vs Xeon Phi, es egalban vannak.
-
Abu85
HÁZIGAZDA
A Xeon Phi pJ/FLOP mutatója 400 és 600 között van, vagyis egy mai GPU-architektúra kétszer-háromszor hatékonyabban működik annál, miközben a Xeon Phi gyártástechnológiailag sokkal fejlettebb node-on van. Szóval az AVX példája csak a lehetőséget mutatja, de hatékonyság szempontjából ellenpéldaként lehet rá mutatni, hogy miért nem ezt az utat járja a többi cég.
(#77) mzso: Azt előbb látni kellene, hogy a gyakorlatban hogy működik. Nyilván nem lehetetlen mixelni a CPU-t egy combosabb FPU-val, de olyan extrém hatékonyságú multiprocesszorokkal, mint amilyenekkel egy mai GPU dolgozik, már nem érdemes próbálkozni.
-
LordX
veterán
Ne keverjük már a RISC utasítást a uOP-al.. A RISC utasítást logikai regisztereken dolgozik, a uOP meg fizikai regisztereken (regiszter átnevezés..). RISC utasításoknál nem értelmezhető olyan, hogy RaW/WaR/WaW hazárd, míg a uOP-nak ez része. RISC processzorban is van uOP.
Egy RISC processzorban pontosan ugyanez a decode lépés benne van a pipeline-ok (és az issue) előtt, és pontosan ugyanezt csinálja (utasítást uOP-ra dekódol, berakja a uOP sorba, ahonnan az issue majd OoO válogat). Ha azt mondod, hogy valahol előáll egy RISC utasítás, akkor még egyszer ugyanazt megcsinálod (max a 2. lépés az egyszerűbb input miatt egyszerűbb)? Össze lehet hasonlítani egy Cortex-A15 pipeline-t és egy x86 pipeline-t. Előbbi egyértelműen RISC, utóbbi CISC. Mégis mindkettőben egy ugyanott van a decode lépcső, ugyanott vannak a uOP sorok, ugyanúgy megy az issue. Mutassa meg nekem bárki a különbséget, ami azt mutatja, hogy az egyik emulálva dolgozik, a másik nem.
Ettől függetlenül igen, némely x86 utasítást több uOP-ra kell dekódolni. Ettől még nem lesz ez sem emuláció, sem RISC utasítás.
-
lenox
veterán
Szerintem ezek azert nem pont igy vannak. Egyreszt AVX/AVX2 (meg akar SSEx) peldaja, hogy hogyan lehet mixelni adatparhuzamos es kesleltetesre kihegyezett utasitasokat. Masreszt a szalak nem celok, hanem eszkozok, ezt mondjuk sokadjara mondom el, de mindegy. Harmadreszt azt amit egy gpu multiprocesszor, vagy cu, egyseg tud, nevezetesen, hogy mondjuk 2000 szalad van, es amig ezek nagy resze adatra var a memoriabol addig a tobbi tud szamolni, azt cpu-val is meg tudod csinalni, a prefetch utasitasokkal, illetve azt is eleg jol lehet kontrollalni, hogy mi kerul a cache-be, es mi csak a memoriaba. Az nyilvan igaz, hogy amig pl. opencl-lel egy gpun ez automatikusan megtortenik, addig cpu-n eleg ugyesnek kell lenni, hogy jol mukodjon, vagy olyan libet kell hasznalni, amiben mar meg van irva. Negyedreszt bar egy cpu-ban viszonylag nagy l2 cache van, de egy cu-ban meg van helyette lds meg regiszterek. Persze ettol meg a mostani cpuk nem ugyanarra vannak kihegyezve, mint a gpuk, lejebb kene vinni az orajelet, nagyobb simd unit kellene belejuk, lehetne akar 4 szalat is kezelniuk, a cachet is lehetne ugyesebben szervezni. Es mintha ilyenrol mar hallottam is volna valahol....
-
Jakuu
őstag
AMD innovaciobol ismet jelere vizsgazott. Sokan tanulhatnanak tole a piacon, foleg azert is mert altalaban az uj technologik elterjedesenek kerekkotoi legtobbszor, csak a sajat erdekeiket szemelott tartva a fejlodessel szemben.
Iden mar masodik ilyen uttoro kezdemenyezest latunk az AMD-tol, amihez remelem sokan fognak csatlakozni.
-
#73
E.Kaufmann
veterán
Jack@l
#10
E.Kaufmann
veterán
Szerintem már ki lett feszítve régóta a Neumann architektúra határa a mai pc-kben, amúgy meg van Harvard architektúra meg biztos sok más is még. Látom azóta már sokat írtak a témában itt a fórumon.
Neumann bá azért csinálta az elveket, hogy kevesebb szívással össze lehessen dobni egy működő számítógépet. Lényegében egy jó minimum követelményrendszer, amivel már lehet egy működő gépet építeni. Hogy legalább el tudjanak indulni valahol.
-
-
Igazabol azt mondom, hogy az ilyesmi megkulonboztetes igazan nem olyasmi, amivel tul sokra lehet jutni.
Pl. egy x86-os CPU, amiben kulon van icache meg dcache, az most Neumann vagy Harvard? Es ha ramondjuk, hogy a ketto kozul valamelyik, akkor abbol kovetkezik-e barmi is? -
#66
flugi
tag
Meteorhead
#49
flugi
tag
válasz
Meteorhead
#49
üzenetére
Kicsit belekotyogok: valószínűleg könyvtár szintű támogatottság kérdése lesz az elterjedtség, ahogy a CUDA is elterjedtnek mondható, legalábbis stabil felhasználóbázisa van, noha gyártóspecifikus. Ha sikerül kihozni egy ütős HSA/Mantle alapú könyvtárat, akár csak mátrixműveletekre, az könnyen lehet sikeres. A nyers erő például az AMD oldalán áll jelenleg, tehát akár ki is jöhetnek egy olyan rendszerrel, ami a sztenderd mérce szerint demonstrálhatóan hatékonyabb, mint a CUDA+Tesla kombó.
-
"A pipeline-ban a decode stage nem azt jelenti, hogy az x86 utasítást átalakítja RISC utasításra"
De.
"hanem azt, hogy melyik futószalagon, milyen regiszterekkel kell az utasítást végrehajtan"
Aha. Es egeszen pontosan melyik futoszalag hajtja vegre pl. a LOOPD utasitast? Hat, egyik sem. Felobontjak RISC-es mikroutasitasokra es azok hajtodnak vegre a futoszalagon.
"ugyanez a stage pontosan ugyanezt csinálja egy RISC chipen is.."
Egyebkent tobbek kozott pont a pipeline az, ami a CISC processzorok halalat okozta, mert tenylegesen CISC utasitasokat feldolgozo pipeline-t baromi nehez csinalni, sokkal-sokkal-sokkal problemasabb, mint szetszedni a CISC utasitasokat mikroutasitasokra es azokat vegrehajtani.
-
LordX
veterán
"Az x86 ugye ma RISC alapokon vanik emulálódva, úgy nagyjából."
Ez nem tudom honnan jött, de úgy hülyeség ahogy van. Igen, egy mai modern x86 processzor felhasznál RISC processzorokból származó ötleteket, de hogy emulálna bármit is, az nonszensz. A pipeline-ban a decode stage nem azt jelenti, hogy az x86 utasítást átalakítja RISC utasításra, hanem azt, hogy melyik futószalagon, milyen regiszterekkel kell az utasítást végrehajtani, esetleg milyen függőségei vannak, ugyanez a stage pontosan ugyanezt csinálja egy RISC chipen is..
-
Abu85
HÁZIGAZDA
Azért kell rengeteg szál, mert rengeteg adat vár végrehajtásra párhuzamosan, tehát az ilyen rendszereket rengeteg szállal lehet etetni. Minél hatékonyabban eteted annál kisebb lesz a pJ/FLOP mutatója a hardvernek, vagyis annál kevesebbet fogyaszt egységnyi teljesítmény mellett, és emellett igen kevés gyorsítótárral lesz szükség, hiszen a sok szál elfedi a memóriaeléréssel járó késleltetést. Ettől ilyenek ma a GPU-k. Ha ezt elveszed tőlük, akkor jóval nagyobb cache kell nekik és nőni fog a pJ/FLOP mutatójuk, vagyis ugyanazt a teljesítményt nagyobb fogyasztás mellett adják majd le.
(#53) Rive: Ha a feladat érzékeny a késleltetésre, akkor a GPU-s feldolgozással csak lassul. A HSA koncepciójában jelenik meg az, hogy a futószalag egyes lépcsőit bünti nélkül végezhesse a megfelelő mag.
-
citkar
addikt
Szerintem az utóbbi 30 évben is elég sok fejlődés volt az x86 architectura terén és ahogy írtad, már alternatíva is van. Ezek után ráadásul lehet még több lesz.
Én örülök, ha fejlődést látok, újításokat, még akkor is ha nem mind lesz használatos a mindennapokban, de talán ez olyan lesz. Túl könnyű lenne, ha ismernénk azt az egy utat, ami a legjobbhoz vezet. -
#54
Abu85
HÁZIGAZDA
Meteorhead
#49
Abu85
HÁZIGAZDA
válasz
Meteorhead
#49
üzenetére
A Mantle az specifikus. Az jelen pillanatban elég nagy támogatást szerzett, és egy tucatnál is több játékot fejlesztenek rá már most. Már a Frostbite 3-ból lesz 15+ játék. Ez egy versenyhelyzet. Ha valaki nem implementálja, akkor technológiailag lemarad a játékok közötti szoftveres versenyben.
A HSA elsődleges területe a szerver és a mobil lesz (Androidon ez lesz A platform és nem az OpenCL). A konzumer szinten a multimédiás programok már rástartoltak. A játékfejlesztőket inkább jobban érdekli a Mantle, mert a DX problémáitól jobban szenvednek.
Az Intel OpenCL 1.2-t akar. Szóba sem került a 2.0. Ahhoz 2015 végéig nem is lesz hardverük.
-
Rive
veterán
Akkor érdemes lenne megforditani Dabadab felvetését, és úgy kérdezni: mi akadálya van annak, hogy a CPU feladatainak egy részét - akár gyalázatos per-thread hatásfokkal, de eszelős 'szélességben' - a GPU-ba rántsuk?
És akkor most beszélgessünk adatbázis vagy webszerverekről, vagy mittudomén.
-
"Mert egy CPU-mag sosem fog 2560 szálat kezelni egyszerre, míg mondjuk a GCN multiprocesszora erre van tervezve"
Es miert kellene egy CPU magnak 2560 szalat kezelnie? Az ISA-ba siman beleirhatod, hogy a GPU resz ezt csinalja es igy mukdik, a CPU meg ugy, mondom, pont ugy, mint ahogy tortenetileg ez az FPU-nal is tortent, aminek az utasitasai mar reg benne voltak az ISA-ban, amikor meg boven kulon szilikonon voltak es teljesen elteroen mukodtek. A dolog nem szol semmi masrol, mint hogy legyenek fix utasitasok, ne eltero nyelvet beszeljen minden GPU.
-
Abu85
HÁZIGAZDA
Mert egy CPU-mag sosem fog 2560 szálat kezelni egyszerre, míg mondjuk a GCN multiprocesszora erre van tervezve. Vagy késleltetésre optimalizálsz, vagy adatpárhuzamos végrehajtásra. A kettő együtt nem működik.
(#48) Rive: Jellemzően 1000 szál fölé lő az NV és az AMD a multiprocesszorok tervezésénél. De nincs egzakt érték. Ami jobban fekszik az architektúrának. Az ultramobil GPU-k is 200-500 szállal dolgoznak a multiprocesszoron belül. Egyedül az Intel dolgozik sokkal kevesebb szállal (egészen pontosan 7/EU).
-
#49
Meteorhead
aktív tag
Abu85
#20
Meteorhead
aktív tag
Kíváncsi lennék a véleményedre, hogy szerinted ennek lesz-e látható hatása a PC-s piacra.
Kicsit azt érzem, hogy hQ és az egész HSA a PC-s piac szemszögéből olyan, mint a Mantle. Egy platformspecifikus cucc, aminek a terjedése eleve halálra van ítélve az által, hogy a konkurensek magasról tojnak rá. Lehet, hogy nyílt, de PC-n ha csak AMD implementálja, akkor platformspecifikus.
Mégis mi reménye lehet ennek a queue-ing modellnek elterjednie, amikor a packet modell kialakításában részt sem vettek azok, akik még csak most tervezik azt az architektúrát, ami konkurenciát szeretne állítani Kaverinek. A borzasztó borúlátásomat csak az táplálja, hogy a legkisebb jelét sem látom annak, hogy a konkurencia akár csak a legáttételesebb módon is, de az AMD saját játékában (az integrációban) szeretné felvenni a versenyt.
Intel szerver fronton 15 magos procikat hoz, NV legutóbbi konferenciáján egyetlen szó sem esett Tegra 5-ről, vagy Maxwellről... Egyedül NV-ről van hír, hogy Tegrával hoz közös címteret, ami az egyik alappillére HSA-nak, de nem vagyok benne biztos, hogy a queue-ing modell megvalósításához nincs szükség HW-es drótozásra is, ha másnak nem, a GPU-s szálütemezőnek tudnia kell valamit hozzá.
Azzal, hogy az Intel azt súlykolja, hogy OpenCL-es játékokat szeretne látni azzal épp azt erősíti, hogy egyelőre nem áll szándékukban OpenCL 2.0-nál mélyebb integrációt megvalósítani. Az már közel van a HSA queue-ing modellhez, de ugyanazon az OS queue-n megy keresztül, mint minden más.
Mindenesetre ha már csak OpenCL 2.0 conformance lenne minden PC-s piaci szereplő között, már az nagy lépés lenne. Akkor már csak azzal a nyomorult C99 variánssal kéne megküzdeni a kernelnyelvben.
-
Abu85
HÁZIGAZDA
Nem az utasításokkal van a baj. Az ISA-nak az utasítások csak egy részét képzik. Az ISA azonban definiálja a rendszer alapvető működési modelljét is az utasítások mellett.
Egy GPU ISA modellje alapvetően különbözik a CPU-k ISA modelljétől. Ezt nem szakszóval párhuzamos ISA-nak hívják a cégek, mert a CPU-k skalár ISA-jához képest a legfőbb szempont az adatpárhuzamos feldolgozás hatékony biztosítása, vagyis alapvetően arra kell ügyelni, hogy a termék gyorsan hozza létre a szálakat vagy semmisítse meg azokat, illetve ezek között biztosítsa az alapvető szinkronizációt, és a nagyon gyors kommunikációt. És itt sokezer szálról van szó, tehát ez egy kritikus része az implementációnak. Ha ezt az előnyt elveszed a CPU-ba építéssel, akkor a rendszer már nem lesz hatékony. -
#44
MCBASSTION
aktív tag
MCBASSTION
aktív tag
jo lesz ez
mar az opencl 2.0-ban is tetszett, hogy a gpu onmaganak adhat feladatot, ezzel sok cpu->gpu->cpu utat meg lehetne sporolni. -
citkar
addikt
Mégis miért kéne mutatnom, talán azt olvastad nekem van?
Olvasd el még egyszer szerintem, amit írtam, mert az arra utal, hogy attól, hogy van valami ami működik, még lehet fejleszteni mást, akár jobbat.
Nem biztos, hogy épp ez lesz a jövő, de ha mindenki csőlátó és a beszűkült lenne most is íjászkodnánk és gyűjtögetnénk, ami nem rossz, úgy is lehet élni, akár boldogan is, de valamiért mégis elhaladt felette az idő. Mint ahogy más vívmány felett is és keresni kell az újat, ami talán jobb lesz, legalább egyes területeken. -
Attol meg, hogy egy ISA-ban vannak az utasitasok, az nem jelenti azt, hogy ugyanazon a pipeline-on kell futniuk, ahogy gyakorlatilag az FPU utasitasok is egy tok kulon cuccon futottak, a CPU bottal se piszkalta oket, aztan megis reszei voltak az x86 ISA-nak (aztan az mas kerdes, hogy idovel a ket szilikon egybeolvadt, de ez most nem tul erdekes).
-
Rive
veterán
Hümm.
Az x86 ugye ma RISC alapokon vanik emulálódva, úgy nagyjából.
Plusz az a néhány multimédia-kiegészités, amitől az eredeti x86 kiagyalói anno kollektive hajrákot kaptak volna.Nomeg ott van a Transmeta-féle x86-emuláció, VLIW alapon (jogok az AMD-nél).
Nem látok amolyan igazán áthághatatlan határokat ebben a dologban.
Ui.: van egy olyan sejtelmem, hogy az Intel kicsit falnak fog szaladni azzal az x86-dinnyével amit csinált pár éve, nem emlékszem hirtelen, mi is volt a neve.
-
Abu85
HÁZIGAZDA
Nem. Ez teljesen téves irány. Az AMD teljes értékű koprocesszorokként gondol az GPU multiprocesszorokra. Két alapvetően eltérő elv szerint működő ISA modell dolgozik a procikban és a GPU-kban. Ezeket egymással nem lehet vegyíteni, mert ami az egyik előnye az a másik hátránya és fordítva. Ezek csak úgy egészítik ki egymást hatékonyan, ha együtt dolgoznak egy lapkán belül, de elvi működésben kellően el vannak szeparálva egymástól.
-
"Keptelenseg megcsinalni, mert nem egy utasitas architekturat (x86/x64) hasznalnak."
Nem keptelenseg, nekem egyre inkabb ugy tunik, hogy az AMD arrafele halad, hogy a GPU utasitasok is belekeruljenek az x64 utasitaskeszletbe (pont ugy, mint ahogy az az FPU utasitasaival tortent).
(#37) Abu85: lehet vegyiteni a kettot, ne felejtsd el, hogy a "487" meg gyakorlatilag ugy mukodott, mint a 387, vagyis kulon egyseg volt (bar a CPU-n belul volt) es aszinkron modon mukodott (mondjuk legalabb explicit WAIT nem kellett neki, mint a 287-nek).
-
Abu85
HÁZIGAZDA
válasz
Alchemist
#29
üzenetére
Olyan nem lesz, mert a CPU-ban a GPU előnye elveszik. Nem lehet büntetés nélkül vegyíteni egy késleltetésre és egy adatpárhuzamos végrehajtásra optimalizált architektúrát (az egyik irány el fog veszni). Az AMD pont azt akarja, hogy ezek megtartsák az előnyüket, tehát az egyetlen mód, hogy egymás mellett működjenek. Közösen ugyan, de kellően elszeparálva egymástól ahhoz, hogy a különböző elvek szerint tervezett ISA modell hatékony maradjon.
-
Fiery
veterán
válasz
Alchemist
#29
üzenetére
Keptelenseg megcsinalni, mert nem egy utasitas architekturat (x86/x64) hasznalnak. Amit az AMD csinal, az csak egy kenyszerusegbol szuletett megoldas (GPU) tovabb faragasa. A GCN jo cucc, de me'g a HSA-val sem lesz belole FPU, marad iGPU, csak konnyebben hasznalhato lesz, mint most.
-
LordX
veterán
Semmi nem Neumann architektúra, amiben van i/d-cache, szuperskalár pipelineing, out-of-order execution, tehát gyakorlatilag bármi, amit 1995 óta csinálnak. Ezek ugyanis módosított Harward architektúra néven futnak.
Egyébként meg ott van a (nem-módosított) Harward architektúra, jeles példája az ARM-M chipek.
A Neumann-Harward különbség csak is és kizárólag önmódosító szoftvereknél probléma, csak ezeket kellene "újraírni", de ezek aránya jelenleg pontosan zéró.
-
Manbal
senior tag
szép meg jó dolgok ezek, de amíg nem növelik a memóriasávszélt 200 GB/s környékére a mai 30-35ös maximum helyett, addig ez xart sem fog érni... nem is értem miért nem lehet 512 bites memóriavezérlőket integrálni a procikhoz, miért kell még mindig jóval alacsonyabb sávszélen üzemeltetni a rendszermemóriákat, mikor a VGAkon már 300 GB/s sem lehetetlen...
-
Hat, a kulon dcache meg icache nem az a tipikus Neumann-architekturas cucc (ahogy az se nagyon illik bele a klasszikus modellbe, hogy a memoriat a CPU-n kivul egy rakat mas cucc is zargatja).
Mondjuk fogalmam sincs, hogy hogy jon ide ez a tema, hiszen gyakorlatilag arrol van szo, hogy azon igyekeznek, hogy a GPU ne egy kulso eszkoz legyen, hanem teljesen beleolvadjon a CPU-ba.
(#19) hokuszla: a GPU-t nem csak a jatekok tudjak kihasznalni
-
Abu85
HÁZIGAZDA
A hUMA/hQ, a HSA, illetve a Mantle lényegében a PC felzárkóztatása az új generációs konzolok képességeihez. Vagy ezt választják vagy a butított konzolportokat. A többi cég sajnos nem törődik a PC szoftveres gondjaival. Elfogadják úgy ahogy van.
Egyébként az AMD-től jöhetnek az OpenCL-es játékok ... 900 GFLOPS-os IGP-vel várják őket. Az a gond, hogy ez már nem segít, mert a konzolban nem csak átlagos integráció van, hanem mély integráció. Amit oda megírnak, azt még OpenCL-lel sem biztos, hogy futtatod PC-n. -
stratova
veterán
De ennek az informatikában semmi jelentősége, majd ha IBM, Intel és társaik kitalálnak valamit, akkor lehet rajta rágódni.
Biztosan azért fejlesztett megint AMD egy kicsit a GCN-en kihozva egy újabb csúcs-VGA-t (R9 290X/290), mert konzolosítani akarják a PC játékipart az APU-kkal.
-
#2
Borisz76
nagyúr
Teclis1993
#1
Borisz76
nagyúr
válasz
Teclis1993
#1
üzenetére
Ja....soha nem alszanak
Korán reggel, kómás fejjel, kávézás közben lettem okosabb.
-
#1
Teclis1993
tag
Teclis1993
tag
A srácok soha nem alszanak.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Pl a Kaveri IGP-jének az erejét lehet-e majd kamatoztatni pl. Bf4-ben hogy van mellette egy GCN arhitectúrás kártya? Jelen esetemben egy Kaveri APU-n jobban futna,mint a mostani FX-emen? Gondolkodom Váltani FM2+ vonalra,de
Ráadásul vannak olyan egzotikus design-ok is, amik sem Neumann, sem Harvard.
Új hozzászólás Aktív témák
- AMD Ryzen 5 7600X BOX - Új, 3 év garancia - Eladó!
- Intel Core i9-12900 OEM eladó ajándék hűtővel
- Intel Core i9-12900K 16-Core 3.2GHz LGA1700 (30M Cache, up to 5.20 GHz) Processzor!
- AMD Ryzen 7 5700X BOX - Új, 3 év garancia - Eladó!
- Amd ryzen 5950x + Msi x570s carbon wifi + Team Group 8Pack Edition 32GB samsung b die .
- HIBÁTLAN iPhone 12 Pro 256GB Graphite - 1 ÉV GARANCIA - Kártyafüggetlen, MS3283
- Bomba ár! Dell Latitude 7320 - i5-11GEN I 8GB I 256-512SSD I HDMI I 13,3" FHD I Cam I W11 I Gari!
- GYÖNYÖRŰ iPhone SE 2020 128GB Black -1 ÉV GARANCIA - Kártyafüggetlen, MS3291
- Okosóra felvásárlás!! Samsung Galaxy Watch 6, Samsung Galaxy Watch 7, Samsung Galaxy Watch Ultra
- GYÖNYÖRŰ iPhone 13 mini 128GB Red -1 ÉV GARANCIA - Kártyafüggetlen, MS2159
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest