IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

GraalVM permet de transformer une application Java en binaire natif de 7 Mo
Qui s'exécute en moins de 30 ms et tourne sur 4 Mo de RAM

Le , par Patrick Ruiz

287PARTAGES

13  0 
GraalVM 1.0 est disponible depuis la mi-avril. Dans son billet introductif, Oracle explique que la nouvelle machine virtuelle a pour vocation de fournir le plus haut niveau de performances et d’interopérabilité pour tous les langages de programmation pris en charge.

« GraalVM est une machine virtuelle universelle pour exécuter des applications écrites en JavaScript, Python, Ruby, R, les langages qui s’appuient sur la JVM comme Java, Scala, Kotlin et les langages LLVM comme C et C++, » peut-on lire sur le site du projet.

Qu’en est-il réellement du niveau de performances et d’interopérabilité que cet outil permet d’atteindre ? Un test indépendant apporte la lumière, notamment, sur l’un des cas d’utilisation prévus par le géant des bases de données : la génération de binaires natifs, c’est-à-dire destinés à être directement exécutés par une architecture particulière de processeur.

Le test proposé porte sur la comparaison des performances entre l’application ligne de commande RawHTTP (tournant sur la JVM) et la version native obtenue avec la machine virtuelle GraalVM. Dans les chiffres, l’application client native permet d’émettre une requête HTTP et d’afficher le résultat en moins de 30 millisecondes. En comparaison, il faut pratiquement dix fois plus de temps à l’application Java pour accéder à la même ressource. L’auteur du test a consigné les résultats pour une requête GET au sein d’un tableau récapitulatif dans lequel on peut voir que l’application native exhibe des performances qui, sous certaines conditions, peuvent battre celles obtenues en faisant usage d’un outil comme curl.

Mémoire (Mo) Temps de démarrage (ms) Temps de réponse (ms)
curl 4,93 10 38
java -jar 37,57 340 318
Image native 4,84 10 28


L’application native serveur exhibe elle aussi des performances de gain notables en comparaison à la version Java et un serveur Apache. Le tableau récapitulatif consigne l’empreinte mémoire utilisée dans chacun des cas, ainsi que le temps de démarrage et la charge de travail.

Mémoire Temps de démarrage (ms) Nombre moyen de requêtes par seconde
Serveur Apache Inconnu 530 1241,16
java -jar 68,07 568 794,57
Image native 16,12 68,3 1719,19


Grosso modo, l’outil semble tenir les promesses faites par Oracle. Il faudra seulement noter qu’il n’est pas encore prêt pour un usage dans la majorité des cas. Le compilateur de binaires natifs est encore frappé par certaines limitations : il ne prend pas correctement l’API de réflexion et les paquetages Java de sécurité pour le moment.

Les tests sont entièrement reproductibles. Il faudra s’assurer d’avoir Java SE 8+ installé sur son système. L’application Java est disponible au sein de l’archive rawhttp.jar. Pour les besoins du test du client sous Linux, notamment, pour savoir quel est son temps de démarrage, il faudra jongler avec le code qui suit en remplaçant les gdate avec date, sinon le code ne tournera que sur OS X.

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
#!/bin/bash

# command that tests that the server is accepting connections
CMD="curl localhost:8082 >& /dev/null"

START_TIME=$(gdate +%s%3N)

# start the server
../rawhttp serve . -p 8082 &
SERVER_PID=$!

STEP=0.001 # sleep between tries, in seconds
TRIES=500
eval ${CMD}
while [[ $? -ne 0 ]]; do
((TRIES--))
echo -ne "Tries left: $TRIES"\\r
if [[ TRIES -eq 0 ]]; then
echo "Server not started within timeout"
exit 1
fi
sleep ${STEP}
eval ${CMD}
done

END_TIME=$(gdate +%s%3N)
TIME=$(($END_TIME - $START_TIME))
echo "Server connected in $TIME ms"
#./rawhttp send -t "GET localhost:8082/hello"

kill ${SERVER_PID}
Télécharger rawhttp.jar ici

Sources : sites.google, GitHub

Et vous ?

Quelle crédibilité accordez-vous aux résultats de ces tests ? Avez-vous personnellement testé cette machine virtuelle depuis l’annonce de sa disponibilité ? Si oui, quel retour pouvez-vous faire ?

Voir aussi :

GraalVM : Oracle annonce une machine virtuelle polyglotte conçue pour supporter plusieurs langages sans sacrifier la performance

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de grunk
Modérateur https://www.developpez.com
Le 30/05/2018 à 8:29
Plus de 300ms pour recevoir une réponse à un GET ca me parait quand même étrange. Faudrait voir à partir de quand il fait sa mesure , mais si c'était vraiment le cas personne n'utiliserais java pour faire des requêtes http.

Le temps de démarrage est sympa , mais ca n'a pas vraiment d'importance, sauf peut êtr edans le cas d'un script qu'on lancerait en boucle.
0  0 
Avatar de forthx
Membre éprouvé https://www.developpez.com
Le 30/05/2018 à 11:45
ca me donne envie de tester ... par curiosité
0  0 
Avatar de Theta
Membre éclairé https://www.developpez.com
Le 30/05/2018 à 17:01
Un interpréteur R qui ne pèse pas les 200mo de la version officielle serait vraiment utile. Notamment pour faire des applications qui ne demandent pas que R soit installé sur la machine (l'interpréteur étant inclus dans l'application).

Malheuresement GraalVM ne semble pas compatible windows, ce qui limite cette utilisation.
0  0