Ú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
- 222 - Lenovo LOQ (15IRX10) - Intel Core i5-13450HX, RTX 5050
- 2000GB NVMe SSD, 1 év gar
- 153 - Lenovo LOQ (15IRX9) - Intel Core i5-13450HX, RTX 4060 (ELKELT)
- Új HP 15 Victus FHD IPS 144Hz i5-12500H 12mag 16GB 512GB SSD Nvidia RTX 4050 6GB Win11 Garancia
- BESZÁMÍTÁS! 1TB Samsung 870 EVO 2,5" SATA SSD meghajtó garanciával hibátlan működéssel
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest