Mono/fr

/fr

Le "Mono pour Second Life" fait référence à une mise à jour des simulateurs susceptibles d’accroître significativement la vitesse d’exécution des scripts — en particulier les scripts de calculs intensifs. Le Linden Scripting Language ( LSL ) restera identique *, de façon à ce que les scripts existants continuent de fonctionner à l’identique, mais plus rapidement. La pierre angulaire de cette optimisation repose sur l’utilisation d’une nouvelle machine virtuelle open-source appelée Mono.

Mono sera déployé sur la grille principale avec la version 1.24 des serveurs, planifiée le 10 aout. En attendant, Mono peut être testé sur la grille Beta. (cf plus bas).

Vous pouvez également regarder des videos illustrant les impacts de mono.

Comment fonctionnent les scripts LSL

Tout vos scripts sont exécutés par un simulateur (des serveurs Linden Lab) sur lesquels tournent également la région sur laquelle vous vous trouvez. Après une téléportation ou en cas de traversée de région, la nouvelle région se charge d’exécuter l’ensemble des scripts de vos attachements. Mais les simulateurs ne traitent pas directement le LSL (compréhensible des humains mais pas des machines). Ainsi, avant son exécution par le simulateur, le script doit être converti dans un format adapté à son traitement et appelé "bytecode". Les scripts LSL sont compilés par les résidents lors de leur création. Le bytecode est stocké sur les serveurs d’assets de Linden Lab et n’est jamais directement utilisé par les résidents. A la place, lorsqu’un objet scripté est rez, le simulateur de la région demande lui même le bytecode du script correspondant. Un simulateur est composé de plusieurs modules, la partie chargée d’exécuter les scripts bytecode est appelée la machine virtuelle LSL.

Aujourd’hui, les scripts sont partout, de la simple rotation d’objet à la gestion des véhicules, en passant par les vendeurs et les attachements réactifs à leur environnement. Pour beaucoup de régions, la machine virtuelle est sollicitée en permanence afin de gérer simultanément des centaines de scripts. Compte tenu que le nombre et la complexité des scripts augmentent de plus en plus, les simulateurs sont de plus en plus sollicités. Mais au delà d’un certain point, la machine virtuelle peut provoquer le ralentissement d’autres processus du simulateur (en particulier le moteur physique) engendrant bugs et lag au niveau du serveur. Ainsi, tout ce qui pourra accélérer l’exécution des scripts permettra de retarder le point où les serveurs commenceront à laguer.

Entrez dans Mono

Mono est un nouveau type de machine virtuelle. C’est une technologie open source ayant déjà fait les preuves de sa vitesse et de sa robustesse. Depuis maintenant un an, Mono est considéré par Linden Lab comme une alternative à l’antique machine virtuelle LSL. Mais la transition entre les deux technologies pose plusieurs problèmes. Le problème majeur vient des différences entre les deux bytecodes car le bytecode LSL est incompréhensible pour mono et vice et versa. Avant d’utiliser une machine virtuelle Mono, nous devions créer un compilateur capable de traduire un script texte en LSL en bytecode mono. Ce point est complexe car il faut faire en sorte que les scripts aient exactement le même comportement en mono que sur l’actuelle machine virtuelle. C’est un travail très complexe qui nécessite une batterie de test très pointue. La touche finale de cette intégration a été apportée au troisième trimestre 2007. Depuis novembre 2007, Linden Lab a mené une campagne de test (automatique et manuelle) pour s’assurer de la bonne intégration du mono.

Le programme de déploiement

Mono a terminé sa longue période de bêta et est enfin prêt pour la grille principale. Les modifications du client seront livrées dans la version 1.21 normalement disponible fin juillet. Le simulateur mono devrait être déployé dans la grille principale avec la version 1.24 des serveurs. Les personnes utilisant le client standard seront capable d’utiliser des scripts mono mais ne pourront pas en écrire à moins d’utiliser une RC (release candidat) du client. Une fois que la 1.21 deviendra le client standard, tout le monde pourra utiliser et compiler du mono.

Une fois le mono mis en place, nous récolteront des statistiques sur son utilisation. Par la suite, nous espérons pouvoir éventuellement arrêter la compilation en bytecode LSL mais nous laisserons l’actuel système opérationnel de façon à ce qu’aucun script ne nécessite de conversion en mono.

Premiers résultats

Nous avons réalisé un comparatif entre la machine virtuelle LSL2 et Mono. Des tests réalisés simultanément sur les deux systèmes montrent que Mono est 220 fois plus rapide. Ces tests sont basés sur des calculs mathématiques classiques utilisés pour ce genre de tests d’évaluation. [...].

FAQ

Quand sera lancée la beta mono ?

La bêta est actuellement en cours.

Comment avoir plus d’info sur la beta ?

Consultez la Mono/Beta FAQ.

L’espace mémoire attribué aux scripts va-t-il changer ?? (Limité à 16k en LSL2)

Pour le même script texte LSL les bytecodes Mono et LSL2 seront de taille différente. Pour assurer la compatibilité avec tous les scripts connus, nous avons étendu la mémoire à 64k. Cette modification est possible, car contrairement au LSL2, mono alloue la mémoire dynamiquement. Les scripts LSL2 occupent 16k obligatoirement, alors que les scripts mono ne prennent que l’espace dont ils ont besoin.

64K? Impressionnant, est ce que cela ne risque pas d’encourager une programmation plus laxiste ?

Nous espérons au contraire que ce changement encouragera une programmation plus performante. Actuellement, les programmeurs contournent la limite des 16k en utilisant plusieurs scripts et plusieurs cycles pour faire transiter l’information entre scripts. Avec un seul script, ce ne sera plus nécessaire.

Est ce que je devrais convertir manuellement mes script en mono ou est ce que cela sera réalisé automatiquement ?

Vous devez compiler vous même vos scripts en mono. Pensez à utiliser le menu “tools” (outils) pour recompiler en une seule fois tous les scripts sélectionnés.

Est ce que je peux laisser tourner mes scripts sur l’ancienne machine virtuelle LSL2 éternellement ?

Nous n’avons pas prévu de supprimer la machine virtuelle LSL2. Ce point sera ré-examiné dans un deuxième temps, une fois le mono complètement intégré. Mais actuellement, il est plus simple de continuer de gérer le LSL2 que de migrer tous les scripts.

Est ce que je pourrais utiliser d’autres langage que le LSL puisque mono gère plusieurs langages ?

Eventuellement.... Notre objectif, pour le moment, est de rendre Mono entièrement compatible avec LSL2 pour les scripts LSL.

Pourquoi ne pas avoir utilisé <mon langage préféré> à la place de Mono? (Exemple, lisp, python, lua, javascript)

ce point sera vu plus tard...

Est ce que le LSL va évoluer, intégrer de nouvelles possibilités ? (Exemple, tableaux, références/pointeurs, includes/imports)

Non, le LSL n’évolue pas avec mono.

Avec les machines virtuelles LSL2, ce sont les clients qui réalisent la compilation, est ce que ce point change avec mono ?

Oui, la compilation mono est réalisée d’une certaine façon dans la sim qui héberge le script.

Dans la même veine que le point précédent, J’utilisais une astuce pour charger mon bytecode, sans qu’il y ait de lien avec un script texte. Que deviendra le script que j’ai chargé de cette façon une fois converti au mono ? Est ce que je pourrais continuer à utiliser mon astuce pour uploader des scripts mono ?

Le compilateur mono se base uniquement sur le script texte. La machine virtuelle Mono ne fonctionnera qu’avec des bytecodes compilés par notre compilateur mono. Vous ne pourrez pas exécuter de bytecodes mono qui aurait été directement uploadé.

Que deviennent les scripts dont le code LSL a été perdu mais qui sont encore fonctionnels (cad les scripts fonctionnant toujours mais dont le code LSL n’est plus connus (qui renvoient le message « Script missing from database » lorsque l’on essaye de les éditer) ? Est ce qu’il y aura un moyen de traduire leur bytecode en Mono ou sont il condamnés à rester dans l’actuel format de bytecode ?

Il n’y a pour le moment aucun projet de migration de bytecodes sauf recompilation manuelle de la source. Ce point sera étudié en fonction des demandes des résidents.

Le programme d’intégration progressive d’Havok4 a rencontré un grand succès. Quand sera déployé un tel programme pour le mono ?

Nous ne pensons pas qu’un tel programme soit adapté à Mono. Nous craignons que la grille principale ne se divise entre les régions mono et les régions purement LSL2, générant des anomalies lorsque les résidents se téléporteront ou traverseront des régions avec des scripts mono. Lorsqu’ils entreront dans une région non-mono, leur script cesseront de fonctionner. Le plus grand nombre de résidents ne comprendront pas ce qui se passe et contacteront leur scripteur pour obtenir une version « corrigée » ou contacteront directement le support LL. Notre stratégie a donc été de tester le mono de façon intensive sur la grille Beta avant de le basculer dans la grille principale

Quand Mono sera-t-il disponible sur la grille principale?

Nous avons décidé que l’actuel mono était suffisamment avancé pour être déployé sur la grille principale et laisser les résidents commencer à l’utiliser. Le déploiement est prévu pour le deuxième trimestre 2008. Nous avons prévu d’intégrer le client mono dans le client 1.21, qui sera mis à disposition en juin. Les modifications des serveurs se feront dans un deuxième temps, sûrement alors que les clients mono seront encore en RC. Dés que les simulateurs seront en place, les résidents souhaitant compiler des scripts mono pourront le faire. Le client standard sera capable de compiler du mono que lorsqu’il passera en 1.21, les résidents utilisant des précédentes versions (sans mono) seront malgré tout capable d’utiliser des scripts compilés en mono.

Quelles sont les principales différences entre les scripts LSL2 et Mono en terme de compilation et d’exécution ?

Nous avons voulu rendre le mono entièrement compatible avec le LSL2. Mais nous n’avons cependant pas dupliqué toutes les astuces/solutions de contournement que le LSL2 pouvait autoriser. Vous trouverez ci-dessous quelques une des différences connues. La liste évoluera au fur et à mesure de la détection des nouvelles différences.

• Supporte l’Unicode . De Strife Onizuka : "Dans le LSO LSL, le périmètre Unicode couvert était conforme au RFC 2279 (environ 2 milliards de caractères possibles). Mono utilise le RFC 3629 qui remplace le RFC 2279 et limite le périmètre Unicode au premier 1,114,112 caractères. Cette différence touche directement les fonctions : llBase64ToString, llUnescapeURL. Les chaînes de caractères passant du LSO au Mono seront corrompues (mais de façon adaptée) si elles contiennent des caractères en dehors du périmètre Unicode reconnu." -- SVC-1960

Une fois que le Mono lancé, pourquoi ne pas recompiler *tous* les scripts de la grille en mono ?

Bien que cela soit tentant d’avoir un seul format à gérer, en pratique ce n’est pas faisable. Voici une liste des difficultés que cela poserait :

• Nous n’avons pas le script texte LSL pour tous les bytecodes des scripts actifs. Ces scripts ne fonctionneraient plus vu qu’ils ne pourraient pas être recompilés.
• La recompilation automatique ferait redémarrer tous les scripts. Beaucoup de scripts sont conçus pour fonctionner en continu sans redémarrage.
• Les scripts Mono n’ont pas le même temps d’exécution que le LSL2 (généralement plus rapide). Une recompilation introduirait des comportements différents susceptibles de rendre certains scripts inefficaces, souvent de manière subtile.
• Certains scripts utilisent des fonctionnalités “non documentées” du LSL2. Nous n’avons pas cherché une totale compatibilité pour ce genre de fonctionnalités, mais plutôt de faire en sorte que le comportement de Mono soit aussi prévisible que possible.
• En conséquence de tous les points listés précédemment, les script recompilés en mono doivent être re-testés. Les résidents codant et vendant des scripts en LSL devront tester et éventuellement ajuster le comportement de la version mono de leur script. Si la conversion était automatique, il faudrait alors faire abstraction de cette phase de test et d’ajustement. En cas de recompilation manuelle, ces scripts pourront par ailleurs être distribués comme une mise à jour (vu qu’ils auront été modifiés et ajustés par leur créateur)
• Enfin, recompiler tous les scripts nous obligerait à toucher aux droits. Si un résident a vendu un script en interdisant sa modification, une recompilation automatique violerait cette restriction. Bien que certains scripteurs seraient favorables à cette options, beaucoup ne le seraient pas.