2. Fórumok
  3. PC, mini PC, barebone, szerver
  4. Jönnek az új Xeon Phi gyorsítók
Keresés

Hirdetés

Új hozzászólás Aktív témák

  • #41 LordX veterán tocsa #38
    Új Válasz #41
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    LordX

    veterán

    válasz tocsa #38 üzenetére

    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 ]

  • #46 LordX veterán tocsa #45
    Új Válasz #46
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    LordX

    veterán

    válasz tocsa #45 üzenetére

    "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..

  • #50 Pikari őstag tocsa #49
    Új Válasz #50
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Pikari

    őstag

    válasz tocsa #49 üzenetére

    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.

  • #51 LordX veterán tocsa #49
    Új Válasz #51
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    LordX

    veterán

    válasz tocsa #49 üzenetére

    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 :U 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.

  • #53 LordX veterán tocsa #52
    Új Válasz #53
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    LordX

    veterán

    válasz tocsa #52 üzenetére

    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.

  • #54 Abu85 HÁZIGAZDA tocsa #52
    Új Válasz #54
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Abu85

    HÁZIGAZDA

    válasz tocsa #52 üzenetére

    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.

  • #64 LordX veterán tocsa #62
    Új Válasz #64
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    LordX

    veterán

    válasz tocsa #62 üzenetére

    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.

Új hozzászólás Aktív témák