- Kormányok / autós szimulátorok topicja
- Milyen videókártyát?
- Melyik tápegységet vegyem?
- Azonnali processzoros kérdések órája
- Megérkezett a Corsair új M.2-es SSD-je, és mindennek mondható, csak lassúnak nem
- Modern monitorokra köthető 3dfx Voodoo kártya a fészerből
- Hamarosan megjön a Samsung 360 Hz-es QD-OLED monitora
- HiFi műszaki szemmel - sztereó hangrendszerek
- Videós, mozgóképes topik
- Azonnali notebookos kérdések órája
Hirdetés
-
Enduro változatot kapott a Mobvoi TicWatch Pro 5
ma WearOS 3.5 rendszerrel és kettős FSTN és AMOLED kijelzővel érkezik az új modell.
-
Már nem hisz a nagy európai EV-forradalomban a Ford
it Meggondolta magát a Ford, a helyzetre való tekintettel 2030 után is kínálhat Európában hibrid és benzines autókat.
-
Spyra: akkus, nagynyomású, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
Új hozzászólás Aktív témák
-
dezz
nagyúr
Na hát erre mondják, hogy "elmész a fenébe!". Ennyire sík hülye nem lehet valaki (tehát valójában te sem vagy az), hogy még csak itt tartson, ennyi szájtépés után és úgy egyátalán. Ergo most biztonyítottad be, hogy csak egy troll vagy, aki azt élvezi, ha másokat idegesíthet, húzhat, rabolhatja az idejüket, miközben a figyelem középpontjában van.
Ez cseppet sem vicces, ugyanis:
Itt a bizonyíték: a netes trollok pszichopatákKeress fel egy jó orvost, amíg nem késő!
ui. és nem kompúter, hanem kompjúter, ha már így írod.
[ Szerkesztve ]
-
atti_2010
nagyúr
Azért ez már nekem hónapok óta feltűnt hogy minden AMD -s hírt negatívan kezel csak nem érdekelt, sokszor csodáltam is a kitartásotokat Abuval hogy meggyőzzétek.
1.Asrock FM2A88X+ Killer,A10-5800K,Kingston 2x4Gb 2400Mhz,Int X25-V SSD,SF Pro S.F.-450P14XE. 2.MSI-A75A-G55,A8-3870, Kingston 2x2GB2000, MSI R9-270, Zen 400.
-
Reggie0
félisten
Nem fogja kezelni a:
- halozatos dolgokat
- periferiakat: akkor a monitor mi?
- kitomoriteni a fajlokat -
dezz
nagyúr
válasz #32839680 #155 üzenetére
És a WinZIP nem is valami jó program. Vannak ilyen orosz ZIP/RAR jelszótörők, azok is kitömörítenek részeket és többszörös tempóban keresik a jelszót, mint akár egy komolyabb, többmagos CPU.
Számomra már az a gyanús, mennyire nem álltak még rá a GPGPU-sításra ott sem, ahol ez kézenfekvő lenne...
Érdekes módon, nem kommersz projektekben, ahol számítási teljesítményre van szükség és az Intel nem tudja rávenni a projektgazdákat, hogy inkább a drága CPU-it vegyék tucatszámra, jóval előrébb tartanak ezen a területen. Az AMD-t nem tudom, de az Nvidia jó üzletet csinál a Tesla szervereivel és munkaállomásaival. Az Intelnek is alkalmazkodnia kellett az igényekhez, így született meg a MIC alapú Xeon Phi, ami lényegében egy GPU szerű képződmény sok kis SIMD feldolgozásra kihegyezett CPU magból. A telj./fogy. előnyét csak az Intel gyártástechnológiai előnye tudja biztosítni, azonos technológiával a GPU-k lennének előnyben. (Kérdés, ez a jövőben hogy alakul majd, beéri-e a többi gyártó az Intelt gyártástechnológiában.) Mondani sem kell, a Teslák sem olcsók, de a Phik mégdrágábbak.
PC fronton addig marad a mostani helyzet, amíg az AMD-nek számottevő előnye van ezen a területen az Intellel szemben és a támogatás helyzetbe hozná az AMD-t. Azaz, már nem sokáig. De szerintem azt nem kell majd megvárni, amíg az Intel GPU-ban is kimondottan fölényben lesz, éppen elég, ha egálban vannak vagy csak kicsivel rosszabb az Intel (amit némi borítékozással ki lehet egyenlíteni, ami a céges gépparkokat illeti, az egyszeri userek pedig amúgy is az Intelt részesítik előnyben, még ha az AMD kicsivel jobb is éppen).
[ Szerkesztve ]
-
dezz
nagyúr
válasz #32839680 #157 üzenetére
Amennyire teheti, az AMD is igyekszik jobb pozíciókat kiharcolni HPC vonalon is. FirePro kártyák sora tolong a vevők kegyeiért, amik természetesen OpenCL-lel programozhatók. Valószínű a HSA koncepcióból sem maradnak ki teljesen. Mindeközben az APU-knak is van FirePro változata (kibővített supporttal az asztali változathoz képest), de eszük ágában sincs kukázni a komolyabb FirePro kártyákat emiatt.
[ Szerkesztve ]
-
dezz
nagyúr
-
dezz
nagyúr
Az lehet. Az OpenCL viszont platformfüggetlen. A HSA keretein belül pedig lehetőség lesz többek között C++-ban is programozni, vagy pl. C++ AMP-ban (később akár Javában is, bár ez nem feltétlen szempont a HPC-ben).
Bizonyos feladatokra egy komoly dGPU a legjobb választás, másokra egy APU, megint másokra pedig a kettő együtt. Lehet majd választani.
-
dezz
nagyúr
Legtöbbször nem számít, de előfordulnak más variációk is. Attól függően, rövidebb vagy hosszabb távú alkalmazásról van-e szó, stb.
(#163) morgyi: Abból a szempontból hasonlítanak, mindkettő C/C++ alapú (illetve a CUDA-nak van Fortran változata is), annak kiterjesztése. A fejlesztői környezet kiépítettségében viszont a CUDA vezet, az tény.
[ Szerkesztve ]
-
Jack@l
veterán
Látom savanyú a szőlő...
Mennyit dobott a gpu-s winzip a kitömörítésen?A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
-
Reggie0
félisten
-
Jack@l
veterán
Mindenkitől kérnék egy tippet, hogy a számítógéppel megoldható problémák, vagy teszemazt felhasználó programok mennyi részén használható az adatpárhuzamos implementáció.
Még azt is meg lehet tippelni, hogy mennyi olyan program lesz, amin az apuval a közös címteret használva érdemben gyorsabb lesz, mint mondjuk egy közepes gpgpu-val.Nem trollkodást kérek, válaszokat.
Kezdem is a második kérdésre(csak hogy ne befolyásoljam az elsőt):
- kép-video enkódolás
- stream titkosítás
- bazinagy mátrix műveletek
- file betömörítést csak azért félig írom be, mert 1 tömörítő nem tömörítő, ha rar meg 7zip is meg lesz oldva, akkor már elhiszem hogy derohadtjó erre is a gpu/apuA hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
-
dfdfdf
őstag
-
ukornel
aktív tag
Nocsak, jól értem, hogy az "APUk kiröhögésétől" eljutottunk odáig, hogy magad kezded összeírni, hogy hol lesz gyorsabb az APU a dGPUnál?
A listádból már önmagában csak a nagy mátrixokkal végzett műveletek miatt is megérné az APUkba fektetni, hiszen az erős vasat igénylő ipari és tudományos számítások (végeselem-szimulációk, Monte Carlo, időjárás-modellezés stb) mind ezen alapulnak.
Az sem véletlen, hogy az AMD az APU13 rendezvényen a Berlin APUt (szóval a Kaverit) olajkutatásokkal is reklámozta.
Ezekhez kell a póver, nem a perifériákra meg a win bebútolására...[ Szerkesztve ]
-
atti_2010
nagyúr
-
dezz
nagyúr
"Nem trollkodást kérek, válaszokat."
Mondja ezt (az eddigiek mellett) egy olyan indítással, hogy "vagy teszemazt felhasználó programok mennyi részén használható az adatpárhuzamos implementáció.", amire nyilván azt a választ akarja hallani, hogy csak egy kisebb része. Ami igaz is, csakhogy ezek fontos programok. (Közben azt sem tudja, hogy nem "felhasználó programok", hanem felhasználói programok.)
Fel kellene fogni, hogy egy APU sokkal több helyen alkalmazható, mint egy dGPU, aminek át kell tolni az adatokat egy relatíve lassú buszon, hogy aztán nekiállhasson (a mai rendszerben ez a nekiállás is lassú) szüttyögni vele, majd az eredményeket tolhatja vissza ugyanazon a buszon, és így tovább. Az APU-nál akár egy időben dolgozhat ugyanazokon az adatokon a kettő és nagyon gyorsan csereberélhetik az adatokat. Ennél mélyebbre nem megyek, úgysem értenéd (mint azt eddig bizonyítottad).
Kb. mindazokban a programokban bevethető az APU, amik viszonylag jól skálázódnak több/sok CPU magra. Főleg, ha még eleve SIMD-esítettek is. Renderelés, tömörítés, videoszerkesztés és enkódolás, képszerkesztés és -feldolgozás, networking, víruskeresés, játékok (most csak úgy végigszaladtam a szokásos teszt-meneten).
Ebben a teszt-cikkben láthatsz egy pár példát láthatsz arra, amikor már a Llano is sokkal gyorsabb volt (értsd: 20-50x gyorsulás!), mint ugyanazt CPU-ból elvégezve. (Némely esetben a mellé tett HD7950-nel sem teljesített jobban.) És hol volt ekkor még a HSA?
-
Jack@l
veterán
Félreérterrrél ,azt írtam, hol lehet gyorsabb. nem azt hogy konkrétan gyorsabb is lesz... (inkább ilyen van esélye gyorsabbnak lenni feltételezés) Időjárást meg nem egy csóró apu-n fognak modellezni, ezt azért te is tudod.
---
Többiek:
Látom azóta se nagyon gyülnek a tippek, pedig kiváncsi lettem volna ki mennyire merész.A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
-
Reggie0
félisten
Mivel a problemak szama nem veges, igy nem egyszeru valaszolni a kerdesre. Az biztos, hogy a nem parhuzamosithato problemak aranya elegge alacsony. Meg a pascal haromszog szamitasat is sikerult parhuzamositani, pedig latszolag egy abszoluit szekvencialis feladat.
Lenyegeben minden olyan alkalmazas, ahol vannak tombmuveletek mar nagy valoszinuseggel gyorsabban futnanak gpgpun. Marpedig ez nem egy ritka dolog. -
Abu85
HÁZIGAZDA
Én főleg a játékfejlesztők előadásait és véleményét ismerem. Ezeket az eseményeket is követem. Azt le tudom írni, hogy miket készítenek a HSA-féle koncepciókra (nem pont HSA-ra, csak az efféle rendszerekre ... OpenCL 2.0 pl., de főleg next-gen konzol).
Új hangmotor koncepció: Bevonja a feldolgozásba a CPU-t, az IGP-t és a dedikált hangprocesszort (ACP). A CPU úgymond az etető, kiadja a feladatot az ACP-nek és az IGP-nek. Az ACP a kodeket kezeli, és információt ad a CPU-nak az IGP menedzselésére. Az IGP a számításigényes feladatokon dolgozik ... indirekt audió, ray casting az egyes jelenségek szimulálására, konvolúciós reverb valós idejű számítása a jelenet szerint.
Jelenetbe visszaíró GPGPU fizika: Az aktuális megoldásokkal ellentétben úgy számolna az IGP fizikát, hogy visszaírná még a jelenet számításába, hogy reagálhasson rá az AI, illetve része legyen a játékmenetnek. Ezzel a felhasználó ne csak egy vizuális dolgot kapjon, hanem egy játékmenetet teljesen befolyásoló feldolgozási modellt.
Hatékony rendezés még a jelenet szintjén: Mielőtt a grafika számítása megkezdődik azelőtt jellemzően szokás alkalmazni rendezést, hogy bizonyos elkerülhető számításokat a rendszer el se küldjön a grafikus hardvernek. Ezt ma a CPU végzi, de az IGP nagyon jó a rendezésekre. Ezeket direkten visszaírja a CPU memóriájába, így felszabadítja a CPU erőforrást, és még gyorsabban is megvan kivágási feladatokhoz a szükséges információ.
Frustum kivágás: Ezt ma a CPU végzi és nagyon fontos feladat, hiszen így töröljük ki a jelenet nagy, nem látható részét, mielőtt elmennének a parancsok a grafikus processzornak. A feladat rengeteg vektor matematikát használ és teljesen párhuzamosítható. Az eredményt a CPU azonnal megkaphatja, hiszen az IGP szimplán beleírja a gyorsítótárába.
Útkeresés: Egyre nagyobb világokat szimulálunk, így egyre több egységnek, NPC-nek, izébizének szükséges útkeresés. Ez a GPU-kon nagyon gyors, mert rengeteg szálat futtatnak. Egy GPU szál egy NPC, egység, izébizé útkeresését megoldja, és a CPU memóriájába direkten vissza lehet írni a megtalált útvonalat. A konzolokban ez egy nagyon hasznos funkció. A PS3-ban az SPU-kat nagyon használták erre és azért olyan zseniális a Naughty Dog játékokban az AI, mert megvolt hozzá a számítás kapacitás. Sokan azt hiszik, hogy az AI programozási tehetség kérdése. Valójában inkább számítási kapacitás nincs ahhoz, hogy jó legyen. Az új konzolokban az IGP statikusan particionálható, így ki lehet vágni egy bizonyos számítási kapacitást erre a feladatra. Ha egy CU-t kivágsz, akkor az máris 256 útkeresésre ad lehetőséget.
Tartalomkikódolás: A játékokat ma jellemzően tömörített tartalmakkal szállítják. Azért, hogy kevés helyet foglaljanak, noha így sem kicsik. Ezeket a tartalmakat a program az adott pálya betöltésénél kódolja ki, méghozzá a processzormagokon. De mivel az a cél, hogy inkább elimináljuk a töltőképernyőket, így a CPU-t nem célszerű erre használni. A GPU rengeteg dekódolási feladatban sokkal gyorsabb, így real-time megcsinálható az egész. A rendszermemóriába az eredményt direkten bele lehet írni. Tulajdonképpen a koncepció, hogy a játékot töltőképernyők nélkül végig lehessen vinni.
Mozgásanimáció fejlesztése: Ez is egy érdekes terület. A grafikus processzorban van elég számítási kapacitás, hogy jóval folyamatosabb mozgásanimációk szülessenek. Ez tipikusan egy mocap vs. számolt dolog. A mocap reális dolog bizonyos játékoknál, de behatárolja a mozgáskultúrát. Ezért a számolt animáció jóval kötetlenebb, így több programban is ezt használják, de ez darabos mozgást eredményez, mert hiányzik a jó minőséghez a számítási kapacitás.Mielőtt jönne a kérdés, hogy hogyan lesz erre az IGP-ben számítási kapacitás elárulom, hogy asszinkron compute képességgel. Ma szinte minden program szinkron feldolgozást használ, vagyis a jellemző GPU kihasználás nincs 40-60% felett. Azokat a kihasználatlan ALU-kat asszinkron feldolgozással be lehet fogni. A PS4 nemrég kapta meg erre az API frissítést, így az új játékok már kihasználhatják. Az új Infamous: SS ki is használja. Az eredménye, hogy az amúgy 4 ms-ot igénylő particle rendszer ingyenes lett. Semmi hatása nincs a teljesítményre, mert a shadow mapok számításával párhuzamosan végzik, tehát akkor történik a számítás, amikor az ALU-k amúgy pihennének.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
atti_2010
nagyúr
Inkább az jellemző a Mantle -ra hogy a min FPS megnő és egy közép tartományban stabilan megy a játék (BF4), most elméletileg 4GB RAM sokat dob a helyzeten de ezt nem tudtam kipróbálni.
1.Asrock FM2A88X+ Killer,A10-5800K,Kingston 2x4Gb 2400Mhz,Int X25-V SSD,SF Pro S.F.-450P14XE. 2.MSI-A75A-G55,A8-3870, Kingston 2x2GB2000, MSI R9-270, Zen 400.
-
Abu85
HÁZIGAZDA
Nem. 100%-on szinte sosem teker. A 70% a max, amit ma elérnek az API-kban.
(#179) dezz: Az oka egyszerű. A GPU igazából egy heterogén módon programozható processzor. Vannak multiprocesszorai, de mellette még egy rakás másmilyen feldolgozó. Mivel a parancsok szinkronban érkeznek, ráadásul úgy, hogy egymás után ugyanazt a feladatot futtatják, így a parancsok által jellemzően terhelt részegység lesz használva, míg a többi pihen.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
dezz
nagyúr
(Az első két mondatban foglaltakat természetesen tudom.) Ha jól értem a harmadikat, nem optimális arányban jönnek a parancsok (v. feladatok), tehát amilyen arányban állnak egymással a különböző fajta egységek. Ez a shader compiler hiányossága vagy arról van szó, hogy pl. nem tudja az adott TMU kiszoltálni az összes hozzá tartozó CU-t?
Olyanról nincs szó, hogy pl. nincsenek teljes szélességben kihasználva a SIMD egységek a CU-kban? Azaz, nem eléggé vektorizált a kód. Ami vagy szintén a shader compiler hibája, vagy elméletileg sem lehet jobb. Az utóbbi esetben nincs mit tenni, hiszen a kihasználatlan "rekeszek" (1-1 SIMD egységen belül) nem hajthatnak végre más utasítást.
-
Szerintem arra gondol, hogy a render-futószalag sorosan végrehajtott fázisainak az egyes részegységekre gyakorolt különböző arányú terhelése miatt messze nem optimális a kihasználtság.
Buta példa: legyen mondjuk 3 fázis, illetve X, Y, Z részegység:
1. fázis: X 100%, Y 70%, Z 50%
2. fázis: X 0%, Y 0%, Z 100%
3. fázis: X 50%, Y 100%, Z 30%Látható, hogy a 2. fázisban a GPU nagy része nem működik. A 2. és 3. fázis simán futhatna egyszerre, de mivel szinkron módon adod ki a különböző parancsokat, ez nem fog menni.
[ Szerkesztve ]
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
ukornel
aktív tag
"Félreérterrrél ,azt írtam, hol lehet gyorsabb. nem azt hogy konkrétan gyorsabb is lesz... (inkább ilyen van esélye gyorsabbnak lenni feltételezés)"
Számos alkalmazásban már bebizonyosodott, hogy jóval gyorsabb. Nem csak a jövőről beszélünk tehát, hanem a jelenről is.
Van amiben biztosra lehet venni, hogy gyorsabb lesz. Van amiben pedig jó az esély, hogy gyorsabb lesz."Időjárást meg nem egy csóró apu-n fognak modellezni, ezt azért te is tudod."
Egy??!??!!? Inkább száz, vagy ezer!
Az időjárás-modellezéshez egy Xeon, egy Power7+, vagy akár egy Tesla is "csóró". Sok ilyet rendeznek fürtökbe, hogy értékelhető sebességet és pontosságot érjenek el. Nyilván a Berlin APU kapcsán emlegetett geológiai számítások sem egy árva APUt vennének igénybe.
Ugye, hogy a PowerPC A2 is milyen "csóró" kis proci. Mégis ebből épültek a Blue Gene szuperszámítógépek - például időjárás modellezésre.
Különben, nagyon beszédes ez a "csóró" elszólásod, és kezdem sejteni, honnan fúj a szél. Úgy tűnik, hogy a te fejedben az APU = AMD, ami úgymond egyenlő a max négy maggal, gyengébb IPC-vel, alacsonyabb egyszálas teljesítménnyel (Bulldozer széria), illetve a korlátozott órajelekkel és IGP-vel (Kabini széria). Ez egy vérpistikének vállalhatatlan kategória. Pedig az APU nem a magok számától, az órajelektől, vagy a benchmark eredményektől az, ami.
Valójában az Intel is APUkat ad el, csak nem használja ezt az elnevezést, mint marketingeszközt.
A különbség, hogy az AMD előrébb jár az integrációban, hogy a sok kis grafikus mag valóban a procit gyorsítsa, és ne csak integrált grafikus egységként szolgáljon. Egyelőre érlelik a koncepciót és igyekeznek megteremteni a szoftveres beágyazottságot. Ha ez megvan, és beválik, és főleg, ha ráharap a piac, akkor előrukkolhatn(án)ak akár 4-500 mm2-es lapkafelületű, lehengerlő teljesítményű APUkkal is, de addig minek? Addig marad a "csóró", 100-250 mm2-es lapkákon való kísérletezés, ami előreviszi a koncepciót, mélyíti az integrációt, fejleszti a feature-öket. Még ha ettől vérpistikének le is lohad az e-pénisze."Látom azóta se nagyon gyülnek a tippek, pedig kiváncsi lettem volna ki mennyire merész."
Azok után, hogy elengeded mások mondadóját a füled mellett és mellébeszélsz, ne csodálkozz, hogy ignorálnak. Épp eléggé rászolgáltál. Ahhoz képest elég sok példát összegyűjtöttek.
Figyelmen kívül hagytad azt is, amit én írtam a nagy mátrixokkal végzett műveletek kapcsán. Az én részemről is érik az az "IGNORE".morgyi
"Pont ezért ha már csak egyedül az összes professzionális program közül a Matlabot és a Toolkitjeit átírnák HSA-ra (álom édes álom...) sok kutató és műszaki ember imákba foglalná az AMD nevét"Jónak mondod, mert én pont Matlabot használok napi szinten; nyígtam is már emiatt a fórumon :-)
-
Jack@l
veterán
Amit mondani akartam, az az, hogy biztos korszakalkotó az irány, de ha emiatt a prcesszor magok felét megnyírbálják, akkor lesz egy "szuper" igp a procidban, ami mondjuk gyorsít a programjaid kb 5%-ban, meg lesz egy fele akkor procid, ami viszont a maradék programodban jókora lassulást fog okozni. Erre a több kicsi 1,6 ghz-es cpu magok még jobban rátesznek minuszban, amit újdonságként kitalkált mostanában az amd.
Emiatt nekem van egy kis nézeteltérésem az amd-s iránnyal, (vagy bármelyik másikkal aki ugyanezt erölteti) de örülök hogy ti ezt előrelépésnek látjátok.
[ Szerkesztve ]
A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
-
dezz
nagyúr
Vedd észre, hogy az Intel iránya is ez a mainstreamben. Őket is szorongatja az energiatakarékosság és a fizika, így ők sem tudnak már túl sokat felmutatni a CPU erő növelésében. Pár százalék teljesítménytöbbletért senki sem vesz új procit, így ha nem akarnak visszaeső eladásokat, más irányban kell javítaniuk a teljesítményt, és ez a computing.
Azt is vedd észre, hogy kétféle felhasználói program van: 1. aminek nem vagy alig számít a számítási teljesítmény, 2. aminek nagyon is. Az utóbbiak nagyobb része már ma is többszálúsított és/vagy SIMD-esített (SSEx/AVX), azaz párhuzamosítottak, így jelentős részüket át lehet vinni GPU-ra is.
Azt értsd meg, hogy egy mai GPU nagy részét sok egyszerű processzor-mag teszi ki (GCN esetén Compute Unit - mellesleg az AMD a CPU modulokat is így hívja), széles SIMD egységekkel. (Mindez ki van egészítve pár célorientált egységgel és dGPU esetén több memóriavezérlővel.)
Valami hasonló már egyszer megtörtént, amikor nem lehetett gazdaságosan nagyobb mértékben növelni az egyszálas teljesítményt, és ezért bevezették a több magot. De CPU magok számát sem érdemes sokáig növelni, akkor már jobb egy GPU.
-
ukornel
aktív tag
Az Intel a maga óriási büdzséjével generációnként 7-12%-okat tudott előrelépni az utóbbi időben. Az AMD-nek ennél jelentősen nagyobb lépésekben kellene fejlődnie, hogy megelőzze, de bebizonyosodott, hogy a hagyományos módon ez nem megy.
Én magam is kíváncsi lennék, mit tudnának kihozni a Vishera utódjaként, 8 Steamroller maggal, mondjuk 28mm-es FD-SOIn. Lehet, hogy összehoznának megint egy procit, ami a csúcs 4 magos Haswellt veri bizonyos programokban, átlagban azonban inkább az Ivy szintjén lenne, egy szálon meg a 2500K szintjét ütné meg. Borítékolható lenne egy ilyen proci fogadtatása - és hatása az AMD üzleti eredményére. Egy ilyen komplex, nagy és drága rétegtermék kifejlesztése jókora szeletet kihasítana büdzséből, az AMD-fanok örülnének, de magukban talán kételkednének, hogy tényleg ezt akarták-e? A többség meg megállapítaná, hogy az AMD-nek most se sikerült, és a veszteségek tovább nőnének.
Erről az irányról le kellett térni.Nem igaz, hogy egy négymagos APU visszalépés egy négymagos korábbi procihoz képest. A magok számának feltornászása pedig nem jött be.
A heterogén irányban benne van a nem 10%-os, hanem akár 10x-es gyorsulás is potenciálisan.
Igen, kompromisszumokat igényel a lapka tervezése során, mert a sok grafikus számoló nagy helyet foglal. De könyörgöm, mire nem elég négy mag? A felhasználók által használt programok 5%-ára?
Egy Richland, Kaveri a HT-s i3-ak szintjén van és a legtöbb otthoni felhasználó igényeit jócskán túlszárnyalja - arra egy Bay Trail vagy egy Kabini is elég, sokkal kedvezőbb fogyasztási- és költségkarakterisztikával. Ezek a maguk helyén mind előrelépésnek számítanak. Teljesítményre meg a HSA-val készül az AMD.
A benchmarhuszároknak átmenetileg biztosan csak az Intel marad. Meg persze az AMD-s topikok telefikázása.[ Szerkesztve ]
-
dfdfdf
őstag
Köszönöm nektek: ukornel, dezz, Abu85 rengeteget tanultam tőletek most is! Csak arra lennék kíváncsi hogy mennyi munkába, időbe került ezt a tudást megszereznetek Nem érzem magam hülyének de néha a cikkeket, HSZeket olvasva googléznem kell szégyen szemre hogy megértsem miről is van szó. Pedig engem a programozás nem érdekel egyáltalán (megszerettették velem a turbo pascallal...) de úgy érzem hogy ezeket a problémákat, fejlesztéseket,jövőképeket meg kell értenem hogy nagyjából tisztában legyek a "jövővel".
-
dfdfdf
őstag
válasz #32839680 #192 üzenetére
Nekem a matektanárom volt ilyen órán 2+2 volt a feladat és dogában meg gyökvonás a holdon szorozva harcoló német alakulattal volt... többször buktam matekból. Azután új tanárt kaptam aki olyan "buta" volt hogy 6 diplomája volt és 2őt csinált tanítás mellett. Nah ő tudott tanítani de írtó kemény volt annyira hogy 4ikban félévkor 2es lettem matekból éppen-hogy de az érettségim kisujjból 78%os lett, Infón meg inkább a tanárom(szervizes) , sulim, tanáraim saját gépeit raktam rendbe. Olyannyira jól ment a "bolt" hogy óra helyett neteztem a tanáriba. Elkaptak dohányzás közben a suli keményebb tanára mentem az igazgatóiba előadta a tanár a történetet igazgatónő kikülte utána és beszélgettünk utána hogy a lánya gépét is meg kellene csinálni .
[ Módosította: radi8tor ]
-
dezz
nagyúr
"grafikus számoló"
Ne bizonytalanítsd el szegényt! A CU-k (Compute Unitok, esetünkben GCN alapú), mint nevük is mutatja, számító egységek. A grafikához annyi közük van, hogy a grafikai számítások általában jól párhuzamosíthatók (és persze az, hogy manapság még jobb híjján többnyire ezzel foglalkoznak), de bármi másra is használhatók, amire ugyanez (masszív párhuzamosíthatóság) jellemző. Ha nem lennének az IGP/GPU-ban olyan egységek, mint pl. a TMU (texture management unit), akkor valahogy úgy hívnánk, hogy vektor ko-processzor tömb.
(#191) dfdfdf: Köszi, akkor ma már nem fórumoztam hiába. De az ilyesmit azért jobb lenne offba tenni.
[ Szerkesztve ]
-
ukornel
aktív tag
Megtisztelő, amit írsz, köszi, de inkább ne tőlem tanulj, nem vagyok informatikus (bár tanultam valamennyit). A PH és más oldalak híreiből és a tényleg hozzáértők hozzászólásaiból lopkodom össze, ami a fejemben van, a köztes űrt pedig józan paraszti ésszel és fizikás intuícióval próbálom kitölteni (amivel azért mellé is lehet nyúlni).
dezz
Igazad van, nem grafikus számoló, bár arra is jó és egyelőre főleg arra használják[ Szerkesztve ]
Új hozzászólás Aktív témák
- Forza sorozat (Horizon/Motorsport)
- Főzőcskés topic
- Battlefield 2042
- gban: Ingyen kellene, de tegnapra
- Kormányok / autós szimulátorok topicja
- Megérkezett az új Nokia 3210 4G Magyarországra, ennyit kérnek érte
- Futás, futópályák
- Politika
- Kerékpárosok, bringások ide!
- Milyen légkondit a lakásba?
- További aktív témák...
- Intel I7 12700KF 14mag/20szál - Új, Tesztelt - Eladó! 85.000.-
- i3-8100 proci 4x3,6 ghz
- Beszámítás! Intel Core i7 4790 4mag 8szál processzor garanciával hibátlan működéssel
- Intel I5 14600K 14mag/20szál - Új, Tesztelt - Eladó! 98.000.-
- Beszámítás! Intel Core i9 9900K 8mag 16szál processzor garanciával hibátlan működéssel
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen