Ú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
Hirdetés
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Kerékpársportok
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Milyen TV-t vegyek?
- Asztalos klub
- Háztartási gépek
- Bittorrent topik
- Friss modell érkezett a Huawei MatePad 11.5-ből
- Milyen belső merevlemezt vegyek?
- Samsung LCD és LED TV-k
- További aktív témák...
- PNY EPIC-X RGB RTX 5060Ti 16GB / Gigabyte EAGLE OC RTX 5070 12GB videokárty 3 év garancia 27% áfa
- BESZÁMÍTÁS! SAPPHIRE NITRO+ RX 7900 XTX 24GB GDDR6 videokártya garanciával hibátlan működéssel
- ASUS TUF Gaming GeForce RTX 3090 24GB GDDR6X
- Gigabyte RX 6800 16Gb Aorus (LCD kijelzős)
- Eladó PNY GeForce RTX 4070 Ti SUPER 16GB OC XLR8
- Telefon felvásárlás!! iPhone 11/iPhone 11 Pro/iPhone 11 Pro Max
- Bitcoin Miner Eladó Bitmain Antminer S19 JPro 104 Th 3150 watt
- Bomba ár! HP Elitebook 8560W - i7-2GEN I 8GB I 500GB I 15,6" FHD I Nvidia I W10 I Garancia
- Akciós Windows 10 / 11 Pro OEM Licenc Kulcs 100% eredeti, jogtiszta!
- Eladó nem szép állapotban levő Apple iPhone 12 128GB / AKKU 100% / 12 hónap jótállás
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest