Új hozzászólás Aktív témák
-
szilagyiv
senior tag
Most akkor a Java kód a virtuális gépben fut, ami után ott van az Apariapi, ami után ott van az OpenCL, ami után ott van a driver, ami után következik csak a vas. Nem sok a köztesréteg kicsit?
De az is lehet, hogy símán csak nem értem (mert nem vagyok programozó).
-
Peter13
senior tag
Engem meg az érdekelne, hogy miért jó a Java kódot grafikus processzoron (vagy processzor-részen) futatni? Én sem vagyok programozó, csak érdekelne hogy mi a gyakorlati haszna (ha egyszer elfutkos a CPUn is). GPU ugye jól párhuzamosítható feledatokban jeleskedik, a tipikus Java kód (ha van ilyen) akkor ezek szerint ilyen?
"No, I'm not immortal: I'm just not good at dying..."
-
B4nd1t4
tag
Pappirappappaaaaa - I'm lovin it....
Alamuszi Nyuszi nagyot ugrik... :)
-
Cathfaern
nagyúr
A Java ugyanúgy teljesen általános programnyelv, mint mondjuk a C. Szóval tipikus kódról nincs értelme beszélni, viszont ebből adódóan nyilván lehetnek olyan feladatok, amik jól párhuzamosíthatóak.
szilagyiv:
Tény, hogy nem kevés, de a java épp erről szól (nyilván a maga hátrányaival, és előnyeivel) -
DRB
senior tag
Ez mennyire van kötve a GPU-hoz? Úgy értem minden alkalmas GPU-n megy, vagy csak AMD(ATi)-n?
-
-
Male
nagyúr
Elég soknak hangzik, főleg ha mégsem sikerül a GPU-n futnia, és még vissza is dobja... erősen feladat függő, de ettől még sokszor megérheti.
Pl nekem a diplomamunkámban baromi sok DCT - iDCT párt kellett futtatni menet közben (vízjelező programot csináltam), ez tisztán CPU-ból ment, ami érezhető is volt a tempón, de a GPU-knak nagyon feküdne az a feladat (már eleve a DCT is, de ebben az esetben több ezer teljesen független transzformáció kellett / kép, szóval rohadt jól lehetett volna párhuzamosítani). Itt hiába lenne sok réteg pluszban biztos, hogy nagyon pozitív lenne a mérleg.
-
Mercutio_
félisten
Azért, mert vannak olyan szituk, amikor nagyságrendekkel gyorsabb tud lenni a GPU, másrészt, jellemzően amikor a GPU nem csinál semmit, akkor érdemes vele számoltatni ezzel levéve a terhet a CPU-ról.
Eladó/Cserélhető: GERE Kopar faládák, ÓRA:Orient Bambino II Bigsize, FANTASY könyvek, Garis keskeny MOSOGATÓGÉP, könyvespolcok, MOSÓGÉP
-
marcias
őstag
Pont az ilyen, és ehhez hasonló projektek fogják szép lassan beindítani a gpu alapú számítások elterjedését.
Steam: marcias88
-
O_L_I
őstag
Érdekes, hogy egy éve az nVidia a Fermi megjelenésének táján azt mondta hogy számukra már nem a grafikus teljesítmény az elsődleges hanem, hogy erős GPGPU-t építsenek.
Ehhez képest de javítsatok ki ha tévedek az utóbbi időben mintha az AMD sokkal jobban tolná a GPGPU elképzelés szekerét...[ Szerkesztve ]
-
hugo chávez
aktív tag
"Ehhez képest de javítsatok ki ha tévedek az utóbbi időben mintha az AMD sokkal jobban tolná a GPGPU elképzelés szekerét..."
Az a baj, hogy jelenleg a Kepler-ről szinte semmit nem lehet tudni ezen a képen kívül, mondjuk, GPGPU szempontból mindenképpen ígéretes, hogy a kép szerint a DP FLOPS azonos fogyasztás mellett megháromszorozódik a Fermi-hez képest. Ezzel szemben az AMD új (GP)GPU-járól már ismert néhány dolog [link], [link], de, mivel a Kepler architektúrájáról még semmit sem lehet tudni, ezért most még megtippelni sem lehet, hogy az AMD, vagy az NV új fejlesztése lesz-e a "jobb" GPGPU.
[ Szerkesztve ]
"sajnos ez a beszélgetés olyan alacsony szintre jutott, hogy a továbbiakban már nem méltó hozzám" - by Pikari
-
_Orbi_
aktív tag
Minecraft!!!
-
bambano
titán
"virtuális gépen fut, vagyis a fejlesztők nem nagyon törődnek a pointerek, illetve a destruktorok használatával, vagy mondjuk a memória felszabadításával.": ettől a mondattól sírhatnékom támadt...
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Abu85
HÁZIGAZDA
At the time we were beginning to see Java bindings for OpenCL™ and CUDA (JOCL, JOpenCL and JCUDA), but most of these provided JNI wrappers around the original OpenCL or CUDA C based APIs and tended to force Java developers to do very un-Java-like things to their code. Furthermore, coding a simple data parallel code fragment using these bindings involved creating a Kernel (in a somewhat alien C99 based syntax; exposing pointers, vector types and scary memory models) and then writing a slew of Java code to initialize the device, create data buffers, compile the OpenCL code, bind arguments to the compiled code, explicitly send buffers to the device, execute the code and explicitly transfer buffers back again.
To the seasoned OpenCL developer this is all routine stuff, but to the Java developer this all seems a little overwhelming. Java developers are used to being (and quite happy to be) shielded from platform nitty gritty. We don’t use pointers, we don’t worry about destructors or tiered esoteric memory models or even about freeing memory explicitly. We expect the Java Virtual Machine to do this heavy lifting for us.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
bambano
titán
a vagyis-sal kezdődő mellékmondat magyarázza a főmondat állítását. amit írtál, az azt jelenti, hogy a java vm legfőbb tulajdonsága, hogy a fejlesztők nem törődnek a memóriakezeléssel.
valami nem attól lesz java vm, hogy nem törődnek a fejlesztők a memóriakezeléssel.
nem használunk pointereket, nem törődünk a destruktorokkal, egyéb ezoterikus memóriakezelési modellekkel, még azzal sem foglalkozunk, hogy explicit felszabadítsuk a memóriát. Mindezt a nehéz munkát ráhagyjuk a java virtuális gépre.
Az eredetiben sehol nem látok olyan mondatot, hogy "A Java alapvetően egy olyan nyelv, ami úgynevezett virtuális gépen fut". az értelemszerű fordítás nem jött össze.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
kisbalázs
tag
nekem azért sokkal szimpatikusabb az amd a többinél hogy ő legalább nyílt forráskódú cuccokat segít
Johnny Mnemonic 2021:320gb-t töltött az agyába és majdnem meghalt, inkább pendrive a s?ggébe!
-
Jim Tonic
nagyúr
Sőt, az egyes részleteket több eszközre kell optimalizálni, ami eltér a Java esetében alkalmazott alapfilozófiától.
Csak mondom, a java ez irányú filozófiája sosem jött be, mindig is optimalizálni kellett a különböző eszközökre.
#2: lebegőpontos számításokban többszörösen gyorsabb egy GPU.
[ Szerkesztve ]
Alcohol & calculus don't mix. Never drink & derive.
Új hozzászólás Aktív témák
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Mibe tegyem a megtakarításaimat?
- A fociról könnyedén, egy baráti társaságban
- OLED TV topic
- Kertészet, mezőgazdaság topik
- Sony MILC fényképezőgépcsalád
- Luck Dragon: Asszociációs játék. :)
- sziku69: Szólánc.
- Futás, futópályák
- Diablo IV
- További aktív témák...
- Újszerű - POWERCOLOR Radeon RX 5500 XT 8GB GDDR6 VGA videókártya
- Hibátlan - GIGABYTE GTX 1660Ti Windforce OC 6G 6GB GDDR6 VGA videókártya dobozos
- Hibátlan - PALIT GTX 1650 StormX 4GB GDDR5 VGA videókártya - tápcsatlakozó nélküli !!!
- ASUS ProArt GeForce RTX 4080 SUPER 16GB GDDR6X OC (ASUS-VC-PRO-RT4080S-O16G) Bontatlan új 3 év gar!
- XFX RX 6600 XT SPEEDSTER SWFT 210