Oracles nye platform skal give flere sprog - men er ydelsen bedre?

Den hellige Graal er vel forvaret, mener Oracle, der har et nyt bud på afviklingsmiljø. Illustration: Bigstock/Pmm.art
En ny compiler fra Oracle med indbygget sprogforsyning skal give bedre ydelse. Men hvis man vil have den toptunede model, skal der betales licenspenge. Ekspert er skeptisk.

Oracle, der står bag Java-platformen, i hvert fald så vidt som at firmaet ejer varemærket, arbejder på en ny afviklingsplatform. Den har fået det pompøse navne GraalVM.

På JDK IO-konferencen, som blev afholdt for nyligt på IT-Universitet i København, gav Oleg Šelajev fra holdet bag det nye miljø en gennemgang af mulighederne.

Oleg Šelajev fra Oracle talte om firmaets nye afviklingsmiljø på JDK IO-konferencen, der blev afholdt i København for nyligt. Illustration: Christian Damsgaard

Graal er en ny just-in-time compiler til JVM-verdenen, som fokuserer på ydelse og understøttelse af flere sprog.

Twitter er blandt kunderne, men firmaet bygger dog selv miljøet fra open source-kildekoden.

Graal kan i visse tilfælde give bedre ydelse til Java-programmer og sprog som Javascript, Ruby, Python og R. Derudover muliggør miljøet udførelse af ‘født’ kode via kompileren LLVM, der i sig selv understøtter et stort antal sprog.

Graal kan også kompilere Java-kode ‘ahead-of-time’, hvor slutproduktet er eksekverbare filer, i stedet for Java-bytecode.

Graal er tilgængelig i en open source-udgave og en enterprise-version, der - lidt usædvanligt - indeholder optimeringer, som ikke er med i den åbne udgave.

Mystik om ydelsesforbedringer

Oleg Šelajev er ikke helt klar i mælet, når det gælder hvilke slags Java-programmer, der kan få bedre ydelse under kørsel i det nye miljø, og under hvilke præmisser. Men det handler dog mest om nyere Java-kode, skrevet i Java 8 eller senere, forklares der.

Han viser et slide, der peger på, at ydelsen med ‘almindelig’ Java-kode ikke forbedres væsentligt. Til gengæld er Graals implementering af Ruby, Python og R meget hurtigere end de officielle udgaver.

En ledende ekspert på området, som Version2 har talt med, og som kender til GraalVM, er skeptisk overfor platformen. Kritikken går på, at de lovede ydelsesforbedringer i høj grad er opnået ved at 'inline' kode, hvor funktioner skrives ind som mikrokode, i stedet for kald. Om det giver generelle ydelsesforbedringer er tvivlsomt, lyder synspunktet.

Et mål for Graal er at afvikle mange sprog, og det er noget, som JVM-platformen kan i forvejen. Men udover de specielle Graal-versioner af Python med mere, kan Graal som nævnt også afvikle bitkode fra LLVM-kompileren.

Det gør det muligt at afvikle eksempelvis C, C++ og Rust-programmer. Hvorfor man ville ønske at afvikle disse sprog via en virtuel maskine, i stedet for på ‘metallet’, fortæller historien ikke noget om.

Minder om .Net

En deltager på konferencen synes, at det minder om Microsofts CLR-kørselsmiljø til .Net, og det er Oleg Šelajev vist ikke helt uenig i.

Selvom OpenJDK-platformen, som er Javas eget kørselsmiljø, også kan håndtere en lang række sprog, så skal de stadig kompileres til JVM-bytecode.

Det er ikke tilfældet med GraalVM, og derfor giver det mulighed for en større rækkevidde af sprog.

Oleg Šelajev viser, hvordan statistiksproget R kan integreres med Java-kode. Det går nemt og kræver ikke kode inde i tekststrenge eller tilsvarende. På nul komma fem kan han lave en webapplikation i Javas Spring-miljø, der viser en graf, renderet i R ud fra et talmateriale.

Oleg Šelajevs indlæg på JDK IO-konferencen vil blive bragt på Youtube på et senere tidspunkt, oplyser konferencen.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (5)
Sune Marcher

Derudover muliggør miljøet udførelse af ‘født’ kode via kompileren LLVM, der i sig selv understøtter et stort antal sprog.

Hvad menes der med "født" kode?

En ledende ekspert på området

Hvem? :-)

Kritikken går på, at de lovede ydelsesforbedringer i høj grad er opnået ved at 'inline' kode, hvor funktioner skrives ind som mikrokode, i stedet for kald.

Mikrokode lyder ret mystisk i denne sammenhæng - hvad er det oprindelige ordvalg?

Hvorfor man ville ønske at afvikle disse sprog via en virtuel maskine, i stedet for på ‘metallet’, fortæller historien ikke noget om.

Det bliver dog indirekte besvaret lidt senere - "Det går nemt og kræver ikke kode inde i tekststrenge eller tilsvarende.". Det er typisk en omstændelig proces hvis du vil interface Java med native kode. Spørgsmålet er hvor mange der vil tage det til sig - kommer nok til at afhænge af hvor meget nemmere det er (der er trods alt stadig noget med typer der skal matches) og hvordan performance bliver.

Og til slut en lille bøn: vil i ikke nok stoppe med at oversætte native til "indfødt"? Det lyder fjollet, og i bruger alligevel (heldigvis!) engelske termer som fx "ahead-of-time".

Log ind eller Opret konto for at kommentere
Pressemeddelelser

Welcome to the Cloud Integration Enablement Day (Bring your own laptop)

On this track, we will give you the chance to become a "Cloud First" data integration specialist.
15. nov 2017

Silicom i Søborg har fået stærk vind i sejlene…

Silicom Denmark arbejder med cutting-edge teknologier og er helt fremme hvad angår FPGA teknologien, som har eksisteret i over 20 år.
22. sep 2017

Conference: How AI and Machine Learning can accelerate your business growth

Can Artificial Intelligence (AI) and Machine Learning bring actual value to your business? Will it supercharge growth? How do other businesses leverage AI and Machine Learning?
13. sep 2017