Új hozzászólás Aktív témák
-
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.
-
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.
-
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.
-
#14
hugo chávez
aktív tag
O_L_I
#12
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.
-
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... -
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.
-
-
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) -
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?
-
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ó).
Csak mert ez így konkrétan nem volt leírva a hírben, és attól még, hogy az OpenCL nyitott az Aparapi-t lehet kötni az AMD-hez, még úgy is hogy ennek is nyílt a forráskódja(bár ez kissé megnehezíti(vagy nehezítené) a dolgot). 
Új hozzászólás Aktív témák
- PowerColor Red Devil AMD Radeon RX 6800 XT 16GB Garanciával!
- Asus DUAL-RTX5070-O12G nVidia 5070 12GB GDDR7 OC videokártya bontatlan dobozában eladó!
- GIGABYTE RTX 5080 16GB GDDR7 GAMING OC - Új, 3 év garancia - Eladó
- Gigabyte GeForce RTX 2060 6GB Garanciával!
- Gigabyte Geforce GTX 1070 G1 Gaming 8GB Garanciával!
- BESZÁMÍTÁS! GIGABYTE A520M R5 5600X 16GB DDR4 512GB SSD RX 6600 8GB ZALMAN N4 Cooler Master 650W
- AKCIÓ! Dell Latitude 5550 notebook - Intel Ultra 7 165U 16GB DDR5 RAM 1TB SSD Intel Graphics WIN11
- Új és újszerű 17.3" Gamer, irodai, üzleti készülékek nagyon kedvező alkalmi áron Garanciával!
- RÉSZLETFIZETÉS.BANKMENTES.KAMATMENTES ASUS Vivobook 17 X712EA-AU737W Notebook
- GYÖNYÖRŰ iPhone 13 Pro 128GB Silver -1 ÉV GARANCIA - Kártyafüggetlen, MS3387, 96% Akkumulátor
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest