egy ilyen kártya, akkor be tud segíteni a Cpu-nak, mint +61db x86 mag?
simán indíthatók rajta normál programok, taskok, stb?

"Egyedi vagy és megismételhetetlen! Csakúgy, mint bárki más!!!'" - 3Dmarkillers - hwbot.org

A 61 db magot hogyan sikerült kihozni?

Nem. Ez nem kompatibilis az x86-ra fordított alkalmazásokkal. A MIC legfontosabb változása a Larrabee projekthez képest, hogy megvágták a kompatibilitást az x86-tal.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Nem, ezt OpenCL-ben programozzák jellemzően.

kár, pedig most nagyon jól jött volna egy-két olyan kártya.. jövőben elképzelhető? vagy végleg feladták?

"Egyedi vagy és megismételhetetlen! Csakúgy, mint bárki más!!!'" - 3Dmarkillers - hwbot.org

Ezeknek a kártyáknak mi is a céljuk??? Otthoni felhasználónak van belőle haszna??

Mármint az x86-os gyorsító? Az kétséges. Az a baj, hogy az x86-ot sosem tervezték skálázhatóságra. Ahhoz, hogy működjön óriási cache kell a lapkába. Azt a helyet viszont a többiek feldolgozóra költik és beletervezik az ISA-ba az adatpárhuzamosságot. Szerintem az Intel is erre megy. Egyszerűen nincs értelme a termék értelmét a vezetőség x86 mániájával kivégezni.

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

pedig az nagy előny tudna lenni, hogy a meglévő programokat nem kell átírni!
főleg, ha pont olyan feladatról van szó, amit jól lehet párhuzamosítani.. ergo pusztán a "sokmagkártyával" lényegesen lehetne sokszorozni a sebességet..

"Egyedi vagy és megismételhetetlen! Csakúgy, mint bárki más!!!'" - 3Dmarkillers - hwbot.org

Az marketingblabla. Át kell írni a programot, hogy skálázódjon. Még a pár soros változás sem elég.

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Közeledünk, közeledünk

Galaxy S24 Ultra 1TB ||| ( •_•) ( •_•)>⌐■-■ (⌐■_■)

7120P 7120X között mi a különbség? Vagy én nem látom? Mert a 3xxx-es sorozat az oké, hogy miben változik az A és a P. De a P és az X.?!

"Ha egyedülállóval találkozunk, mindegy, mit mond, de biztos, hogy nem azért van egyedül, mert élvezi a magányt, hanem mert már megpróbált beilleszkedni a világba, de az emberek újra meg újra kiábrándítják."

Szerintem arra gondol, hogy ami jelenleg megy kód pl 1 - 64 procimagon, szinte lineáris skálázódással, azoknak ez jó lenne így önmagában is (nem kéne szerver lap, meg clustert építeni, hanem pár ilyen kártya egy gépbe), ha meglenne az x86 kompatibilitás továbbra is, és nem kéne átírni semmit a kódban.

Beteg

"It's not about having what you want, it's wanting what you've got."

EZZ beteg

a cuccból 4 rendel

Ha már opencl, egy ilyen vajon mit tudna egy opencl-es realtime rendernél, mondjuk egy nvidia quadro ellen?

Most ezekkel piszok gyorsan lehet pl videókat konvertálni meg renderelni?

△ Asrock X570M Pro4 △ AMD Ryzen 9 5950X ~ 4.4GHz - 1.248V +Corsair H115i PRO XT △ EVGA RTX 3090 FTW3 ULTRA GAMING 24GB (1950 MHz/20000MHz) - 0.950V △ G.SKILL 32GB KIT DDR4 3600MHz CL16 - 3600MHz △ Samsung EVO 970 M.2(500GB) +Samsung 980 PRO M.2(1TB) △ Samsung Odyssey G7 C27G75T ívelt 240Hz (27") △

De ez jobb, mint egy 7970 radeon gyorsításra?

A bortól bolondokat gondol az ember, DE A PÁLINKÁTÓL MEG IS CSINÁLJA!!!

Ha OpenCL-ben írsz valamit, akkor a MIC betartva a hardver speckó igényeit kb. olyan hatékonyságra képes, mint egy GCN. Ergo a GCN annyival erősebb, amennyivel nagyobb a számítási teljesítménye.

Igazából itt az lesz az érdekes, amikor natív C++ kódot lehet rajtuk önállóan futtatni. A GCN és a MIC is képes rá.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

kb pont annyi helyen nyerő a cuda mint a gcn. Sőt már kevesebb helyen

Troll (nemhivatalos definíció): az akinek véleménye nem tetszik nekünk/nem értünk vele egyet. (10-ből 9 fanboy ezt ajánlja) || Fanboy 8 in 1 (Intel, AMD, Nvidia, konzol, PC,+minden politikai oldal) hiszen "ahol nem mi vagyunk, ott az ellenség"

Jah, mint a Metro Last Light-ba mi? [link]

És itt még az advanced physx be sincs lőve, képzelhetnéd akkor milyen hátrányba lenne az AMD, ha az is be lett volna lőve.

Abu85: Annyira azért a 2033-ba se harmadolta az FPS értékeket, ez nem kicsit túlzás ami állítasz! Itt épp az SSAO eszi igazán a vasat!

[ Szerkesztve ]

△ Asrock X570M Pro4 △ AMD Ryzen 9 5950X ~ 4.4GHz - 1.248V +Corsair H115i PRO XT △ EVGA RTX 3090 FTW3 ULTRA GAMING 24GB (1950 MHz/20000MHz) - 0.950V △ G.SKILL 32GB KIT DDR4 3600MHz CL16 - 3600MHz △ Samsung EVO 970 M.2(500GB) +Samsung 980 PRO M.2(1TB) △ Samsung Odyssey G7 C27G75T ívelt 240Hz (27") △

SSAA-t akartam mondani, nah! Anélkül, már a 660 TI is veri a 7970GE-t egyébként... [link] Nemhiába, van új driver is NV részről, hiába van "kiherélve" a kepler driverek is kellene a VGA-k mellé. És itt is a 680-ból kiindulva 1,66x-os fps csökkenés volt. Harmadolni azért nem harmadolja az FPS-t.

A többit sztem itt: [link], csak, hogy ne OFF-oljunk itt.

[ Szerkesztve ]

△ Asrock X570M Pro4 △ AMD Ryzen 9 5950X ~ 4.4GHz - 1.248V +Corsair H115i PRO XT △ EVGA RTX 3090 FTW3 ULTRA GAMING 24GB (1950 MHz/20000MHz) - 0.950V △ G.SKILL 32GB KIT DDR4 3600MHz CL16 - 3600MHz △ Samsung EVO 970 M.2(500GB) +Samsung 980 PRO M.2(1TB) △ Samsung Odyssey G7 C27G75T ívelt 240Hz (27") △

Nem követem pontosan az ilyen gpgpu-szerű technológiákat, de néha elég kiábrándító dolgokat lehet látni (csakhogy a kedélyek kicsit csillapodjanak: prog.hu intel opencl 1.2
Pl:
"Hogy ne legyek elfogult, en idorol idore mindig kiprobalgatom az amdocl.dll-t, de hat az a baj, hogy nem valamelyik opencl sample appot akarom ujra megirni"
"i5 3570K-val kb megegyező (kicsit rosszab) sebességet tudok kihozni a Radeon 6870-ből"
"a ram az akkor is iszinyat lassu :S Probald megcsavarni ugy (ha egyaltalan lehetseges), hogy 1-et olvasol, 30-at matekozol."
"Sajna a GPU CPU uzemmodban hasznalva nagyon rossz"
Szerintem SW HW és tapasztalat terén is még van hova fejlődni. Nemtudom átlagfelhasználói szinten mikor lesz ebből nélkülözhetetlen dolog és általános elterjedtség (nyilván a xeon kezdetű dolgok pont nem is az átlagfelhasználónak születnek csak úgy általában mondom).

An open mind is like a fortress with its gates unbarred and unguarded.

Próbálkozzon APU-val, ahol a PCI Express késleltetés és sebessége nem lesz korlátozó tényező.

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

inkohézív, asszimetikus hulladék. inkább egy 16 magos amd, vagy tilera.

A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

Azert nem mindegy, hogy mennyire "nativ" az a C++ kod! Peldaul a CUDA kernelbe nem lehet STL konyvtarakat beinclude-olni (ergo a compiler ami a CUDA magok assembly-jere fordit nem kepes meg boldogulni mindazzal a generikus es egyeb nyelvi dologgal, ami ezzel jarna). Jol izolalt es jol korulhatarolt kerneleket tud futtatni. AMi szoftver architekturalisan nem feltetlenul gond.
Ha az Intel nem butitja el tulzottan az x86 architecturatol az MIC magokat, akkor annak pont az lehet az elonye, hogy a meglevo C++ compiler-ek optimalizalni tudnak rajuk meg mindig, es valoban _barmilyen_ (szo szerint) C++ kodot kepes futtatni.

Xeon Phi-nek ket esetben latom ertelmet:
1. Nagyon eros dupla lebego pontos szamitasu massziv parhuzamos feladatoknal. Az nVidia es az AMD is probal itt feljebb kapaszkodni, de mivel az MIC magok Pentium magok, es annak azert nem olyan rossz az FPU-ja, ezert a Xeon Phi-nek viszonylag jo DP FP teljesitmenye van. Nem veletlenul lattam valahol, hogy a marketing anyagokban ezt domboritjak ki.
2. Olyan parhuzamos feladatoknal, amiknel egy thread is meglehetosen komplex, azaz profitalhat a nagy cache-bol, Out-of-Order vegrehajtasbol, elagazas becslesbol es minden okossagbol, es az egyes vegrehajto egysegeknek kommunikalniuk is kell egymassal. Pl mesterseges intelligencia algoritmusok. Vagy minden olyan algoritmus, ami ugyan parhuzamosithato, de kicsit nyogve-nyelosen, es a GPUGPU architekturanal az MIC jobban fekszik neki.

[ Szerkesztve ]

Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz

Akkor innentől kezdve nem emelheti az egekbe az árát az intel, illetve lehet lesz hozzá support is. Bár a sok balga lehet megveszi akkor is ha nem kell, mert rajta a xeon matrica :-)

A bortól bolondokat gondol az ember, DE A PÁLINKÁTÓL MEG IS CSINÁLJA!!!

Azt kérdeztem mire valóak ezek a kártyák.....

Az megvan, hogy ezek in-order magok? (Gyakorlatilag egy módosított Atom, felturbózott vektor pipeline-al).

Én nem értem ezt a felizgulást a natív C++ kódra. Jó, megvan a fordító, lefordítottat a "bármilyen" C++ programodat a GPU-ra. Gratulálunk, kaptál egy olyan binárist, ami a CPU-s sebesség töredékét hozza. Mármint miután már leszámítottad a PCIe buszon történő adatmozgatást is.

Semmilyen "natív" C++ program nem tartalmaz adatpárhuzamosítást, egy masszívan párhuzamos C++ program is bőven 50 szál alatt van (ami már overkill lenne egy CPU-ra). Egy ilyen Xenon Phi-nek minimum 240 szálra (=60*4) van szüksége, de inkább 1000-re. Adatpárhuzamos szálakra, tehát mindegyiknek tökéletesen ugyanazt kell csinálnia szinkronizálva (blokkonként, azaz pl. 386 szálanként).

Task-parallel világból data-parallel világba az áttérés nem kis módosítás, gyakorlatilag nulláról kell újrakezdeni mindent. Ami érdekes a C++-ban, az az absztrakció szintje, ami hiányzott eddig a GPU programozásból - erre (jelenleg még csak Windowson) megoldás a C++AMP: Működik, C++, GPU-ra is fordul. Az Intel gőzerővel dolgozik a Linux porton. Megjegyezendő, hogy ott se lehet pl. STL-t használni, egy hasonló, de teljesen más szemantikájú fejléckészletet kell használni.

TL: DR: le lehet fordítani, hogy fusson, de abszolúte semmi értelme.

[ Szerkesztve ]

Hat az nem volt meg nekem, hogy ezek ennyire buta in-order magok. En egy korabbi tervre emlekeztem, ahol Pentium magokat hasznaltak (volna).

Felizgulas a C++ kodra: pedig te is peddzegeted a dolgot. "teljesen más szemantikájú fejléckészletet kell használni" - namost ha x86-os magok lennenek, akkor a meglevo x86-os kompilerek miatt nem lennenek ilyen korlatozasok. _Tenylegesen_, _valoban_ azt futtathatnal, amit akarsz, mert a kompiler le tudna forditani.

Ez igenis tenyezo lehet olyan esetben, ha mar van egy eleve multi-thread-es programod egy masszivan parhuzamosithato feladatra (tehat a kododat korlatozza az, hogy pl csak 8 szalon futhat, futhatna akar 200-on is). Viszont a kodod hasznal ilyen-olyan konyvtarakat. Tehat igazabol van egy kerneled, de nem felel meg meg a CUDA kovetelmenyeknek sem. Nem feltetlenul egyszeru megfosztani ezt a kodot a konyvtaraktol. (Gyakorlatilag implementalod a konyvtar azon reszet, amit hasznalsz).

240 vagy 1000 szal nagy feladatoknal, adatmennyisegnem nem gond, megvan az.
Itt a task parallel dolgot nem kevernem most ide. A lenyeg, hogy van egy kerneled, de az komplex.
Mondjuk itt most eppen nem is mesterseges intelligenci algoritmusokra gondolok, azok esetleg bonyolultabbak lehetnek. Bar nyilvan ott sem lehetetlen, lattam en olyan implementaciot, amit Python-ban irtak, a Python-hoz van olyan konyvtar, amivel CUDA-t is meg tudsz hajtani.

Az STL-t csak peldakent irtam.

C++ AMP-hez ovatosan allok hozza, meg nem probaltam ki, nyar vege fele lesz idom talan. Azt orommel hallom, hogy Linux-on is dolgoznak rajta. Van meg mas hasonlo szoftveres megoldas is egyebkent.

Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz

"Itt a task parallel dolgot nem kevernem most ide."

Pedig pont hogy ez a probléma, CPU-ra task parallel módon párhuzamosítasz, GPU-ra data parallel módon. Teljesen más hozzáállást igényel a kettő, és ezért nincs semmi értelme annak, hogy meglevő C++ kódot akarjon valaki felhasználni. Attól még jó dolog lenne egy C++-szerű nyelven data parallel programozni (de nem "natív" C++-ban): Ilyen a C++AMP és tegnap nézegettem az AMD OpenCL C++-át, az is jó irány. Csak az egyik Windowshoz kötött, a másik meg Radeonokhoz..

1. Ki a loturo akarna C++ "szeru" programnyelven data parallel programozni, ha lehetne C++-ban is?
2. Mar miert ne lehetne data parallel programot irno C++ SMP architecturara??? Pont errol szol a Xeon Phi is, olvasd el amit irtam. Eredetileg pl dupla pontossagu lebego pontos teljesitmenye osszemerheto volt a GPGPU FLOP-javal. Igen is van (volt?) letjogosultsaga. Persze a piac majd eldonti vegul. Meg nemtom akkor vegul mennyire butitottak le. Az Atom magok kicsit lelomboznak.

Az OpenCL-ben pedig jo, hogy platform fuggetlen (AMD vs nVidia vs others), nade az egesz kerneled egy stringben van? (igy kuldod el leforditani, mondjuk tudom, hogy a leforditott kernel cache-elheto. Nade egy stringben van a kernel????)

C++ AMP-tol annyira nem vagyok felvillanyozva eddig meg, habar nem probaltam. Pont ezaz, hogy merni szeretnek majd, hogy mennyit tud a nativ CUDA-hoz kepest.

Van itt meg hova fejlodni.

[ Szerkesztve ]

Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz

a data paraller kifejezés csak egy üres lózung, amivel a gpgpu hívei próbálják magukat nyugtatgatni, mikor észreveszik, hogy nem lehet a hulladékukra valódi szoftvert írni. lehet azt, csak DATA PARALLER <- így nyugtatgatják magukat. mint mikor a német katonák a titkos, láthatatlan csodafegyvert cipelik.

A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

1, Ha lehetne, akkor senki. De nem lehet hatékonyan. A C++AMP 100% C++ szintaxis, csak a függvénykönyvtárak mások (és próbál minél jobban hasonlítani az STL-re).

2, SMP-re lehet data parallel programot fordítani, miért ne lehetne? Sőt, single processzorra is lehet írni, max nem lesz gyorsabb, mint a natív megvalósítás Fordítva van a probléma. Egyszerűen azért, mert a GPU-ban úgy vannak a végrehajtó egységek, hogy (pl.) 32 darabonként van egy darab közös vezérlőegység. Tehát 32 szálanként egy adott órajel alatt pontosan ugyanazon utasítás hajtódik végre mind a 32 szálon, nem működik az, mint SMP esetében, hogy egyik szállal ezt, másikkal azt csinálom. Egy standard SMP esetében ha van 32 darab végrehajtó egységed (processzorod..), akkor az 32 különböző dolgot csinálhat. (sőt, fog csinálni, mert még processzoron belül is gyakorlatilag kivitelezhetetlen az utasítás szintű szinkronizálás.)

3, Mert miben legyen, a C++ is egy textfájlban van, mielőtt lefordítod. A probléma az, hogy nem fordíthatsz máshol, csak a kliens gépén.

2.) Pont azt magyarazod, hogy miert lehet letjogosultsaga egy ilyen many-core x86-os architekturanak. A 32-es warp size miatt ha a thread-ek futasi ideje nagyon kulonbozo, akkor az nagyon betehet az ossz teljesitmenynek a GPU-nal. Vegyunk peldaul egy kepfeldolgozasi algoritmust, ami maszkolt, azaz a kep csak bizonyos reszeire kell lefuttatni, es ezek a reszek amorfak. Namost egy data parallel algoritmust siman raszabaditok 8 magra, ugy ahogy van, ezek szepen kiszamolnak minden, ha valamelyik pixel es kornyezete hatarertek alatti, akkor nyomul a kovetkezore. Ellenben a GPU nagyon megszivhatja. Most csak emiatt strukturaljam at az adatot? De az egesz tili-tolival nagyon elmegy az ido. Mar az adat mozgatas a GPU es a rendszer kozott is problema, es ezt meg meg kene fejelni megegyszer annyival, hogy atrendezgessek, hogy a GPU-nak kegyeskedjen jo lenni a bemenet.

(Azt is tegyuk hozza, hogy a legujabb generacios nVidia GPU-knak mar fejletteb utemezoje van es ilyen kiegyensulyozatlan feladatok eseten jobban teljesitenek, de nekem meg nincs ilyen kartyam).

(Meg azt is tegyuk hozza, hogy az AMD legujabb tervezett APU-inal pedig az adat mozgatas a CPU es a GPU kozott nem lesz gond, mivel nem lesz szukseg ra, mert mindketto ugyanazt a kozos cimteret es GDDR5 memoriat latja majd.)

3.) Varjunk azert. Egy darab string tipusu valtozo, karakter halmaz egy fajlon belul != maga a text fajl. Az a C++ text fajl az IDE-ben megnyitva syntax highlight-olt, debuggolod, sorokra ugrassz, stb. Mig egy stringbe belehanyva az egesz source... hat... nem kis kulonbseg van. Pl a syntax highlight esetleg felesleges funkcionak tunhet, de valojaban nagyon sokat jelent ahhoz, hogy jobban atlassad a kodot es konnyebben eszrevedd a hibakat. Majdnem erre megy ki az egesz jatek, hogy kikuszoboljuk a hibakat, amiket vetunk! Minden lepes szamit ehhez.

Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz

Nem az adatot kell átstrukturálni, hanem az algoritmust. Akárhogy is, a natív megoldás még ha le is fordul, nem lesz gyorsabb. Lehet, hogy e miatt jó lehetne a many-core x86, de ha sok CPU mag kell, tegyél a gépbe sok CPU-t. Ezek a kártyák sose akartak mást, mint amit tudnak, ha programozni akarod őket, azt úgy kell csinálni, hogy nekik jó legyen.

Nem tudom te milyen IDE-t használsz, de mind a Visual Studio és az Eclipse is .cl fájlban is highlightol, és debuggolni is tudom (bár ez utóbbi erősen SDK függő).. A szögnél bonyolultabb kódokat amúgy is ki kell szervezni külön fájlba, gyakorlatilag semmi sincs .cpp forrásban idézőjelek között.

Nem veszed számításba, hogy az x86 nem skálázhatóságra épített ISA. Amikor tervezték, akkor sosem merült fel, hogy lesz többmagos korszak. Ezért módosították a MIC-ben, mert a hagyományos x86 nem skálázódik jól egy bizonyos szint után, a változásokkal viszont megszűnt a bináris kompatibilitás, de ez mindegy is. A jelenlegi MIC-ben a rendszer úgy skálázódik megfelelően, ha a magok által futtatott feladathoz az adat ott van a magokhoz rendelt L2 cache-ben. Ha a memóriába kell menni érte, akkor sokat veszít a rendszer. Ezért van a Knights Cornerben 30+ MB L2 cache, miközben a többi GPU-ban 1 MB körüli L2 van, de csak azért, mert az ISA-ba beletervezték a skálázhatóságot. Ez az oka annak is, hogy az AMD és az NV, illetve a többi GPU fejlesztő cég 3-4-5 évente kompletten lecseréli az ISA-t. Ezek nem olyan hardverek, hogy évtizedekig lehet ugyanahhoz az ISA-hoz ragaszkodni. Lehet, csak nem fog skálázódni.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Mindenki tudja, mire gondolt, de egy ehhez hasonló hw nem lenne jó arra. Teljesen beállna az egész.

(#50) Pikari: Az nem lehet, hogy csak neked nem sikerült, azért vagy ilyen frusztrált?

Azt kellene már megérteni, hogy CPU alapon sokkal nagyobb fogyasztással lehetne kihozni hasonló számítási teljesítményt.

Koszi egyebkent a "vitat", eszmecseret.
Szandekosan helyezkedtem egy kicsit a kartya oldalara, es probaltam felhozni erveket mellette. Vegul ugyos a piac dont. A CUDA miatt meg amugy is at kell strukturalni kicsit a programot. Ami architekturalisan az elonyere is valik, hogyha nem olyan bonyolult az akernel es nem include-ol be foloslegesen dolgokat.

Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz

Igaz, sajnos a skalazodas az problema lehet. Ezen javithat az, hogyha a feladat szerencses, es nagy CPU de keves memoria mozgatasi igenyu. De ez ritka. x86-nal Intel eseteben a QPI segitene (bizonyos feladatoknal), de a Phi-ben nincsen QPI.
A savszelesseg a GPU-knal is problema amugy, az nVidia cross-bar memoriat tervezett az AMD pedig ring buszt. (javitsd ki ha forditva van), mindkettonek megvan a maga elonye es hatranya.

Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz

Ezek a kártyák jók, mert első blikkre iszonyat teljesítményük van - céges gépemben van egy i7-i3667U, a benne levő értékelhetetlenül hipergyenge HD4000 is 8-10x gyorsabban szoroz össze nagy (~3000x3000) mátrixokat. Viszont helyén kell kezelni őket, különben pofára esés lesz az egész - kis mátrixokra (~8x8) már lekörözi a proci, mert csak 64 szálat lehet indítani az eredmény kiszámolására, ami kevés.

Nem úgy tűnt, mintha mindenki tudná.
...és miért is állna be az egész rendszer? Anélkül, hogy tudnád, mit is kell számolni, te megmondod, hogy nem működne

Abu pl. tudta, ez a válaszából is kitűnik.

Nem csak én mondom meg. Szerinted miért hagyta ki az Intel az x86 kompatibilitást? És nyomatja hozzá az OpenCL-t?

De amúgy könnyű belátni:
- Egy 8 v. 16 procis, egyenként 8 v. 4 magos E5-46xx cluster össz-memóriasávszélessége ~400/600 GB/s, de ami fontosabb, összesen 2048/4096 biten! Alacsony késleltetésű DDR3-mal. Phi: 352 GB/s, 512 biten, nagyobb késleltetésű GDDR5-tel.
- A fenti clustereknél összesen 176MB L2+L3 áll rendelkezésre, a Phinél 31MB L2.
- A fenti clusterekben összesen több TB memória lehet, Phi: 8GB.
- A Phi magjai nem teljes értékű procimagok, valószínűleg nem annyira szeretik az ugribugrit, ráadásul in-orderesek. Ugyanakkor a hatékony kihasználásukhoz masszívan SIMD-ezett kódra van szükség.
- A clusternél nem kell, hogy különösebben össze legyenek hangolva a procik (még az egyes magok sem annyira), a Phinél azonban ez megkerülhetetlen.

Mert nem ideális _általában_. Viszont tudom mire akarná használni helkis, és oda ez tökéletes lenne.

Annál a feladatnál ~30MB adat van gyilkolás alatt, egy darab 4GHz-es Ivy maggal kb 5-6 perc egy lefutás, aminek az eredménye mindössze két darab double érték, viszont minimum 10.000 lefutás kell (de ha meglenne a szükséges teljesítmény, akkor ez milliárdos nagyságrend inkább), és ezek teljesen függetlenek. Gyanítom bőven elég lenne a memória méret és sávszélesség.

Ha általánosságban kijelented, hogy nem volt ideális az x86 ehhez, és azért kukázták, akkor egyetértek, de az adott feladat és a megvalósító x86-os kód ismerete nélkül nem kéne ilyet kijelenteni...

"de ami fontosabb, összesen 2048/4096 biten" Őőő... ha a sávszélességeket hasonlítgatod össze, akkor annak nem sok jelentősége van, hogy az adott sávszélesség hány bites busszal jön ki. Vagy szerinted 100MHz 128bit gyorsabb, mint 200MHz 64 bit? A késleltetésnek már inkább van szerepe (meg persze annak, hogy mekkora adatot akarsz átpréselni egyszerre az adott buszon).

Jó, de ez már nagyon speciális eset! Amúgy meg lehet tudni, hogy ez mi a "fene"?

A #2-esben normál programokat, taszkokat említett. Később is csak jól párhuzamosítható feladatokat, így a kettő együtt pl. renderelést sejtet.

Nem csak a sávszélességet hasonlítottam össze, mint láthatod, hiszen nem csak az számít. Pl. egy sok szálon futó, nem külön GPU-ra fejlesztett renderelés esetén, ahol az egyes szálak egymástól nagyrészt függetlenül dolgoznak, eltérő memóriahozzáférési patternnel, nagyon nem mindegy, hogy hány biten és csatornán érik el a ramot a magok. Ilyen esetben az 512 bites GDDR5 (neki megfelelő 5 GHz körüli effektív órajellel) sehol sincs a 32-64 csatornás, 2048/4096 bites DDR3-hoz képest (hiába csak ~2 GHz).

azért itt a gondolatmenetet még bonyolítja a random memory read kérdése, pontosabban az, hogy az algoritmusodnak mennyire van szűksége rá.

A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

Igen, bár a memóriahozzáférési patternbe ez is beleértendő.

Igen, spec eset, de nekünk pont ez van Ezért mondom, hogy általánosságban igaz amit írsz, de ebben a konkrét helyzetben nekünk jó lenne az x86 kompatibilitás.

Szerintem ez nincs feltétlenül így, de rendereléssel és hogy ott mi az előnyös, azzal nem foglalkozom, így inkább nem mennék bele.

szerintem igazából végső soron lényegtelen, hogy x86, arm, vagy mips. a linuxnak mindegy. a lényeg, hogy monolitikus legyen, hogy pthread_createval le tudja rakni a szoftvered a petéit.

A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

Ha az egész újra írható (és a költségvetésbe, időbe belefér), vagy még nincs meg, akkor mindegy, persze.

miért kéne újraírni? semmit sem kell újraírni, lefordítod és kész.

A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

Erm? Még mindig GPU-n futtatásról beszélsz?

már rég nem arról beszélünk, jóreggelt

A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.