- TCL LCD és LED TV-k
- Épített vízhűtés (nem kompakt) topic
- AMD GPU-k jövője - amit tudni vélünk
- Milyen belső merevlemezt vegyek?
- Projektor topic
- Vezetékes FEJhallgatók
- AMD Navi Radeon™ RX 9xxx sorozat
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Részletezte a Clearwater Forest felépítését az Intel
- Fejhallgató erősítő és DAC topik
Ú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
- Megdöntheti az iPhone 4 rekordját az iPhone 17
- TCL LCD és LED TV-k
- gban: Ingyen kellene, de tegnapra
- Napelem
- Autós topik
- A fociról könnyedén, egy baráti társaságban
- Épített vízhűtés (nem kompakt) topic
- AMD GPU-k jövője - amit tudni vélünk
- Milyen belső merevlemezt vegyek?
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- További aktív témák...
- MSI GeForce RTX 3090 VENTUS 3X 24GB OC Garanciával!
- ASUS ROG STRIX RTX 4070 Ti SUPER OC Edition 16G (kishibás) videokártya garanciával
- ASUS RX 5700 XT 8GB GDDR6 ROG STRIX OC Eladó!
- Eladó Gigabyte Aorus RTX 3070 8GB /Jótállással!/Dobozos!/Posta ok!/Beszámítás!
- Külső táp nélküli Asus GeForce GTX 1050Ti 4 GB ! AkciÓÓ!
- Telefon felvásárlás!! iPhone 15/iPhone 15 Plus/iPhone 15 Pro/iPhone 15 Pro Max
- 10 GB-os RTX 3080 OEM
- Telefon felvásárlás!! iPhone 13 Mini/iPhone 13/iPhone 13 Pro/iPhone 13 Pro Max
- Samsung Galaxy A55 5G / 8RAM 256GB / Gyárifüggetlen / 12 Hó Garanciával
- Ritkaság! Hibátlan Prémium felsőkategóriás LGA 1700 Alaplap! Asus Rog Strix Maximus Hero Z790 Wi-Fi
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest