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)
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.....
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.....
Even wat gezonde scepsis toevoegen.Wow... Dat zou nog wel eens een revolutie kunnen betekenen voor professionele toepassingen en de hardware in server parken.
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!
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?
Zou dat dan iets voor een GPU kunnen zijn? Of is één request voor één pagina al te complex?
[Reactie gewijzigd door delima op zondag 12 augustus 2012 14:58]
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.
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.
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.
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.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.
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.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.
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.
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.
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.
Zoals deze bedoel je? http://www.amax.com/hpc/gpuservers.asp
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.
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.
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:
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:
Dat gaat nog wel een tijdje duren denk ik.I plan to maintain Rootbeer until the Java Programming Language is not popular.
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.
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.
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 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.
Het is ook niet correct dat C++ CUDA kernels langzamer zijn dan C kernels. Er is geen verschil in performance.
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.
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.Als je puur OO zou programmeren in CUDA zou je de prestaties om zeep helpen.
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.
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 zondag 12 augustus 2012 15:36]
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.
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!
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!
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.....
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.
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
Bronnen:
http://www.ateji.com/blog...gh-performance-computing/
http://gac.udc.es/~gltaboada/papers/JAVAHPC-CIEMAT-2011.pdf
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.
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.
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).[...]
Interessant, dat de beste stuurlui altijd aan wal staan. Zonder OO design is geen enkel software project onderhoudbaar, schaalbaar of begrijpelijk voor nieuwe ontwikkelaars.
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.
Edit: nevermind...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.
[Reactie gewijzigd door johnbetonschaar op zondag 12 augustus 2012 22:30]
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.
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.
Misschien dat de echte GPU ninja's gewoon niet bij jou willen werken 
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.
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.
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.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.
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 maandag 13 augustus 2012 11:39]
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'.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
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.
"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.).
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.
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).
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 maandag 13 augustus 2012 12:27]
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.
betekend dit dat minecraft straks fatsoenlijk kan lopen ?
Om serieus antwoord te geven:
Minecraft maakt al gebruik van de GPU, ze maken gebruik van OpenCL voor zover ik weet. Als ze overgaan op Rootbeer zal Minecraft waarschijnlijk niet beter of minder gaan lopen, alleen is het misschien makkelijker te onderhouden voor de developers.
Minecraft maakt al gebruik van de GPU, ze maken gebruik van OpenCL voor zover ik weet. Als ze overgaan op Rootbeer zal Minecraft waarschijnlijk niet beter of minder gaan lopen, alleen is het misschien makkelijker te onderhouden voor de developers.
ah, toch bedankt voor het antwoord
is het dan enkel cuda?omdat Rootbeer de benodigde code na analyse van de Java-bytecode automatisch aanlevert in x86- en amd64-compatibele Cuda-code.
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
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.
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 zondag 12 augustus 2012 14:57]
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).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.
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 zondag 12 augustus 2012 15:47]
Het kan aan mij liggen, maar de prestaties lijken nog steeds behoorlijk slecht. Bijvoorbeeld de 4096x4096 dense matrix vermenigvuldiging met GPU in 52 seconde. Mijn AMD N36L (dual-core 1.3 GHz) doet dat met een enkele CPU core in 58 seconde, terwijl een redelijke GPU met efficiente CUDA/OpenCL code dat zeker onder de 1s zou moeten kunnen.in benchmarks die de ontwikkelaar heeft vrijgegeven, zijn aanzienlijke prestatiewinsten te zien.
Mis ik iets of is Java inderdaad zo verschrikkelijk inefficient?
Als je software niet geschikt is om parallel te draaien (en dan niet 10 threads maar 100(en)) dan zul je hier weinig voordeel uit halen![...]
Mis ik iets of is Java inderdaad zo verschrikkelijk inefficient?
Iets met "no free lunch"
.Mijn punt is dat hun GPU oplossing voor hetzelfde paralleliseerbare probleem nog altijd niet echt sneller is dan een oplossing in C met langzame CPU.Als je software niet geschikt is om parallel te draaien (en dan niet 10 threads maar 100(en)) dan zul je hier weinig voordeel uit halen!
Wordt er nou een kernel bedoelt die op een GPU draait of een CPU-kernel met GPU-computing-support? Die eerste lijkt me erg interessant, maar ik betwijfel of het al kan: je videokaart eruit slopen en via een alternatief PCI-slot een soort GPU-chipset met BIOS en voeding eraan hangen zodat je een zelfstandige op GPU draaiende computer krijgt.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.
edit: dat was @hoofdthread
[Reactie gewijzigd door blorf op zondag 12 augustus 2012 14:58]
java (en c#) kunnen sneller zijn dan C++ applicaties omdat ze JIT gecompileerd worden en dus de optimalisaties van die bepaalde machine kunnen gebruiken, terwijl C++ code vooraf gecompileerd is en dus sommige optimalisaties mist
Je kan C/C++ ook gewoon optimaliseren in de compiler op voorhand, de JIT heeft daar helemaal niets mee te maken ... C/C++ is sneller en efficiënter dan Java omdat het geen VM nodig heeft en je dichter op de hardware speelt. Daarentegen is het foutgevoeliger en vereist het soms wat meer programmeerwerk.
Totdat er een nieuwe technologie komt in je processor waar je weer voor moet optimaliseren. De java app zal (mits de developers hem in de java VM steken, wat vrijwel altijd gebeurt) er gebruik van kunnen maken, je c++ app niet, die moet je hercompilen en opnieuw distribueren.
Het heeft alles met JIT te maken.
Het heeft alles met JIT te maken.
Als er een nieuwe technologie komt, dan wordt de compiler daar ook gewoon voor aangepast. Het is een kwestie van updaten. Daarnaast als er een nieuwe technologie beschikbaar komt, is het soms gewoon nodig om je broncode en methoden anders te schrijven om hiervan te profiteren. Daarnaast ben je bij Java afhankelijk van een ander om je software beter te laten draaien.
Kijk in de realiteit eens naar het prestatieverschil tussen beiden, aarin je duidelijk ziet dat Java zo goed als altijd het onderpit moet delven als het op prestaties aankomt. Tijdskritische applicaties en deze die maximale performance vereisen worden altijd in C/C++ geschreven ipv Java omdat de overload van de VM gewoon niet gewenst is.
Kijk in de realiteit eens naar het prestatieverschil tussen beiden, aarin je duidelijk ziet dat Java zo goed als altijd het onderpit moet delven als het op prestaties aankomt. Tijdskritische applicaties en deze die maximale performance vereisen worden altijd in C/C++ geschreven ipv Java omdat de overload van de VM gewoon niet gewenst is.
die overhead is volledig afhankelijk van
1) wat je met die code wilt doen
2) hoe je het programmeert
Daarnaast zijn de calls die je maakt naar de VM vaak sneller dan je eigen calls naar hardware omdat ze hard geoptimaliseerd zijn per platform, wat je niet kan doen in je eigen code (naar elk platform hard optimaliseren).
Ook geheugenmanagement zijn in een managed heap (zoals die van Java met een garbage collector) dynamische allocaties vaak sneller afgehandeld
Wat ik wel niet weerleg is dat er een vorm van overhead is, je toepassing kan ook trager draaien (ik heb nooit gezegd dat Java/C# applicaties altijd sneller zijn dan C++ applicaties), en meer geheugen verbruiken (door de VM). Ik wil alleen aantonen dat een Java programma niet altijd traag is, en dat dit met de tijd flinke verbeteringen heeft gekend. Helaas zit de slechte naam er nog steeds in, door een aantal veel gebruikte libraries (zoals Swing).
Moraal van het verhaal: iedere taal heeft zijn eigen voordelen als het komt op vlak van snelheid
1) wat je met die code wilt doen
2) hoe je het programmeert
Daarnaast zijn de calls die je maakt naar de VM vaak sneller dan je eigen calls naar hardware omdat ze hard geoptimaliseerd zijn per platform, wat je niet kan doen in je eigen code (naar elk platform hard optimaliseren).
Ook geheugenmanagement zijn in een managed heap (zoals die van Java met een garbage collector) dynamische allocaties vaak sneller afgehandeld
Wat ik wel niet weerleg is dat er een vorm van overhead is, je toepassing kan ook trager draaien (ik heb nooit gezegd dat Java/C# applicaties altijd sneller zijn dan C++ applicaties), en meer geheugen verbruiken (door de VM). Ik wil alleen aantonen dat een Java programma niet altijd traag is, en dat dit met de tijd flinke verbeteringen heeft gekend. Helaas zit de slechte naam er nog steeds in, door een aantal veel gebruikte libraries (zoals Swing).
Moraal van het verhaal: iedere taal heeft zijn eigen voordelen als het komt op vlak van snelheid
C/C++ is lastiger te optimaliseren dan Java: vooral function inlining vereist goede profiling en als jij profiled met een verkeerde testset is je inlining niet optimaal. Een VM optimaliseert niet op basis van een of andere synthetische testset maar op basis van real-life data en maakt zou veel meer kans het goede te doen. Dat niet altijd uit de verf komt is een probleem van de VM in kwestie, maar het is theoretisch zo dat een VM minimaal net zo goed kan zijn als statische compilatie en in de praktijk veel beter.
alleen de praktijk wijst uit dat 99% van de c++ applicaties die los gecompileerd zijn voor een bepaald platform een stuk sneller draaien.
of kijk naar bv android waarbij duidelijk is dat de dalvik java vm een stuk, HEEL stuk trager is dan bv mono(die gasten van mono hebben 'android' eens als test geport naar mono/c# waarbij deze in de meeste gevallen zo'n 80% sneller draaide dan nu, wat voor mij een teken is dat ze eigenlijk zo snel mogelijk die hele dalvik moeten dumpen), en in de meeste gevallen is meteen optimaal compileren nog eens een verbetering oplevert ten opzichte van .net... eigenlijk nog geen applicatie gezien die beter presteerde geschreven in bv C# dan 1tje die in native c++ of zelfs C is geschreven.
Want waarom is het toch zo tegenwoordig dat je een veel snellere computer nodig hebt om een nieuwere versie te draaien van bepaalde software met de performance van de oude versie op je oudere hardware...
kijk ook eens hoe ineffiecient bv android dus wel niet is, 80% verschil, noem ik toch echt te gek voor woorden.
of kijk naar bv android waarbij duidelijk is dat de dalvik java vm een stuk, HEEL stuk trager is dan bv mono(die gasten van mono hebben 'android' eens als test geport naar mono/c# waarbij deze in de meeste gevallen zo'n 80% sneller draaide dan nu, wat voor mij een teken is dat ze eigenlijk zo snel mogelijk die hele dalvik moeten dumpen), en in de meeste gevallen is meteen optimaal compileren nog eens een verbetering oplevert ten opzichte van .net... eigenlijk nog geen applicatie gezien die beter presteerde geschreven in bv C# dan 1tje die in native c++ of zelfs C is geschreven.
Want waarom is het toch zo tegenwoordig dat je een veel snellere computer nodig hebt om een nieuwere versie te draaien van bepaalde software met de performance van de oude versie op je oudere hardware...
kijk ook eens hoe ineffiecient bv android dus wel niet is, 80% verschil, noem ik toch echt te gek voor woorden.
Dalvik is geoptimaliseerd voor minder geheugen verbuikt. Pak een willekeurige Sun/Oracle VM en die rent rondjes om je statische C/C++ code (na opwarmtijd).
Volgens de docs doet de CPU versie in java er 58 minuten over.. als jouw CPU dat doet in 58 seconden... lijkt me dat je dan niet dezelfde berekening uitvoert.. En zowel dan is java wel heul erg dramatisch langzaam. Java is traag, maar ook weer niet zo traag.
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.
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.
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.
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.
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?
En zou dat met deze tool dan ook een aanzienlijke prestatiewinst opleveren?
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.
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 zondag 12 augustus 2012 15:01]
Minecraft maakt gebruik van OpenGL hardwareversnelling via de GPU.
http://www.minecraftwiki.net/wiki/Hardware_performance
http://www.minecraftwiki.net/wiki/Hardware_performance
[Reactie gewijzigd door peter123 op zondag 12 augustus 2012 16:53]
OpenGL != OpenCL.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Apple Microsoft Sony Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
