Ontwikkelaar maakt gpu-compiler voor Java

Ontwikkelaar Phil Pratt-Szeliga heeft op GitHub een compiler geplaatst waarmee vrijwel alle Java-code voor een gpu gecompileerd kan worden. Volgens de developer is het zo mogelijk om met relatief weinig moeite Java-code via de gpu te draaien.

De compiler, Rootbeer GPU Compiler geheten, zou volgens Pratt-Szeliga krachtiger en minder complex zijn dan het gebruik van Cuda- en OpenCL-language bindings. Zo kan Rootbeer objecten automatisch vertalen naar primitive arrays, een vertaalslag die nodig is om code geschikt te maken voor afhandeling door een gpu. Ook het schrijven van een gpu-kernel in Cuda of OpenCL is niet langer nodig omdat Rootbeer de benodigde code na analyse van de Java-bytecode automatisch aanlevert in x86- en amd64-compatibele Cuda-code.

Rootbeer kan vrijwel alle onderdelen van de Java-programmeertalen omzetten naar code die op een gpu kan draaien, al zijn er enkele uitzonderingen zoals native methods en dynamic method invocation. Desondanks maakt de compiler het mogelijk om Java-code potentieel flink te versnellen door delen van de code naar een grafische rekenkern te sturen: in benchmarks die de ontwikkelaar heeft vrijgegeven, zijn aanzienlijke prestatiewinsten te zien.

Reacties (68)

[Verwijderd]

Ik ben zelf eerder voorstander van AMD's Aparapi. Bij die API moet je specifiek parallele taken opgeven, die door de GPU worden uitgevoerd. Er is ook een automatische CPU fallback als er geen OpenCL beschikbaar is. Werkt erg mooi én cross-OS.

Uiteraard zal er verbetering zijn met deze compiler, maar grote winst zul je pas halen als je je programma ophakt in parallelle taken en je de java.lang.Math functies door de GPU laat uitvoeren.

[Croga]

Wow... Dat zou nog wel eens een revolutie kunnen betekenen voor professionele toepassingen en de hardware in server parken.

Ik weet zo niet hoe het zit met efficiëntie en warmte productie per TFLOPS maar ik gok zomaar dat een low-end grafische kaart kan gaan concurreren met CPUs op JBOSS servers. Om nog maar te zwijgen over de AMD Fusion processoren.....

[Verwijderd]

Wow... Dat zou nog wel eens een revolutie kunnen betekenen voor professionele toepassingen en de hardware in server parken.

Even wat gezonde scepsis toevoegen.

Een applicatie die niet is opgebouwd om massaal paralelle threads te gebruiken zal hier waarschijnlijk nauwelijks baat bij hebben. Een GPU is namelijk niet goed in sequentieel verwerken van informatie, die moet het hebben van het grote aantal parallele threads dat hij kan verwerken.

Dus tenzij dat je een applicatie hebt die veel parallel kan doen, en daar ook voor gebouwd is, heb je hier denk ik niet direct veel aan. Concurrency is allesbehalve eenvoudig!

[delima]

Voor veel web applicaties geldt dat er één thread is per request van een eindgebruiker. Als je de veel concurrent users hebt, dan heb je veel threads.

Zou dat dan iets voor een GPU kunnen zijn? Of is één request voor één pagina al te complex?

[Reactie gewijzigd door delima op 24 juli 2024 04:35]

[Zoijar]

Voor veel web applicaties geldt dat er één thread is per request van een eindgebruiker. Als je de veel concurrent users hebt, dan heb je veel threads.

Juist voor dat soort taken zijn multi-core CPUs veel geschikter. Buiten het feit dat GPUs in de regel meer stroom verbruiken, en je al je data van en naar de GPU moet kopieren, zijn ze niet geschikt voor dit soort "random" taken. Een GPU is letterlijk maar goed in een ding: heel erg vaak precies hetzelfde doen op een ander stukje data. Voor graphics is dat ideaal waar je bijvoorbeeld de kleur van 2 miljoen pixel moet berekenen op nagenoeg dezelfde manier maar met andere parameters.

[Jegorex]

Een GPU process kan veel minder doen dan nodig is voor een gemiddelde web request van een eindgebruiker.
Je kunt een GPU heel goed gebruiken om snel erg veel berekeningen uit te voeren, maar zelfs de meest eenvoudige web pagina doorgeven aan een gebruiker is te veel gevraagd voor een GPU.

[wootah]

Grappig dat je dat zegt. In GPGPU mag je per thread eigenlijk maar een kleine hoeveelheid geheugen gebruiken. Waarom? Omdat het grote geheugen waar je ook toegang tot hebt voor veel te veel overhead zorgt. En als ik het over kleine hoeveelheden geheugen heb moet je denken aan zo'n 8KB. Ik schat in dat de meeste web applicaties toch wat meer gebruiken dan dat.

[Zoijar]

Een GPU is namelijk niet goed in sequentieel verwerken van informatie, die moet het hebben van het grote aantal parallele threads dat hij kan verwerken.

En dan ook nog eens threads die hetzelfde doen op een ander stuk van de data en operaties die data-lokaal zijn. Random geheugen access is verschrikkelijk duur op een GPU, zeker voor schrijf operaties.

Zo zal een ray tracer die in Java is geschreven en meerdere keren brancht op een ray ontzettend slecht draaien op een GPU. Dit is ook de voornaamste rede dat nog niet alle GPUs alleen maar ray-tracen ipv renderen.

[kozue]

Ja tuurlijk... server parken...
Heb je ooit een server (een echte, niet jouw omgebouwde home-desktopje) gezien met grafische kaart?

Dit is een leuke gimmick, en wellicht handig voor specifieke toepassingen, maar ik zie het nog niet zo snel overal gebruikt gaan worden.

[smeaggie]

Zoals deze bedoel je? http://www.amax.com/hpc/gpuservers.asp

[batjes]

Er zijn er zat hoor. Windows 2008 R2 en Windows 2012 gebruiken ook de GPU om een aantal normale taken heen te schuiven. 2008 R2 nog niet zo heel veel. 2012 een stuk meer. Kun je je CPU behoorlijk mee verlichten door er een GPU in te douwen.

[Verwijderd]

Als dit echt werkt is dit een behoorlijk revolutionaire ontwikkeling. Met OpenCL kun je geen serieuze software schrijven omdat essentiele dingen als operator overloading en OO functionaliteit ontbreekt. CUDA is wat dit betreft veel beter maar is nog steeds alleen voor NVIDIA en de laatste generatie NVIDIA kaarten zijn extreem slecht wat gpgpu performance betreft. Ik ga deze compiler dus zeker testen.

[johnbetonschaar]

Het soort code dat je op een GPU zou willen draaien (rekentaken dus, geen complete applicaties) heeft weinig tot geen baat bij OO technieken, operator overloading, of welk ander soort abstracties om architectuur en control flow logica mee vast te leggen. Een GPU is slechts goed in 1 ding, en dat is parallel grote hoeveelheden rekenwerk uitvoeren. Daarbij wil je juist een zo plat mogelijke structuur hanteren met zo min mogelijk abstracties, die leiden namelijk onvermijdelijk tot branches, conditionals en indirections. De beste manier om alle performance voordelen van GPU computing om zeep te helpen dus, want GPU's zijn notair slecht in dat soort dingen. Wat je wil doen is je applicatie in een high-level taal schrijven, en slechts de reken taken als hapklare blokken aan de GPU geven. Negen van de tien keer is dat gewoon data in, data out, zonder dat daar de abstracties van 'gewone' programmeertalen voor nodig zijn.

Dit project is weliswaar interessant maar zeker niet revolutionair, via bindings kon je al lang GPU computing doen vanuit Java. Nu is het misschien iets toegankelijker voor mensen die alleen Java kennen, maar dan nog zul je heel je software zelf geschikt moeten maken voor parallelle berekeningen, domweg Java bytecode naar GPU code vertalen gaat je echt niet zomaar automagisch super performance opleveren.

[Verwijderd]

Het soort code dat je op een GPU zou willen draaien (rekentaken dus, geen complete applicaties) heeft weinig tot geen baat bij OO technieken, operator overloading, of welk ander soort abstracties om architectuur en control flow logica mee vast te leggen.

Interessant, dat de beste stuurlui altijd aan wal staan. Zonder OO design is geen enkel software project onderhoudbaar, schaalbaar of begrijpelijk voor nieuwe ontwikkelaars.

Het is ook niet correct dat C++ CUDA kernels langzamer zijn dan C kernels. Er is geen verschil in performance.

[roy-t]

Er zal inderdaad geen verschil in snelheid zijn tussen C++ CUDA kernels en C CUDA kernels maar dat komt omdat de kernels zelf niet OO zijn. Of nog belangrijker dat komt omdat in de kernels zelf indirectie (als het goed is) zoveel mogelijk wordt weggewerkt.

Verder is het absolute onzin dat zonder OO design geen enkel project onderhoudbaar of begrijpbaar is. Ik weet vrij zeker dat voor dat OO bestond er ook goede software werd geschreven. Hoe onderhoudbaar je code is hangt veel meer af van het proces dan van de gebruikte techniek.

En ik zie nog meer waar ik het mee oneens ben. Je kunt geen serieuze software schrijven zonder operator overloading? Weet je wel waar je het over hebt? Java heeft geen operator overloading!

[roy-t]

Hoewel ik zelf niet zo'n JAVA fan ben heb je echt geen idee waar je het over hebt volgens mij. JAVA is inderdaad niet de standaard taal voor HPC toepassingen (gek genoeg is een van de populairste HPC talen Python, ben wel benieuwd waarom eigenlijk) maar het wordt zeker wel gebruikt. Het European Space Agency gebruikt bijvoorbeeld veel JAVA voor een hoop number crunchen.

Bronnen:
http://www.ateji.com/blog...gh-performance-computing/
http://gac.udc.es/~gltaboada/papers/JAVAHPC-CIEMAT-2011.pdf

[SuperDre]

over closeminded gesproken zeg... zeker nog te jong om niet met non-oo talen te hebben gewerkt, oo isn't the holy grail..... het maakt het leven van een developer wel makkelijker en luier.....

[Zoijar]

Mijn bedrijf zoekt altijd naar mensen op hpc/gpgpu gebied maar die gaan we naar aanleiding van dit nieuwsbericht dus specifiek niet in Nederland zoeken. Wat een kansloze reacties en een gebrek aan kennis hier zeg. Ik zal aanraden om in India of Oost Europa of zo te gaan zoeken.

Aan de hand van een paar reacties op een forum bij een nieuwsbericht je hele bedrijfsstrategie aanpassen en outsourcen naar India...

Verder eindigt dit weer in zo'n mijn-favoriete-taal-is-beter discussie. Het gaat uiteindelijk om de code die eruit rolt. Al doe je dat in javascript, als die een snelle hardware kernel kan compilen loopt het waarschijnlijk prima. Als je in high-performance C++ een kernel bakt die tien dynamische branches doet per data item loopt het waarschijnlijk voor geen meter.

[A Noniem]

OO design en OO implementatie zijn altijd nog twee verschillende dingen. Als je puur OO zou programmeren in CUDA zou je de prestaties om zeep helpen. GPU-code moet je aanleveren in hapklare brokken, alleen dan is een GPU snel in vergelijking met een CPU.

[Verwijderd]

Als je puur OO zou programmeren in CUDA zou je de prestaties om zeep helpen.

