Passer au contenu

GCC 3.0 compile nativement Java

La nouvelle version du compilateur GCC accueille le langage Java et le processeur Itanium 64 bits. Les performances du code Java compilé de manière native font rougir de honte les différentes machines virtuelles Java.

Nettement moins médiatisée que la sortie d’un noyau Linux ou Apache, une nouvelle version de GCC n’en constitue pas moins un événement majeur pour la communauté engagée dans l’Open Source. Le GCC, sigle de GNU Compiler Collection, est en effet une pièce maîtresse pour la construction des logiciels, libres ou non. C’est lui qui permet de faire tourner l’immense majorité des composants ou des noyaux Linux et FreeBSD, sans oublier Apache, Samba, Squid, KDE ou Gnome. GCC est une suite de compilateurs, portables et multiplates-formes, pour les principaux langages de programmation : C, C++, Fortran et, désormais, Java. Très portable, il peut produire du code pour pratiquement tous les systèmes : les principaux Unix, Windows, BeOS, QNX et même Palm.La technique de Cross-compilation permet à GCC de tourner sur un système, tout en produisant du code destiné à un autre type de machine. Sous l’appellation Canadian-cross, il peut même générer, depuis un système A, une version pour un système B, qui produira du code pour un autre système C.Il est courant de générer un GCC pour Sun ou Windows à partir d’un système Linux. De nouveaux processeurs sont supportés pour la génération de code. L’Itanium 64 bits côtoie ainsi les dernières moutures Motorola, Atmel, Mitsubishi, Fujitsu, Sun ou AMD. Comme pour les précédentes versions, il peut se “bootstrapper”, c’est-à-dire se régénérer à partir de versions plus anciennes. Il a été construit sur Linux à partir de la version 2.96 livrée avec Red Hat. L’opération se passe sans histoires, via les traditionnels Configure et Make, à condition que 500 Mo de disque soient libres pour la compilation. Le code généré en C est compatible avec celui des versions précédentes, ce qui n’est pas le cas du C++.La nouvelle ABI (Application binary interface) impose la recompilation de toutes les bibliothèques utilisant ce langage. Red Hat avait commis l’erreur de livrer prématurément la version 2.96, dont l’ABI n’était pas totalement finalisée. Il faudra refaire le travail pour cette version définitive. C’est pour cette même raison que les architectes de la distribution Linux Debian ont décidé de ne pas utiliser GCC 3.0 pour la future version Debian 3.0.

Java et C++ au coude à coude

Les performances, au moins sur l’architecture Intel, n’ont pas bénéficié d’améliorations spectaculaires. Sur notre test favori, un interprète Lisp écrit en C, nous avons même remarqué une légère dégradation des performances, d’environ 1 % pour une taille de code à peine supérieure. L’excellente nouvelle vient du langage Java. GCC a fait le choix de compiler nativement le code Java sans passer par l’intermédiaire d’une machine virtuelle. Si la portabilité s’en ressent ?” il faut recompiler le code pour chaque architecture processeur cible ?”, les performances sont, en revanche, au rendez-vous. Nous avons utilisé deux versions optimisées du crible d’Eratosthène, l’une en C++, l’autre en Java, pour mesurer la vitesse. Pour la première fois, Java fait jeu égal avec C++, celui-ci bénéficiant d’un écart de performances de 10 % seulement. Java se permet même de générer un exécutable nettement plus petit (10 Ko contre 37 Ko pour C++) pour un encombrement mémoire quand même plus important (13 Mo contre 8 Mo). Si la partie du langage et des bibliothèques de base est à peu près complète, les bibliothèques AWT, et surtout Swings, sont encore en chantier.

🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.


Christian Jullien