Contrairement à C# le code n'est pas interprété par une machine virtuelle, c'est un langage compilé. Pour être plus précis, le compilateur génère de manière intermédiaire du "C", ce qui permet à un logiciel programmé en Vala d'utiliser facilement des bibliothèques en C, ou à l'inverse à une bibliothèque programmée dans un langage qui s'interface avec du "C", de faire appel à une bibliothèque programmée en Vala.
Dès le début ce nouveau langage apportait nativement des fonctionnalités très intéressantes comme :
- Les interfaces
- Les propriétés (spécifique aux GObjects)
- Les signaux (démocratisé par Qt)
- Les expressions Lambda
- Les classe génériques
- La gestion assistée de la mémoire
- La gestion des exceptions
Cette nouvelle mouture apporte deux grosses nouveautés :
- Les closures (version plus puissante des expressions Lambda)
- Les appels asynchrones
Plus d'informations dans la suite de la dépêche. Jürg Billeter et Raffaele Sandrini, les développeurs de vala fournissent quelques exemples des deux nouveautés, dont voici une retranscription en français quelque peu remaniée (cf blog pour la version anglaise) :
Closures
Bien que Vala supporte les expressions lambda depuis longtemps, elles ne permettaient pas d'accéder aux variables locales en dehors du contexte de leur construction.
Avec la version 0.7.6 celà a changé puisque vous pouvez accéder et modifier toutes les variable locales dans les expressions lambda, ce qu'on appelle les closures.
Nous espérons quelles seront utiles pour simplifier l'écriture des gestionnaires de signaux (slots en Qt), comme dans l'exemple ci-dessous :
void main (string[] args) {
Gtk.init (ref args);
var window = new Gtk.Window (Gtk.WindowType.TOPLEVEL);
window.set_default_size (300, 50);
window.destroy.connect (Gtk.main_quit);
var button = new Gtk.Button.with_label ("Click me!");
button.clicked.connect (() => {
window.title = "Closures in Vala";
});
window.add (button);
window.show_all ();
Gtk.main ();
}
Vous pouvez même écrire des expressions lambda récursives :
delegate int Func (int i);
void main () {
Func fib = null;
fib = (i) => (i <= 1) ? i : (fib (i - 2) + fib (i - 1));
for (int i = 0; i < 10; i++) {
message ("%d", fib (i));
}
}
Méthodes asynchrones
Pour simplifier l'écriture de code faisant appel à des fonctions asynchrones nous avons eu l'idée d'intégrer les méthodes asynchrones directement dans le langage.
Les méthodes asynchrones sont fréquemment utilisées dans les API d'entrée/sortie telles que GIO et D-Bus. En général, écrire des programmes asynchrones est considéré difficile, car l'on en arrive vite à écrire des suites de callbacks et l'on perd facilement la trace du flot d'exécution du programme.
La gestion expérimentale des méthodes asynchrones a été développée depuis longtemps en vala. Cependant, cette mise en œuvre relevait plus du prototype qu'autre chose. Bien que l'on s'attende à quelques bugs, avec cette nouvelle mouture, nous avons une implémentation bien plus complète et robuste qu'elle ne l'a été par le passé.
Alors à quoi ça ressemble? Le code suivant définit une méthode asynchrone nommée list_dir qui énumère de manière asynchrone tous les fichiers du répertoire "Home" :
async void list_dir () {
var dir = File.new_for_path (Environment.get_home_dir ());
try {
var e = yield dir.enumerate_children_async (FILE_ATTRIBUTE_STANDARD_NAME, 0, Priority.DEFAULT, null);
while (true) {
var files = yield e.next_files_async (10, Priority.DEFAULT, null);
if (files == null) {
break;
}
foreach (var info in files) {
print ("%s\n", info.get_name ());
}
}
} catch (GLib.Error err) {
warning ("Error: %s\n", err.message);
}
}
void main () {
list_dir.begin ();
var loop = new GLib.MainLoop (null, false);
loop.run();
}
Comme vous pouvez le constater, il est très facile d'appeler les méthodes asynchrones enumerate_children_async et next_files_async que ce soit dans une boucle ou même dans un bloc gérant les exceptions (try-catch). Inutile de s'encombrer avec la création de structures pour les donnée à conserver entre les appels, tout est limpide et intégré au langage.
Aller plus loin
- L'annonce officielle (1 clic)
- Le site de vala (9 clics)
- Tutoriel (6 clics)
- Blog (2 clics)
# Intéressant…
Posté par DLFP est mort . Évalué à 5.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Intéressant…
Posté par Pascal Terjan (site web personnel) . Évalué à 8.
Les developpeurs de Mono utilisent Mono et ne sont pas près d'arrêter...
http://www.vuntz.net/journal/post/2006/08/08/393-gnome-et-mo(...)
[^] # Re: Intéressant…
Posté par bubar🦥 (site web personnel) . Évalué à 2.
Mais ça me semble mal barré dans la mesure ou là le concurrent est en constante évolution (pas les mêmes besoins que samba), j' ai bien peur que Mono ne fasse que suivre, éternellement. Ou alors tout le monde se met à coder en Mono, et là on a que du compatible, tout le temps. Là, encore plus, ça relève de l'utopie.
Mais ça serait pas un mal, ouaih, que les distributions arrêtes d'inclure les applications mono pour gnome par défaut, car de plus elles n'apportent rien de spécial que d'autre ne sachent faire. (un mail presque au hasard : http://www.mail-archive.com/gnewsense-dev@nongnu.org/msg0088(...) )
Perso, je préfère largement Adobe Air à Mono ;) au moins ça se développe partout pareil, ça marche partout pareil et ça avance à visage découvert. \o/
[^] # Re: Intéressant…
Posté par gnumdk (site web personnel) . Évalué à 2.
>C'est à dire un élément se posant à égalité avec son concurrent
Faut peut être pas abuser... Actuellement, Samba3 tel qu'il est livré dans les distributions GNU/Linux fait pale figure face à un serveur Windows 2008 et l'ensemble des technologies fournis par ce dernier pour les clients Windows...
Samba4, y'a du mieux, mais il semble que cela ne soit pas encore génial au niveau de la gestion des GPO...
Actuellement, une solution offrant le même niveau de service qu'un serveur Microsoft, y'a SambaEdu3:
- Déploiement de GPO via machine, utilisateur, groupe, parcs, ...
- Déploiement d'imprimantes via machine, utilisateur, groupe, parcs, ...
- Déploiement d'applications via machine, utilisateur, groupe, parcs, ... (wpkg)
Seul hic, SambaEdu est trop lié à l'utilisation en collèges/Lycées pour l'utilisant dans un autre contexte... Et arrivé au niveau de fonctionnalité de ce dernier sur un Samba de base, y'a une quantité énorme de travail.
SambaEdu.org: http://wwdeb.crdp.ac-caen.fr/mediase3/index.php/Accueil
[^] # Re: Intéressant…
Posté par bubar🦥 (site web personnel) . Évalué à 3.
En tout cas, merci pour le lien vers SambaEdu
[^] # Re: Intéressant…
Posté par Gniarf . Évalué à 3.
> > C'est à dire un élément se posant à égalité avec son concurrent
> Faut peut être pas abuser... Actuellement, Samba3 tel qu'il est livré
> dans les distributions GNU/Linux fait pale figure face à un serveur
> Windows 2008 et l'ensemble des technologies fournis par ce dernier
> pour les clients Windows...
genre planter ou redémarrer le serveur à distance si on lui envoie le bon petit paquet qui va bien ?
merci du cadeau, hein.
# je suis pas convaincue
Posté par turanga leela . Évalué à 3.
D'une manière générale, n'est il pas plus intéressant d'utiliser de très bonnes lib comme Qt plutôt que des langage de 17ième niveau??
Si vous me répondez non, je jure de me mettre au vala.
[^] # Re: je suis pas convaincue
Posté par Pascal Terjan (site web personnel) . Évalué à 2.
Ca genere du C, ensuite ça compile le C comme si tu avais écrit le C et les performances sont les mêmes.
[^] # Re: je suis pas convaincue
Posté par FantastIX . Évalué à -5.
[Jean-Pierre Troll! Au secours!]
[^] # Re: je suis pas convaincue
Posté par mickabouille . Évalué à 3.
[^] # Re: je suis pas convaincue
Posté par lasher . Évalué à 10.
[^] # Re: je suis pas convaincue
Posté par FantastIX . Évalué à -1.
[^] # Re: je suis pas convaincue
Posté par Christophe Duparquet (site web personnel) . Évalué à 8.
Dans un temps illimité, soit. Mais en temps limité, je ne me mesurerais pas à un compilo.
Vu la complexité du moindre CPU actuel (et c'est valable pour les MCU), il faut prendre en compte tellement de paramètres (temps d'exécution d'une séquence en fonction du choix des registres, remplissage du cache, et sûrement d'autres trucs que j'ignore) que la machine fait finalement du bon boulot.
J'ai pu le constater sur avr-gcc en voulant réécrire du code en assembleur. Les choix du compilo (qui en plus n'est pas le plus abouti) ne sont pas tous idiots, loin de là, mais ça ne saute pas au yeux.
Maintenant, en ce qui concerne l'efficacité des langages évolués, je pense qu'au contraire, ils permettent au compilo de faire de meilleurs choix car le code fourni par le programmeur est alors plus proche de la description du problème et s'éloigne de la fourniture d'une solution qui peut orienter le compilo vers une direction moins optimale. Un peu comme ce que je disais au dessus, en fait.
Pour en revenir à vala, sans le connaître, je l'imagine comme un préprocesseur très évolué. Donc pas de perte de performance.
Je crois me souvenir que l'élaboration de C++ est passée par un préprocesseur du même genre, qui gobait du « C with classes » pour en faire du C K&R. Je peux me tromper !
« J'ai pas Word, j'ai pas Windows, et j'ai pas la télé ! »
[^] # Re: je suis pas convaincue
Posté par FantastIX . Évalué à -2.
[^] # Re: je suis pas convaincue
Posté par Kerro . Évalué à 8.
Bien entendu, sur un petit nombre d'exemples soigneusement choisis, l'humain fait mieux... mais ça prends 50 ou 100 fois plus de temps. Et sur tous les autres exemples, l'humain fait jeu égal ou moins bien.
Les compilateurs actuels sont _vraiment_ puissants. Et quand je dis actuels, ça vaut en fait depuis des années. Au milieu des années 90 déjà, il fallait s'accrocher pour produire du code au moins aussi bon que le Watcom C par exemple.
[^] # Re: je suis pas convaincue
Posté par lasher . Évalué à 2.
Un compilateur sur une machine Out-of-Order a justement *moins* de boulot à fournir, vu que le moteur OoO matériel se charge de rendre moins moche un code « mal généré ».
Pour donner un ordre d'idée, sur une archi certes quasi-morte, à savoir l'Itanium 2, la qualité du code généré par gcc comparée à celle d'icc [1] est carrément lamentable. Le compilateur d'Intel dans ce cas est en moyenne 3 fois plus performant que gcc. Bien sûr, il y a plusieurs raisons :
1/ Plus de dévs pour gcc/x86 (mais là je renvoie à gcc/PowerPC qui se débrouille plutôt bien, et je suis sûr que l'OoO y est pour beaucoup)
2/ L'Itanium 2 n'est pas une machine très répandue (et pour cause), ce qui est finalement une variation sur 1/. :)
N'empêche : l'Itanium 2 a une architecture VLIW et superscalaire, et dont les seules opérations out-of-order sont liées à la mémoire. Presque tout est laissé au compilateur, et si celui-ci se débrouille mal pour la génération de code, alors le programme résultant sera vraiment mauvais.
Sur x86, l'OoO limite vraiment la casse.
[1] Le compilateur du constructeur (Intel), donc évidemment il y a un avantage net pour ce dernier, qui possède le modèle machine du CPU
[^] # Re: je suis pas convaincue
Posté par thedude . Évalué à 1.
Apple aurait pas file un coup de pouce a gcc sur ppc?
C'est une question, xcode ayant longtemps utilise gcc, je me dit qu'ils ont du bosser sur le compilo pour en faire qq chose de bien.
[^] # Re: je suis pas convaincue
Posté par lasher . Évalué à 2.
[^] # Re: je suis pas convaincue
Posté par Mildred (site web personnel) . Évalué à 3.
Même gcc utilise du code intermédiaire, il n'est ni écrit, ni spécifié, mais c'est du code intermédiaire.
[^] # Re: je suis pas convaincue
Posté par Kerro . Évalué à 8.
Il y a bien entendu des exceptions, mais elles restent rares.
Cela est valable même si on programme mal. Un mauvais programmeur en C donnera un programme plus lent (ou plus gros, etc) qu'un bon programmeur en assembleur. Mais le mauvais programmeur en C, si il avait fait le code en assembleur, aurait produit également quelque chose de très mauvais.
Reste que les langage dits de haut niveau ne sont pas faits pour être plus performants, mais pour coder plus vite. Ce qui, dans beaucoup de cas, est un atout considérable.
[^] # Re: je suis pas convaincue
Posté par Pinaraf . Évalué à 9.
Non, l'assembleur est juste une représentation humaine du code machine. On ne compile pas l'assembleur en code machine, on le "traduit", et cette traduction est réversible sans que cela n'entraîne de différences sur le contenu.
[^] # Re: je suis pas convaincue
Posté par lasher . Évalué à 1.
[^] # Re: je suis pas convaincue
Posté par Kerro . Évalué à 4.
Il y a même du code pur et dur qui est traduit en fonction du contexte.
Exemple tout bête: jmp mon_etiquette peut être traduit en saut relatif "short" (0xeb) ou "near" (0xe9). Autrefois il y avait même le jump far (0xea). Même chose pour call. Tu peux préciser jump short ou jump near si tu le souhaites, dans ce cas tu as une traduction de 1 vers 1, mais tu perds la souplesse offerte par le compilateur.
Et justement, un compilateur C écrit des jmp, donc il délègue au compilateur assembleur le choix de la bonne instruction finale. Ce n'est pas le boulot d'un compilateur de haut niveau de savoir si la cible d'un saut est proche ou non.
[^] # Re: je suis pas convaincue
Posté par ecyrbe . Évalué à 5.
C'est là l'un des gros atouts de vala, pas de perte de performance. Les développeurs de vala ont justement conçu le langage pour que le mapping en C soit très proche de ce que l'on écrit nativement.
En regardant de près le code généré, on remarque qu'il y a quelques différences par rapport à ce que l'on écrirait à la main.
- Les boucles for sont traduites en boucles while ce qui peu réduire les chances de voir les boucles statiques optimisée par le compilateur.
- les déréférencements ont systématiquement un test pour vérifier que le pointeur n'est pas null, chose qui ne pourrait être vérifié qu'une fois.
je ne doute pas qu'il y a d'autres points ou la transcription n'est pas (encore) parfaite, mais il me semble aussi que ces points sont facilement améliorable, et ne remet pas en cause le fait qu'on peut générer un code C aussi rapide que celui qu'on aurait écrit à la main.
[^] # Re: je suis pas convaincue
Posté par patrick_g (site web personnel) . Évalué à 4.
Je suppose que tu voulais écrire "les déréférencements ont systématiquement un test pour vérifier que le pointeur n'est pas null, chose qui pourrait n'être vérifié qu'une fois" ?.
[^] # Re: je suis pas convaincue
Posté par ecyrbe . Évalué à 2.
[^] # Re: je suis pas convaincue
Posté par Guillaume Knispel . Évalué à 3.
[^] # Re: je suis pas convaincue
Posté par lasher . Évalué à 10.
[^] # Re: je suis pas convaincue
Posté par domak . Évalué à 2.
[^] # Re: je suis pas convaincue
Posté par BAud (site web personnel) . Évalué à 3.
tu n'as pas vu http://linuxfr.org/2009/09/19/25933.html
ni http://linuxfr.org/~patrick_g/28661.html
ni tous les autres ?
[^] # Re: je suis pas convaincue
Posté par domak . Évalué à 3.
[^] # Re: je suis pas convaincue
Posté par Thomas Douillard . Évalué à 2.
Pour ça le code aurait été tellement différent que comparer les performances respectives des deux langages à pas de sens, si tu prends pas en compte la facilité de debuggage, de codage, etc.
[^] # Re: je suis pas convaincue
Posté par benoar . Évalué à 3.
[^] # Re: je suis pas convaincue
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
En gros, si la nested function est executé en dehors de la fonction qui la créer la pile d'appel n'a plus aucun sens. Une vrai closure doit gérer ce cas-là (Lisaac le fait pour les types blocs).
"La première sécurité est la liberté"
[^] # Re: je suis pas convaincue
Posté par benoar . Évalué à 5.
Pour moi, Vala n'est qu'une surcouche qui ne réimplémente pas des choses aussi fondamentales que ça. Peut-être que je me trompe, je ne connais pas vraiment bien le projet, mais j'aimerais bien savoir alors comment il fait.
Ha, et une petite remarque désargéable (oui, j'aime bien être désagréable) : citer Lisaac pour ça alors que pleins d'autres langages plus connus (à peu près tous les langages fonctionnels, .Net, Scala et plein d'autres) le gèrent, ça fait un peu fanboy de Lisaac .... (oui, je dois avoir l'air d'un fanboy Scala)
[^] # Re: je suis pas convaincue
Posté par Antoine . Évalué à 4.
Pas besoin de sauvegarder toute la pile, juste les variables de la fermeture. En général il y en a seulement quelques-unes, et tu les connais à l'avance (lors de la compilation). Tu peux donc déléguer l'accès à ces variables à une structure ad hoc, passée en paramètre caché de ta fonction-fermeture (un peu comme le "this" caché de tes méthodes, d'ailleurs un objet n'est rien d'autre qu'une fermeture un peu retournée).
(oui, je dois avoir l'air d'un fanboy Scala)
Oui, vu que de toute façon Python et Ruby (et probablement Perl) gèrent aussi les fermetures.
[^] # Re: je suis pas convaincue
Posté par Mildred (site web personnel) . Évalué à 1.
En gros, si la nested function est executé en dehors de la fonction qui la créer la pile d'appel n'a plus aucun sens. Une vrai closure doit gérer ce cas-là (Lisaac le fait pour les types blocs).
Tu veux me dire que comme vala, les block Lisaac peuvent accéder à des variables définies en dehors du block (upvalue), même si ces variables ne sont plus dans la pile au moment où le block est appelé ?
Je ne pense pas que ce soit le cas ...
Cela voudrait dire une allocation dans le tas.
[^] # Re: je suis pas convaincue
Posté par Watchwolf . Évalué à 3.
[^] # Re: je suis pas convaincue
Posté par Kangs . Évalué à 3.
Si un jour suffisamment de gens estiment que Vala tient la route tu auras un compilateur Vala (un front-end gcc par exemple)
[^] # Re: je suis pas convaincue
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Et puis, on utilise Qt mais Qt est une surcouche au C++ et le code doit être précompilé avec moc avant de pouvoir être compilé avec gcc. Donc finalement, Vala reprend un peu la même approche...
[^] # Re: je suis pas convaincue
Posté par Larry Cow . Évalué à 6.
Un peu seulement. Parce qu'avec Qt, on a très largement du C++ "normal", avec juste une adjonction - qui aurait été possible en C++ pur, mais syntaxiquement lourde - pour le principe des signaux/slots.
Ici, on a un langage "complet", avec sa propre syntaxe - certes inspirée du C# - qui est transformé en un autre langage.
En gros, Qt n'est pas un langage. C'est juste une bibliothèque (ou un ensemble de) qui s'autorise une petite déviation par rapport au langage "officiel" et fournit les outils pour que cette déviation soit indolore.
[^] # Re: je suis pas convaincue
Posté par Gof (site web personnel) . Évalué à 5.
Le moc lis les fichier en-tête, et génère le code des signaux et celui nécessaire pour l'introspection. Le code généré est sous la forme d'une autre fichier C++ à adjoindre à la compilation.
Le code que l'on écrit quand on fait de la programmation avec Qt est du C++ pur et est directement compilé par GCC.
Le code que l'on écrit en Vala est traduit en C avant d'être compilé
[^] # Re: je suis pas convaincue
Posté par Krunch (site web personnel) . Évalué à -1.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: je suis pas convaincue
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Le code écrit pour Qt n'est pas du C++ pur car tu ne peux pas le compiler avec n'importe quel compilateur si tu n'est pas passé par la moulinette moc avant. Je t'accorde cependant que le dialecte de Qt est très proche du C++, c'est une simple extension alors que Vala est plus un traducteur.
[^] # Re: je suis pas convaincue
Posté par Gof (site web personnel) . Évalué à 5.
(Et utiliser les outils d'analyse statique de code, ou les éditeurs spécialisés dans le C++)
Par contre, si tu ne lance pas le moc, ça ne passeara pas l'étape de l'édition des liens car le linkeur te dira qu'il manque des symboles.
[^] # Re: je suis pas convaincue
Posté par benoar . Évalué à 2.
#include
class Counter : public QObject
{
Q_OBJECT
public:
Counter() { m_value = 0; }
int value() const { return m_value; }
public slots:
void setValue(int value);
signals:
void valueChanged(int newValue);
private:
int m_value;
};
(extrait de http://doc.trolltech.com/4.4/signalsandslots.html )peut passer _syntaxiquement_ dans un compilo C++ standard ? (en particulier les public slots et signals ...)
C'est considéré comme des labels que MOC utilise au moment du link ?!?
[^] # Re: je suis pas convaincue
Posté par Littleboy . Évalué à 4.
Partie "Building the example", quelques dizaines de lignes en dessous du code que tu as copier-coller:
The C++ preprocessor changes or removes the signals, slots, and emit keywords so that the compiler is presented with standard C++.
puis
By running the moc on class definitions that contain signals or slots, a C++ source file is produced which should be compiled and linked with the other object files for the application.
ce qui est tres exactement ce que decrit Gof.
Je pense que dans ta hâte a critiquer QT, tu as oublie que tout compilateur C++ est egalement dote d'un preprocesseur qui permet l'ecriture de macros. Cela-dit c'est pas grave, on t'en veut pas :P
Tiens, le liens direct vers le fichier source avec les definitions pour slots et signal (tu vas voir, c'est pas tres complique...):
http://qt.gitorious.org/qt/qt/blobs/master/src/corelib/kerne(...)
[^] # Re: je suis pas convaincue
Posté par benoar . Évalué à 2.
Oui c'est exactement ça /o\
Vous pouvez me moinsser.
Merci pour ces infos !
[^] # Re: je suis pas convaincue
Posté par Mildred (site web personnel) . Évalué à 2.
#define slots /*nothing*/
#define signals /*nothing*/
Ce sont juste des mots-clefs supprimés par le préprocesseur C++ qui sont là pour que le compilateur moc comprenne où sont les signaux et les slots.
[^] # Re: je suis pas convaincue
Posté par Alexis Ménard (site web personnel) . Évalué à 2.
[^] # Re: je suis pas convaincue
Posté par ecyrbe . Évalué à -1.
Le fait qu'il y ait un code intermédiaire en C à été voulu par les concepteurs du langage.
En fait, toutes les librairies au dessus GObject (comme Gtk) pourraient être réimplémenté en Vala et continuer à avoir une ABI et une API compatible avec celle d'aujourd'hui.
[^] # Re: je suis pas convaincue
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
L'objectif de GTK et maintenant de GNOME est d'avoir les bases en C pour pouvoir programmer les applications dans le langage que l'on souhaite. Cependant, les bases doivent rester en C.
[^] # Re: je suis pas convaincue
Posté par ecyrbe . Évalué à 2.
Les langage de script resteront compatible. c'est la beauté de Vala.
[^] # Re: je suis pas convaincue
Posté par jeberger (site web personnel) . Évalué à 1.
[^] # Re: je suis pas convaincue
Posté par Clément David (site web personnel) . Évalué à 1.
Quand tu écris du Vala, le code généré est *très* lisible et permet de comprendre le travail réalisé derrière. De plus des 'binding' antre langages automatiques sont réalisés grâce aux capacités de GObject pour l'introspection, cf [http://live.gnome.org/GObjectIntrospection].
Une autre approche est d'utiliser un générateur d'interface tel que SWIG [http://www.swig.org] mais, personnellement je trouve cette approche très lourde par rapport à l'introspection.
[^] # Re: je suis pas convaincue
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
As tu des exemples qui sont utilisés courament (or de la mouvance Qt et KDE) ?
[^] # Re: je suis pas convaincue
Posté par alberthier (site web personnel) . Évalué à 1.
.NET ou Java utilisent leur bytecode comme dénominateur commun pour que les bibliothèques puissent être utilisables sur tous les langages de la plateforme.
La plateforme GNOME utilise le C. Vala produit du C, celui-ci peut être passé dans les moulinettes automatiques qui génèrent les bindings C++, Python, etc...
[^] # Re: je suis pas convaincue
Posté par jeberger (site web personnel) . Évalué à 2.
Attention, relis bien ce que j'ai écrit: je n'ai pas dit qu'il était possible de prendre n'importe quelle bibliothèque écrite dans n'importe quel langage et de la réutiliser dans n'importe quel autre langage! J'ai dit qu'il était possible d'écrire une bibliothèque en C++ ou en Haskell de telle sorte qu'elle soit utilisable depuis un programme C. Et dans ce cas elle devient effectivement utilisable dans la majorité des langages.
Rien n'empêche Vala de faire pareil si ils veulent développer un compilateur natif.
PS: Je ne dis pas qu'ils devraient le faire, hein? Juste qu'il peuvent le faire sans perdre la compatibilité C.
# Performances
Posté par ecyrbe . Évalué à 1.
http://code.google.com/p/vala-benchmarks/wiki/BenchResults
[^] # Re: Performances
Posté par JoeltheLion (site web personnel) . Évalué à 3.
[^] # Re: Performances
Posté par ecyrbe . Évalué à 2.
Ceci explique qu'ils utilisent les même benchmarks.
[^] # Re: Performances
Posté par Clément David (site web personnel) . Évalué à 3.
À l'origine ma démarche a été de discuter avec Isaac Gouy du shootout (voir [http://alioth.debian.org/forum/forum.php?thread_id=3619&(...)]) cependant celui-ci n'a pas jugé le Vala comme langage intéressant pour son projet. J'ai donc lancé [http://code.google.com/p/vala-benchmarks/] pour écrire l'ensemble des tests avec comme but final d'être intégré au shootout.
Actuellement un certains nombre de tests ont été implémentés et on permis de fournir une base d'exemple de code.
[^] # Re: Performances
Posté par Stéphane Klein (site web personnel) . Évalué à 1.
[^] # Re: Performances
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
En même temps, c'est complexe de trouver un test d'un milliers de ligne maximum qui met en avant les performances objets d'un langage.
Il faudrait mettre en avant les perfs d'héritage, des redéfinitions de fonctions (le virtuel du c++), etc... Bref, les perfs des fonctions avancées objet.
Je pensais bien à un système de factory qui utilise ensuite les objets créés. Mais ce n'est pas évident de définir qqch qui n'est pas trop artificiel.
"La première sécurité est la liberté"
[^] # Re: Performances
Posté par Antoine . Évalué à 3.
[^] # Re: Performances
Posté par Clément David (site web personnel) . Évalué à 3.
Pour obtenir les meilleures performances du code généré, j'ai du effectuer un choix parmi les différents types de classes :
- héritant de GObject (publiques et enregistrées dans GObject)
public class MyClass : Object {
...
}
- implémentant GObject par le compilateur (publiques)
public class MyClass {
...
}
- implémentant GObject partiellement par le compilateur
[Compact]
public class MyClass {
...
}
- passant les paramètres par valeur
public struct MyClass {
...
}
Tu peux t'amuser avec les différents façon et tu observera une différence réelle dans ce test. Le Vala a ainsi l'avantage de te laisser choisir l'implémentation en C par construction ce que ne permettent pas d'autres langages.
Il faut aussi te méfier avec des tests comme ceux-ci car les performances lors de la construction dépendent de la librairie GObject donc de la façon de la compiler. Pour ce benchmark je me suis restreint à la distribution par défaut dans Debian Squeeze.
[^] # Re: Performancesvv
Posté par Thomas Douillard . Évalué à 3.
Ben non, en ajoutant une couche objet en C "human readable" on perd quand même en perf par rapport à une implémentation plus maligne de la même couche objet ...
[^] # Re: Performancesvv
Posté par Clément David (site web personnel) . Évalué à 1.
Il y a un rajout de code et de temps d'exécution mais dans une application réelle, tu ne fait pas qu'allouer ou désallouer des objets, non ? Ainsi quand on fait une somme sur l'ensemble des tests implémentés, le Vala s'approche du C.
Concernant le fait de rajouter une couche objet plus maligne, il faut bien différencier deux choses :
- une implémentation à tendance statique, style C++
- une implémentation à tendance dynamique, style Objective-C ; Java ; .NET ; GObject
Donc en soit on ne peut pas vraiment comparer C++ et C/GObject car le fonctionnement est différent. Personnellement, j'ai voulu comparer l'impact d'une machine virtuelle en conservant une environnement haut-niveau équivalent (Vala vs C#), le C++ a été ajouté par la suite.
# C# pas interprété
Posté par TImaniac (site web personnel) . Évalué à 7.
C# n'a jamais été conçu pour être interprété mais pour être compilé dans un code intermédiaire qui est lui même compilé à la volée (JIT), voir en avance (AOT).
L'interprétation, c'est totalement has been, ca sert uniquement à porter "rapidement" un langage sur une nouvelle plateforme matérielle en attendant une chaîne de compilation native.
[^] # Re: C# pas interprété
Posté par ecyrbe . Évalué à 3.
En C# le byte-code est donc bien interprété, cette interprétation utilise la technologie JIT qui permet de gagner en performance, mais celà ne rend pas ma phrase fausse pour autant.
[^] # Re: C# pas interprété
Posté par ecyrbe . Évalué à 1.
[^] # Re: C# pas interprété
Posté par TImaniac (site web personnel) . Évalué à 4.
Je vois pas le rapport entre le premier et le 2ème paragraphe.
La présence d'une machine virtuelle ou d'un environnement d'exécution ne défini en rien le fait que C# soit interprété.
cette interprétation utilise la technologie JIT qui permet de gagner en performance
JIT est une technique de "compilation", pas d'interprétation.
C'est même dans le nom : http://en.wikipedia.org/wiki/Just-in-time_compilation
je cite : "It converts code at runtime prior to executing it natively, for example bytecode into native machine code. The performance improvement over interpreters originates from caching the results of translating blocks of code, and not simply reevaluating each line or operand each time it is met (see Interpreted language)."
Ce qui se traduit par :
"Il converti le code pendant son déroulement avant de l'exécuter nativement, par exemple il converti le bytecode en code natif. Le gain de performance par rapport aux interpréteurs vient du fait de mettre en cache le résultat de la tranduction de bloc de code plutôt que de réévaluer chaque ligne ou opérateur à chaque fois qu'il le rencontre. (voir langage interprété)."
La compilation et l'interprétation sont 2 techniques différentes pour exécuter du code. Que la compilation se fasse en 2 étapes pour ajouter un niveau d'abstraction (machine virtuelle) ne change rien.
C# est un langage conçu pour être compilé en ciblant la CLI et cette dernière est conçue pour compiler du bytecode en code natif.
Il est possible d'interpréter le bytecode intermédaire, mais l'intérêt est limité. La page de mono sur l'environnement d'exécution décrit bien les différentes techniques utilisées et précise à propos de l'interpréteur :
http://www.mono-project.com/Mono:Runtime
"Mono has both an optimizing just-in-time (JIT) runtime and a interpreter runtime. The interpreter runtime is far less complex and is primarily used in the early stages before a JIT version for that architecture is constructed. The interpreter is not supported on architectures where the JIT has been ported. "
Ce qui se traduit par :
Mono a un moteur d'exécution optimisé à la volée (JIT) et un interpréteur. L'interpréteur est beaucoup moins complexe et est avant tout utilisé en amont avant qu'une version du moteur JIT pour l'architecture cible soit construit. L'interpréteur n'est pas supporté sur les architectures où le moteur JIT a été porté.
# Et le déboguage ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 8.
Ma question est de savoir comment Vala gère cet aspect ?
[^] # Re: Et le déboguage ?
Posté par Clément David (site web personnel) . Évalué à 3.
Il existe un patch pour gdb qui permet de déverminer facilement du code Vala [http://abderrahim.arablug.org/blog/archives/8-GDB-Vala-suppo(...)]. Cependant l'utilité de ce patch est, pour moi, réduite car Vala utilise des conventions simples.
Un autre aspect qui facilite la prise en main d'un exécutable est l'inclusion dans le langage de pre, post -conditions et invariants ce qui facilite le déverminage. On peut aussi noter la conservation des commentaires ce qui permet de facilement retrouver la translation d'un algorithme particulier.
En résumé, actuellement la déverminage se passe sur la mailing-list car la majorité des utilisateur lise du C facilement.
[^] # Re: Et le déboguage ?
Posté par gentildemon . Évalué à 2.
N'y a-t'il pas des cas où l'erreur est détectée seulement au moment de la compilation du code C ?
[^] # Re: Et le déboguage ?
Posté par DitOuQueMon . Évalué à 2.
Après, si valac génère effectivement un code contenant des erreurs de syntaxes, je crois qu'on peut considérer ça comme un bogue :-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.