Nee, ik schrijf uitsluitend nog maar C++ kernels voor CUDA en de performance is prima. Absoluut niet langzamer dan C code. Alleen is C++ code beter leesbaar, onderhoudbaar en schaalbaar. Wat dat betreft is gpu code niet anders dan cpu code.

[marking]

Wat heeft C++ nou met C te maken in dit geval? Beide kunnen naar vrijwel identieke assembly compilen, het ligt er puur aan wat en hoe je het gebruikt. Feit is dat een GPU het meest efficient is in een data oriented aanpak.
Je gaat geen optimale performance halen als je een afbeelding in een OO design stopt waar elke pixel zijn eigen object is, derived van een color object, in een container genaamd image, welke dan compiled voor CUDA en naar de GPU stuurt, om maar een extreem voorbeeld te geven.
In plaats daarvan doe je intern (binnenje OO implementatie), deze in een vec4[] gooien en zo naar de GPU sturen.

[Reactie gewijzigd door marking op 24 juli 2024 04:35]

[A Noniem]

Ik heb het over OO vs niet-OO en dat niet-OO op GPU beter werkt, niet over C++ vs C op een GPU. Met C++ kan je alleen wat verder abstraheren dan C, zolang je dit niet teveel doet zal de performance inderdaad niet veel verschillen van standaard C. Je moet je echter wel ervan bewust zijn dat sommige van die extra features in C++ (al heeft nVidia er in Cuda een hoop uitgelaten i.v.m. o.a. de performance) ook een achilleshiel zijn als deze verkeerd worden gebruikt.

[johnbetonschaar]

[...]

Interessant, dat de beste stuurlui altijd aan wal staan. Zonder OO design is geen enkel software project onderhoudbaar, schaalbaar of begrijpelijk voor nieuwe ontwikkelaars.

Haha dat is een goeie, misschien moet je die opmerking eens naar jezelf vertalen. Ik heb in mijn professionele carrière denk ik al een slordige paar miljoen regels OO code geschreven/onderhouden, terwijl ik ben afgestudeerd op embedded hardware/software codesign (DSP's etc).

Volgens mij moet je eerst maar eens wat meer ervaring gaan opdoen als je denkt dat OO de enige goede manier is om onderhoudbare software te schrijven. Voor embedded taken is dit in veel gevallen niet of slechts gedeeltelijk waar. Voor extreem parallel werk is een functionele aanpak veel beter, bij voorkeur met een functionele taal, maar in de praktijk vaak ook in C. Het daadwerkelijke number crunchen op zoiets als een GPU duw je zo ver mogelijk naar onderen wat abstractieniveau van je archtiectuur betreft, waardoor je hopelijk op platte, data-in data-out functies op hapklare brokken data uitkomt. Zo niet, dan doe je iets verkeerd.

Mijn bedrijf zoekt altijd naar mensen op hpc/gpgpu gebied maar die gaan we naar aanleiding van dit nieuwsbericht dus specifiek niet in Nederland zoeken. Wat een kansloze reacties en een gebrek aan kennis hier zeg. Ik zal aanraden om in India of Oost Europa of zo te gaan zoeken.

Edit: nevermind...

[Reactie gewijzigd door johnbetonschaar op 24 juli 2024 04:35]

[Verwijderd]

We konden in Nederland al geen goede mensen vinden. De reacties hier bevestigen het beeld wat ik toch al had, een aantal mensen hebben de klok horen luiden maar weten niet waar de klepel hangt.

Ik doe de technische interviews trouwens en zou jou en je voorgangers om die reden niet aannemen, simpelweg gebrek aan kennis zoals bij iedere sollicitant tot nu toe. We zijn haast zover om werkloze Amerikanen of Indiërs te gaan importeren.

[SG]

Ik denk dat de weinige GPU ninja's die NL kent, nogal vrije keuze hebben in NL onverzadigde markt. Lage aanbod vs vraag. Andere landen lopen ver voor alleen door het grote toegankelijkheid van educatie. Zoals India. NL is studeren meer iets voor de hoge midden stand en rijken. Daarnaast reageren hier op deze van oorsprong tweakers nu jan en alleman, gewoon iedereen met of zonder kennis, maar wel een mening gebaseerd op vaak onwetenheid. Ik denk dat je de lieden vind met meer GPGPU kennis vind op het nVidia developers forum of AMD dev forum.
Zelfs of devnet krijg je ook veel inmenging van non gpgpu coders.

Zelf ook geinterresseerd in GPGPU en kijk ook naar Cuda OpenCL AMP
En nV heefd met de 680 aardig GPGPU specifiek logic uit gehaald tov 580 architektuur.
Terwijl AMD eerder GPGPU rijker is geworden. Ik zie eerder dat nV de GPGPU prof markt van eigen chip variant wilt voorzien.
Daarvoor waren de consumenten lijn in de drivers al Double precizion gelimiteerd. Om het op software matige manier te scheiden.

Heb aardig wat GPGPU boeken. Maar ben geen expert. Dus zal mij niet inmengen in de OO battle.

De Cuda boeken die ik heb gaat het ook over gpgpu optimalisaties die bulk van performance winst bepalen.
Het klopt, niet alles is geschikt voor GPGPU de programmeur moet eerst kijken of aplicatie kwa concurency baad heefd bij gpgpu. Want non concurent aandeel heefd grote impact en beperkt performance schaling aanzienlijk.
Daarnaast is optimnalisatie zwaar nodig. Er zijn 3 levels van geheugen. Local shared en videomem. Van snel naar traag en hoge latency.
Daarnaast is de block grote tussen verschillende typen cores ook nog verschillend.

Het kan zijn dat als je bepaalde software omport naar GPGPU je al aardige performance boost krijgt. Maar dat je na optimalistie een finke boost kn vrijgen. Maar dat je dan wel wat gpgpu specifieke talen moet verdiepen. Alleen al vanwege de gpgpu community daar reeds veel werk in verzet is dus ook veel kennis in de gpgpu community is.

Zelf eerder C# C++ dus zou eerder naar de AMP libaries kijken. Wil ook niet al te nV afhankelijk zijn met Cuda.

[Zoijar]

Daarnaast reageren hier op deze van oorsprong tweakers nu jan en alleman, gewoon iedereen met of zonder kennis, maar wel een mening gebaseerd op vaak onwetenheid.

Klopt, maar dat betekent niet dat iedereen onwetend is. Er staat hierboven heel wat terechte kritiek op mijnsinziens vrij kortzichtige generalisaties. Mensen als Roy, om maar een voorbeeld te noemen, weten best wel waar ze het over hebben als ik terug kijk naar zijn vroegere posts in Programming. Denk dat je als bedrijf blij mag zijn als je zo iemand binnen haalt. En met het risicio arrogant te klinken, zelf weet ik ook best redelijk waar ik het over heb met een phd in "graphics" en een jaar of 10-15 ervaring met GPUs. Om dat dan weg te zetten als "in nederland loopt er geen talent rond" vind ik extreem kortzichtig. Natuurlijk vallen mensen dan over zo'n domme uitspraak.

Blijkbaar herkent Rockzo gewoon geen talent en concludeert daarom dat het er niet is. Als je elke sollicitant die vindt dat je zonder operator overloading ook goede software kan schrijven niet aanneemt, dan hou je natuurlijk weinig over. Je zal maar na jaren studie ergens solliciteren en dan met zo iemand moeten praten... (maarja, er zal wel het een en ander wat aangedikt worden...)

[Reactie gewijzigd door Zoijar op 24 juli 2024 04:35]

[johnbetonschaar]

Klopt, maar dat betekent niet dat iedereen onwetend is. Er staat hierboven heel wat terechte kritiek op mijnsinziens vrij kortzichtige generalisaties.

[..]

Blijkbaar herkent Rockzo gewoon geen talent en concludeert daarom dat het er niet is

Als ik Rockzo zijn reacties lees dan lijkt het er eigenlijk meer op alsof hij gewoon een troll is die hier een beetje interessant wil komen doen over een onderwerp waar hij ook eens iets over gelezen heeft. Wat je ook voor programmeertaal of abstracties gebruikt zijn er gewoon een aantal zeer fundamentele eigenschappen die voor GPU computing of het schrijven van software voor DSP's of custom ASIC's gelden, en uit Rockzo zijn opmerkingen lijkt hij zich daar totaal niet van bewust, alleen al door zijn originele veronderstelling dat het 'behoorlijk revolutionair zou zijn' als je 'automatisch Java bytecode naar GPU code kunt converteren'.

Mij maak je niet wijs dat zo iemand verantwoordelijk is de sollicitaties voor HPC personeel bij wat voor bedrijf. Sowieso getuigen zijn opmerkingen over hoe dat in zijn werk gaat van weinig kennis over de arbeidsmarkt voor dit soort technisch personeel. Er zijn detacheerders die volkomen gericht zijn op embedded en HPC werk, en als je nog specialistischer nodig hebt recruiters die heel Europa voor je afzoeken als je een echte domein-expert nodig hebt (mijn zwager werkt toevallig voor zo'n bedrijf). Dat je voor zulke mensen maar 'werkloze Amerikanen en Indiaers' moet gaan halen is echt lachwekkend.

[Verwijderd]

Misschien dat de echte GPU ninja's gewoon niet bij jou willen werken

[Aloys]

Dat is natuurlijk lariekoek. Jij bent gewend geraakt aan OO en je hebt zelf, net zoals vele andere programmeurs daardoor meer moeite met talen als C.

Als je kijkt naar bedrijven die software schrijven voor embedded systems of software die erg goed porteerbaar (java is niet porteerbaar) moet zijn, dan zie je vaak gewoon nog C code. In C moet je iets anders nadenken, maar soms is het heerlijk om al die abstracties weg te hebben.

Daarbij is het complete systeem dus niet OO. Zolang je netjes programmeert en de documentatie in orde hebt, dan is er echt niets aan de hand.

* Aloys vind C een fijne taal! Overigens ben ik assistent bij twee programmeer vakken in C, het ligt zeker niet iedereen even goed, maar je leert er een berg meer van dat een beetje Java of C# prutsen.

[latka]

"Zonder OO design is geen enkel software project onderhoudbaar, schaalbaar of begrijpelijk voor nieuwe ontwikkelaars" heb al eens meerdere malen andermans Cobol mogen onderhouden naast C++ en Java code. Ik kan je vertellen: de Cobol code is veel beter leesbaar en begrijpelijk. Geen 'kijk mijn design pattern of the week' acties en andere shit die men zo nodig in applicaties moet stoppen om het CV op te poetsen. Het is dan ook werkelijk niet nodig OO te gebruiken om leesbare/onderhoudbare systemen te maken. Integendeel zou ik zelfs willen poneren. Het hangt voornamelijk af van de mindset van de ontwikkelaar. Als jij een systeem moet maken en je weet dat je hier 30 jaar verantwoordelijk voor gaat zijn doe je geen al te spannende dingen. In de wereld waarbij projecten systemen opleveren en de mensen hierna opzouten is die motivatie er niet en krijg je dus ononderhoudbare rommel (laatst nog eens een systeem in Javascript mogen zien: daar snapt dus werkelijk niemand meer wat van: een immature platform met een luizige programmeertaal zonder typing en dan onderhoudbare systemen maken. Sure.).

[demonite]

Helemaal mee eens. Met elke taal kun je onleesbare en niet onderhoudbare code maken. Hoe complexer de taal, hoe meer mogelijkheden om er een puinhoop van te maken. Templating en het ontbreken van strong typing zijn de top 2 ingrediënten voor je recipe for disaster.

[Wizz15]

Ik ben het volledig met je post eens, op het puntje Javascript na.

Toegegeven: Javascript in de browser is niet fijn om mee te werken, maar dit komt voornamelijk door de DOM. Javascript an sich (zonder DOM) is een fijne en super flexibele taal, mits je het niet probeert te gebruiken als een 'klassieke' taal zoals Java of C.

Het probleem is echter dat de meeste programmeurs bij het zien van Javascript denken: "Hey, dit komt me bekend voor". En vervolgens met de verkeerde mindset gaan zitten programmeren.

Prototypal inheritance is bijvoorbeeld iets wat de meeste programmeurs in hun eerste contact met Javascript compleet vergeten. Net als closures, met als gevolg rare bindings van het keyword 'this' en onverwacht gedrag in je programma.

In mijn optiek heeft Javascript zeker bestaansrecht (Node.js), het probleem is echter dat vrijwel iedere hobbyist denkt Javascript te snappen. Dit is voornamelijk te wijten aan de browser wars, waar het een sport werd om de meest crappy code nog te laten werken in Javascript, en Microsoft die dit alles vervolgens in de standaard heeft geforceerd.

Ik (en menig serieus Javascripter) zal het met je eens zijn dat strictere regels wat syntax betreft geen slecht idee zouden zijn (geen automatische semicolon placement, etc).

[Reactie gewijzigd door Wizz15 op 24 juli 2024 04:35]

[wootah]

In theorie heb je ook helemaal geen OO nodig om goede programma's te schrijven. OO kan het alleen maar iets makkelijker maken soms.

Ik kan best zien dat dit project handig is voor programma's die mensen thuis op hun pc willen draaien, dan hoeven al die java programmeurs opeens niet meer zo hard na te denken over hoe ze hun OpenCL/Cuda programma moeten schrijven.
Aan de andere kant zie ik dit niet terug komen in de high-performance wereld. Met OpenCL/Cuda kun je als programmeur veel verder optimaliseren en daardoor veel computer tijd besparen. Heb je daar voor getrainde mensen voor nodig? ja dat wel...

en lol om zijn eindconclusie:

I plan to maintain Rootbeer until the Java Programming Language is not popular.

Dat gaat nog wel een tijdje duren denk ik.

[ivarkentje]

Ik heb hier zelf (nog) heel weinig verstand van, maar betekent dit dat een spel als bijvoorbeeld Minecraft dan nu ook alleen door de CPU gedaan wordt?
En zou dat met deze tool dan ook een aanzienlijke prestatiewinst opleveren?

[peter123]

Minecraft maakt gebruik van OpenGL hardwareversnelling via de GPU.
http://www.minecraftwiki.net/wiki/Hardware_performance

[Reactie gewijzigd door peter123 op 24 juli 2024 04:35]

[elmuerte]

OpenGL != OpenCL.

[BastiaanCM]

Dat is te zien. Dit heeft niets met minecraft of games te maken.

Java is een programeertaal waar je programmas mee schrijft. Deze worden door een compiler omgezet in uitvoerbare code (voor de processor). Het artikel gaat over een compiler die de code kan omzetten in uitvoerbare code voor een grafische processor.

En dat is dan weer interessant omdat een CPU flink anders werkt dan een GPU.

[Reactie gewijzigd door BastiaanCM op 24 juli 2024 04:35]

[bogy]

omdat Rootbeer de benodigde code na analyse van de Java-bytecode automatisch aanlevert in x86- en amd64-compatibele Cuda-code.

is het dan enkel cuda?
want eerder in het bericht spreekt men over opencl én cuda, maar dan lees ik weer dat de compiler cuda-code aanlevert, iets waar amd(ati) en Intel (bv Ivy Bridge) kaarten eigenlijk niet veel mee kunnen want die doen uiteraard enkel OpenCL.

Ik hoop, al ben ik zelf geen ontwikkelaar, dat het gewoon wordt aangeleverd in zowel cuda (voor nvidia) als opencl (voor de rest); zodat je niet per sé een nvidia kaart moet hebben om te kunnen genieten van de snellere processing. Laat die teraflops maar vliegen; we investeren niet voor niets in vette 3D kaarten, nu kunnen ze ook wat werk verplaatsen als we niet aan het gamen of renderen in adobe's CS

[FreezeXJ]

Yep dit ziet eruit als CUDA (dus NVidia) only. Jammer voor als je doubles gebruikt en een nieuwe GPU hebt, want die hebben een beroerde prestatie.

Als voorbeeld: de 600-serie heeft een double performance van 1/24e van z'n float-performance... voor de 580 is dat 1/8e, voor de 480 en overige 500-kaarten 1/12e. AMD heeft 1/4e voor de 69X0 en 79X0, en 1/16e voor de overige true-7000-kaarten. (de overige 6000-kaarten ondersteunen geen double precision)

Voor een heleboel toepassingen maakt het niet uit, als je er rekening mee houdt, maar voor wetenschappelijk rekenwerk kan het essentieel zijn.
Daarnaast is het gewoon zuur om je te moeten beperken tot 1 fabrikant, veel handiger is code die op alles draait (OpenCL), al is het dan een procentje of wat langzamer. Het is al lastig genoeg om je GPU goed aan te sturen, als je je dan ook nog over model-specifieke dingen zorgen moet maken gaat de acceptatie nog veel langzamer.

[Reactie gewijzigd door FreezeXJ op 24 juli 2024 04:35]

[Zoijar]

Daarnaast is het gewoon zuur om je te moeten beperken tot 1 fabrikant, veel handiger is code die op alles draait (OpenCL), al is het dan een procentje of wat langzamer.

Het essentiele verschil is denk ik dat OpenCL geen functie-pointers ondersteunt en CUDA wel. Met functie pointers kan je zo'n beetje alle moderne OO/Java/C++ taal-dingetjes implementeren (virtual functions zijn in feite gewoon functie pointers, een pointer naar een tabel van functie pointers).

Ik zie niet hoe je Java code naar OpenCL zou kunnen compilen zonder functie pointer support. Het gaat dus niet om een procentje performance, maar het is zeer waarschijnlijk niet eens mogelijk. Veel hardware kan het ook niet, dus wat dat betreft is het geen echte "fout" van OpenCL: ze nemen de core functionaliteit die op de meeste hardware draait. CUDA heeft daarentegen alle functionaliteit van de nieuwste nvidia hardware. Naar CUDA is het goed mogelijk en niet veel anders dan Java naar C te compilen.

[Reactie gewijzigd door Zoijar op 24 juli 2024 04:35]

[Gropah]

Dit zou best kunnen helpen met de prestatie's van Java en zou erg kunnen helpen om Java gangbaarder te maken bij zwaardere programma's. Ik hoop er in ieder geval op, het is namelijk een heerlijke taal om in te ontwikkelen.

[vandijk]

Lijkt me een techniek die vooral aan de 'client'(desktop/workstation) kant voor performance verbetering kan zorgen. De meeste servers (virtual en fysiek) hebben geen CUDA compatible gpu aan boord.

[mBull]

dit blijkt me handig voor brute force password cracking tool te schrijven in java, aangezien je niet meer moet denken aan cuda, de compiler doet dit voor je.

[Verwijderd]

Helaas is dynamic method invocation nogal een fundamentele operatie, dus het idee dat je zomaar een bestaand programma of library zou kunnen gebruiken is niet echt realistisch.

[marsattacks]

In Mono heeft men iets gebouwd waar methods van een bepaalde class (Mono.Simd namespace) vertaald worden naar SIMD instructies, mits ze voorhanden zijn. Zo niet, word de instructie geemuleerd. Natuurlijk is een rechtstreekse vertaling zoals deze Phil Pratt-Szeliga doet nog beter. Mijn punt is: Microsoft, wanneer komen jullie eens met iets vergelijkbaars?