- Milyen okostelefont vegyek?
- iPhone topik
- Kiszivárgott a Pixel 10 Pro
- VoLTE/VoWiFi
- Azonnali mobilos kérdések órája
- Vivo X200 Pro - a kétszázát!
- Huawei Mate 20 Pro - a mindenit!
- Samsung Galaxy Z Fold4 - egyre megy, honnan nézed
- QWERTY billentyűzet és másodlagos kijelző is lesz a Titan 2-ben
- Honor Magic6 Pro - kör közepén számok
Új hozzászólás Aktív témák
-
Sir Ny
senior tag
válasz
hugo chávez #25 üzenetére
Én meg a környezetvédelemé. Éljenek a hardverre optimalizált szoftverek! Le a felesleges áramfogyasztással! Vesszenek a burzsuj vadkapitalista csakapénz cégek!
-
hugo chávez
aktív tag
"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.
-
dezz
nagyúr
válasz
hugo chávez #23 üzenetére
Persze, a C-re épül (ahogy az OpenCL is és több más), de egy ilyen kód attól még platformfüggő és a kódoláshoz meg kell ismerni az egész CUDA rendszert, bizonyos mértékig a HW felépítését is figyelembe kell venni.
-
hugo chávez
aktív tag
"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).
-
dezz
nagyúr
válasz
hugo chávez #19 ü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? A MathLab-ot szokták még emlegetni, amit szintén többfelé portoltak már. (De lehet, hogy keverem valami hasonlóval. Mindenesetre, van valamilyen platformfüggetlen matematikai cucc.)
Nehezen tudom elképzelni, hogy ezek most nekiálljanak CUDA-zni... Esetleg valamilyen hacker ügynökök.
Igen, a saját oprendszer(verzió) az várható, plusz állítólag a Windows8 is futni fog ARM-okon. Csak hát ez még csak az alap, a supportban nincs benne, hogy megírjuk helyettetek a szoftvert...
Nem tudom, double prec.-ben most mi a helyzet, de peak single prec.-ben valami dupla számok vannak AMD oldalon. Bár elvileg a feltételes ugrásokat kevésbé szereti. Azt meg ugye egyelőre nem tudhatjuk, hogy az AMD mennyire célozza a HPC-t a jelen fejlesztéseiben... De nem valószínű, hogy pusztán a PC-s grafikára gyúrnának.
Nem hallottam még erről a Cilkről és most nincs is időm elolvasni, de nem hinném, hogy ne lehetne "kézzel" optimálisabb kódot írni. Inkább talán arról van szó, hogy ez viszonylag optimális low-level kódot tud generálni, magas szintű nyelvből.
-
Abu85
HÁZIGAZDA
válasz
hugo chávez #19 üzenetére
Az annyit jelent, hogy a Cayman esetében el tudsz indítani több GPGPU alkalmazást is és párhuzamosan futhatnak. Például több folding egyszerre, ugyanazon a GPU-n.
A Ferminél jól írod ez a megkötés. Ez annyit jelent, hogy nem futtathatsz több foldingot ugyanazon a GPU-n. -
hugo chávez
aktív tag
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ó
), 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?
-
dezz
nagyúr
válasz
Iron Funeral #17 üzenetére
Khmm, én sem...
Hanem párezerre. De az sem biztos, hogy néhány tízezer kedvéért fenntartanának egy iparágat, ha tízmilliószámra adhatják el a "kézi készülékeket" és más effélét.
Persze munkaállomások valószínű sokáig lesznek még (bár ebbe is bezavarhat a felhős dolog), de hogy játékok lesznek-e rá...
Aztán persze lehet, hogy mégsem így lesz, de ez a trend.
-
Abu85
HÁZIGAZDA
válasz
hugo chávez #14 üzenetére
Ahogy látom az OpenCL-t jól támogatja az NVIDIA, csak az asztali termékek esetében lassabb az implementálás. Ennek az az eredménye, hogy a GeForce driver még mindig OpenCL 1.0-s, míg a Catalyst már október óta OpenCL 1.1. A Quadro driver például már más. Ott van korrekt OpenCL 1.1 támogatás.
-
dezz
nagyúr
válasz
hugo chávez #14 üzenetére
Ezért lenne jó, ha lennének végre rendes tesztek ezekre. Ha ezáltal (OpenCL vs. CUDA, Nvidia vs. AMD) bizonyítást nyerne, amit írsz, szerintem rá tudnának hatni a 3 betűsek, hogy ne csíteljenek...
De a legnagyobb poén az lenne, ha AMD GPU-kon gyorsabb lenne az OpenCL, mint Nvidián a CUDA.
-
hugo chávez
aktív tag
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.
-
dezz
nagyúr
válasz
hugo chávez #12 üzenetére
Miket tudnál ajánlani ezek helyett? Csak mert a CUDA jól helyettesíthető az OpenCL-lel.
-
hugo chávez
aktív tag
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) 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
is, hogy ne csak egy pipa legyen az Usernek."
Ezt nem teljesen értem
-
dezz
nagyúr
válasz
Iron Funeral #10 üzenetére
5 ember kedvéért nem fognak.
-
dezz
nagyúr
válasz
hugo chávez #7 üzenetére
C&P a cikkből. Nekem is furcsa volt, de gondoltam, talán egy olyan is van ott.
Így rákeresve csak nemzetit találok.
Szerintem legalább olyan fontos, nekik aztán főleg, hogy ne egy cégtől függjenek...
(#8) Duracellm...: Az már a chipjeik felépítéséből is látszik egy ideje. Abu nem véletlenül írja, amit.
-
#16939776
törölt tag
Ha ez évente lesz, abból látszani fog hogy tényleg akarják a HPC szegmenst.
(#7) hugo chávez: NV be akarja bizonyítani hogy a CUDA, tényleg használható... kicsit rá kellene gyúrni a performancéra
is, hogy ne csak egy pipa legyen az Usernek.
-
hugo chávez
aktív tag
Egy kis kötekedés: "nemzetközi"?
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.
-
dezz
nagyúr
És ahhoz mit szól a Los Alamos-i nemzetközi laboratórium, hogy az Nvidia a saját zárt, platformfüggő megoldásához akarja láncolni őket és a HPC szektort -- amikor ott van az OpenCL is?
megint én, Eddie141, r1E3S3E7T: És szerintetek ha már mindenki "marok dolgok"-at fog használni (és/vagy pl. a tévéje beépített cuccát, stb.), gyártani fognak még moduláris cuccokat egy marok geeknek?
Hozzáteszem, HPC területen nem a miniatűrizálás lesz később sem a cél, hanem a teljesítmény, így még sokáig lesznek nagyteljesítményű, méretes chipek. De azért vannak itt is kérdések: mennyire maradnak meg ezek a chipek GPU-nak, nem jön-e be ott majd valami nem-PC-s kártyaszabvány, stb.
-
Eddie141
senior tag
válasz
Iron Funeral #4 üzenetére
Én is hasonlóra gondoltam. Nincs gond a miniatürizálással. Sőt azt sem bánnám, ha azonos dolgokat tudnék megtenni a telefonommal (játszani ilyen szinten, és minden mást is) az tetszene. Mondjuk lassan oda értünk
-
hugo chávez
aktív tag
Hehe, múltkor a DARPA, most meg a LANL, azért az Nvidia tudja, hogy kikkel kell cimbiznie a potenciális jövőbeni (és persze feltehetően igencsak "zsíros") állami megrendelések érdekében.
-
Eddie141
senior tag
A pc él, és élni is fog. A marokmegoldások csupán abban a tekintetben köszönhetnek be szerintem, hogy egyre jobban a miniatürizáláson van a hangsúly, és hamarosan azért már a mini-itx-es lapokban is megjelenhetnek komolyabb hardverrel szereltek (2 éve belül) és így kiválthatják akár teljes mértékben a nagyobb társaikat.
Mindenesetre én nem vagyok akár az általad leírt "marok dolgok" ellen sem. Az sem butaság. De a Pc ipart biztosan nem fogja kiszorítani. -
megint én
őstag
Jönnek majd a PC vége jóslatok???
Reméljük nem lesznek szellemileg visszamaradott gyerekek, akik a"marok dolgokat" preferálják...
A kép Abu egyik kommentjéből...
Új hozzászólás Aktív témák
Hirdetés
- Csere-Beszámítás! Sapphire Nitro+ RX 6700XT 12GB Videokártya!
- BESZÁMÍTÁS! Gigabyte AORUS MASTER RX 6800 XT 16GB GDDR6 videokártya garanciával hibátlan működéssel
- BESZÁMÍTÁS! SAPPHIRE Pulse OC RX 9060 XT 16GB GDDR6 videokártya 27% áfa 3 év garancia
- ROG Astral GeForce RTX 5080 16GB GDDR7 OC Edition - 32 HÓNAP IPON GARANCIA
- Msi Mech 2x Radeon RX 6600 XT GAMING X 8G
- Jo Nesbo: LEOPÁRD (nem olvasott)
- AKCIÓ! HP Elitedesk 800 G1 USDT mini asztali számítógép - i7 4770S 16GB RAM 128GB SSD Intel HD
- BESZÁMÍTÁS! MSI B450M R7 2700X 32GB DDR4 512GB SSD RTX 3050 8GB Rampage SHIVA Thermaltake 500W
- Bomba ár! Dell Latitude E6440 - i5-4GEN I 8GB I 250GB I 14" HD I HDMI I Cam I W10 I Garancia!
- ÁRGARANCIA! Épített KomPhone i9 14900KF 64GB RAM RTX 5080 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest