Keresés

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

  • hugo chávez

    aktív tag

    válasz dezz #24 üzenetére

    "bizonyos mértékig a HW felépítését is figyelembe kell venni."

    Na de az OpenCL-nél is ugyanúgy figyelembe kell venni, ha maximális hatékonyságot akarnak elérni.

    Mindenesetre szerintem az NV mindent meg fog próbálni, hogy "rávezesse" a LANL/DARPA/Sandia embereit, hogy jobban járnak a CUDA-val, mint az OpenCL-lel és szerintem sikerrel is fog járni, persze ennek nem örülök, mert én is inkább a nyílt és platformfüggetlen megoldások híve vagyok.

  • hugo chávez

    aktív tag

    válasz dezz #22 üzenetére

    "Cray rendszerekre hogy programoznak? C-ben, Fortranban (néhány éve még nagyban használták ezt matematikusok, fizikusok, nem tudom, most mi a helyzet) vagy valami spécibb?"

    C, C++, Fortran, illetve a védelmisek az Ada-t is használják.
    Programozási környezetnek meg leginkább saját cuccokat használnak, pl. "Cray Scientific and Math Libraries" [link], [link]
    Matlab-ot az Inteles, Quadro-s CX1-eknél használnak:[link]

    "Nehezen tudom elképzelni, hogy ezek most nekiálljanak CUDA-zni..."

    Hát, nekem nem úgy tűnik, hogy a C/C++-hoz képest olyan nagy különbség lenne: "Programmers use 'C for CUDA' (C with NVIDIA extensions and certain restrictions), compiled through a PathScale Open64 C compiler, to code algorithms for execution on the GPU." és CUDA C Programming Guide, de mivel, mint már írtam, semmit sem értek a programozáshoz, ezért nyugodtan javíts ki, ha nem jól gondolom.

    "Nem tudom, double prec.-ben most mi a helyzet, de peak single prec.-ben valami dupla számok vannak AMD oldalon."

    Cypress-nél 1/5-e a DPFPO/s a SPFPO/s-nek, Cayman-nál 1/4-e, Ferminél 1/2-e, számszerűsítve a teljes értékű Cayman-nál 2700/675 GFLOPS, a GF110-es Ferminél pedig 1580/790 GFLOPS és ugye a Ferminél még ott vannak az egyéb nyalánkságok: ECC, írható L2 cache, out of order thread block execution; stb. [link] (kár, hogy az AMD-nél nincs ilyen részletes "architecture whitepaper", legalábbis én sehol sem találtam).

  • hugo chávez

    aktív tag

    válasz dezz #15 üzenetére

    Tulajdonképpen arra akarok kilyukadni és a példák, amiket hoztam, is erre utalnak, hogy a hárombetűsek nem pusztán hardvert, hanem komplett HPC "környezetet" vásárolnak az adott cégtől, hardvert, operációs rendszert, felügyeleti és egyéb szoftvereket és ezek supportját, tehát nekik az szerintem lényegtelen, ha az NV esetleg ragaszkodik a CUDA-hoz és arra adja a maximális supportot. És ezen nem is csodálkozok, mármint, hogy ragaszkodik a CUDA-hoz, mert az Intel is be akar lépni a HPC-s GPGPU piacra, de, ha addigra sikerül eléggé elterjeszteni a CUDA-t, akkor az Intelnek még akkor is nehéz lesz labdába rúgnia, ha a Larrabee származékuk esetleg erősebbre sikerülne, mint az akkori NV GPGPU. Amúgy, most ugye arról beszél az NV, hogy processzormagokat is belepakol a következő generációs (GP)GPU-iba, szóval nem lennék meglepve, ha kidobnának egy saját operációs rendszert is (mondjuk, valami UNIX/Linux származékot összemixelnek a CUDA-val) és így már ők is komplett HPC környezetet tudnának kínálni, hasonlóan a Cray-hez.

    "De a legnagyobb poén az lenne, ha AMD GPU-kon gyorsabb lenne az OpenCL, mint Nvidián a CUDA."

    Hát, ha igaz, (és miért ne lenne igaz?) amit Abu és mások (többek között maga az NV is) írnak a Fermiről és utódairól, mármint, hogy kifejezetten a HPC/GPGPU követelményekhez tervezik őket (az NV CUDA Architecture-nek nevezi őket, ami azért elég sokatmondó :D ), akkor erre nem sok esély van, esetleg néhány olyan OpenCL-es progi lehet gyorsabb, amelyiknél csak a single precision FPO/s számít, mert ugye jelenleg ebben erősebbek az AMD GPU-k.

    Ultra off, de kíváncsi lennék rá, hogy erről mi a véleményed, mert én ugyan semmit sem értek a programozáshoz, de ha jól értem, akkor arról van szó, hogy ha Cilk-ben írnak meg egy (tetszőleges?) programot, akkor az sokkal jobban képes lesz kihasználni a többmagos/többszálú procikat, mintha bármelyik más jelenlegi nyelvben írták volna meg.

    (#16) Abu85:

    Abu, itt írtad, hogy "Ez az első rendszer, ami aszinkron feladatirányítást használ, vagyis a GPU több, teljesen független utasításfolyam párhuzamos futtatására is képes. Ezzel lényegében lehetővé válik több GPGPU-s alkalmazás párhuzamos futtatása is egyetlen grafikus processzoron." és ezzel kapcsolatban lenne egy olyan kérdésem, hogy ez nagyjából ugyanaz-e, mint a Fermi "Concurrent Kernel Execution" képessége (ahol 16 kernel futhat egyszerre, de van egy ilyen megkötés, hogy "same application context", vagy "same CUDA context"), vagy több annál?

  • Iron Funeral

    őstag

    válasz dezz #11 üzenetére

    Nyílván nem 5 emberre gondoltam, légyszi ne nézz már retardáltnak...

  • hugo chávez

    aktív tag

    válasz dezz #13 üzenetére

    Nos, VxWorks helyett RTLinuxot, csak hát ugye a support...
    UNICOS/CLE helyett OpenBSD-t, vagy FreeBSD-t, csak hát ugye az optimalizáció és a support...

    "Csak mert a CUDA jól helyettesíthető az OpenCL-lel."

    NV hardveren is? Mert ugye az NV-nek nem érdeke az OpenCL terjedése a CUDA ellenében, tehát az NV-s OpenCL driverbe kerülhetnek érdekes dolgok, amiktől furcsa, ámde konstans lassulás következhet be az ugyanazon feladatot végrehajtó program CUDA-s verziójához képest.

  • hugo chávez

    aktív tag

    válasz dezz #9 üzenetére

    Ja, most már látom, hogy Abu írta el, pedig, amikor először olvastam a hírt, akkor fel se tűnt.

    Hát, talán egy kicsit erőltetett egy GPGPU API-t operációs rendszerekkel összehasonlítani, de mivel semmi mással nem tudom, ezért utánanéztem egy kicsit a hárombetűseknél használt operációs rendszereknek: a DoD a SUSE Enterprise-t és az erre épülő UNICOS/lc-t és utódját a CLE-t preferálja: [link], [link], [link]
    Az NSA-ről nem találtam biztos mostani infót, de úgy tűnik, hogy Cray XT5h-kat [link], [link] használnak, így ők is a UNICOS/lc valamelyik változatát használják. Mondjuk, attól, hogy Linux alapú a UNICOS/lc és a CLE, még nem tudom, hogy mennyire "open" (illetve a Linux része biztosan az, de pl. a Hardware Supervisory System és a System Management Workstation nem nyílt), de szerintem már csak a support miatt sem lehet a Cray-től független. Persze, lehet, hogy a jövőben ezen változtatni akarnak, de úgy tűnik, hogy eddig nem igazán zavarta őket a függés.
    A NASA (oké, tudom, ez nem három, hanem négybetűs :D ) beágyazott környezetben aktívan használja a VxWorks-öt [link], [link] ami pedig egyértelműen nem nyílt és nem cégfüggetlen, szóval ebből én arra következtetek, hogy az amerikai állami hivatalok döntéshozói hajlamosak feláldozni a nyíltságot és a cégfüggetlenséget cserébe a teljesítményért, hatékonyságért, megbízhatóságért, supportért vagy csak simán némi mutyipénzért. ;]

    (#8) Duracellm...:

    "kicsit rá kellene gyúrni a performancéra :D is, hogy ne csak egy pipa legyen az Usernek."

    Ezt nem teljesen értem :F

  • Iron Funeral

    őstag

    válasz dezz #6 üzenetére

    Miért ne gyártanának? Ha arra lesz igény akkor olyat gyártanak.

  • hugo chávez

    aktív tag

    válasz dezz #6 üzenetére

    Egy kis kötekedés: "nemzetközi"? :Y ;]

    Amúgy, szerintem az esetleges közös fejlesztések gyümölcsének elsődleges felhasználási területén (DoD, NSA és a többi hárombetűs) inkább a számítási teljesítmény és az ezt, illetve az architektúrát minél jobban kihasználni képes API (és, ha a hardver NV, akkor ugye borítékolható a CUDA) érdekli, nem pedig az, hogy néhány gyártó (és "próféta" ;] ) mennyire hype-olja az OpenCL-t.

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

Hirdetés