Wikipédia abstraite/Mises à jour/2021-06-17

Actualités de la Wikipédia abstraite

Toutes nos excuses pour avoir manqué la mise à jour de la semaine dernière. Ces temps-ci sont plus occupés que d’habitude.

Pourquoi permettre plusieurs mises en œuvre d'une fonction ?

Avant que nous plongions dans le sujet du jour, deux rappels rapides :

Notre première heure de présence au bureau arrive le mardi 22 juin à 16:00 UTC. Cela se tiendra sur les canaux Telegram et IRC via Libera.Cat #wikipedia-abstract^connecter..
Le mardi 24 juin 2021, nous nous présenterons à la conférence Arctic Knot. Le membre de la communauté Mahir Morshed présentera comment obtenir les données lexicographiques prêtes à être utilisées dans la Wikipédia abstraite à 15:00 UTC et Denny fera une présentation sur la Wikipédia abstraite et Wikifonctions en général à 16:00 UTC.

Le modèle au cœur de Wikifonctions est centré autour de fonctions. Chaque fonction peut avoir plusieurs mises en œuvre. Toutes les mises en œuvre d’une fonction devraient retourner les mêmes résultats étant donné les mêmes entrées.

On peut se demander : Pourquoi ? Quel intérêt y a-t-il à avoir plusieurs mises en œuvre qui produisent toutes la même chose ?

Il y a plusieurs réponses à cela. Par exemple, pour de nombreuses fonctions, des algorithmes différents existent qui peuvent être utilisés par des mises en œuvre différentes. L’exemple traditionnel repris dans les classes de formation informatique est la fonction de tri : une fonction de tri prend deux arguments, une liste d’éléments à trier (c’est-à-dire à ranger dans un ordre linéaire spécifique) et un opérateur de comparaison qui, étant donné deux éléments, nous dit lequel devrait venir en premier. Il y a de nombreux algorithmes de tri différents, dont n’importe lequel pourrait être utilisé pour mettre en œuvre la fonction de tri. Une visualisation particulièrement intéressante des différents algorithmes de tri peut être trouvée sous forme de danses populaires traditionnelles.

La personnes appelant la fonction de tri ne se soucie souvent pas beaucoup de quel algorithme est utilisé, du moment qu’il fonctionne, est correct et retourne suffisamment rapidement. Mais disposer de différents algorithmes mis en œuvre permet au service d’exécuter les différents algorithmes et comparer leurs comportements les uns par rapport aux autres. Des algorithmes différents demandent souvent des quantités différentes de mémoire ou de cycles de calcul. Garder la trace du comportement à l’exécution des différentes mises en œuvre permettra éventuellement à l’orchestrateur de fonctions de prédire et sélectionner la mise en œuvre la plus efficace pour une entrée donnée et à tout instant donné. Lorsque des cycles de calcul inutilisés sont disponibles, il peut également exécuter plusieurs mises en œuvre avec des entrées différentes, afin d’en apprendre davantage sur les différents comportements de ces mises en œuvre.

Un bienfait de permettre des mises en œuvre multiples est que cela réduit la potentialité de conflits lors des modifications de Wikifonctions. Si un contributeur souhaite essayer une mise en œuvre différente, en pensant que cela serait plus efficace, il sera le bienvenu pour le faire et pour soumettre au système sa nouvelle mise en œuvre. Il n’y a aucun besoin des arguments bien connus concernant des langages de programmation différents et leurs mérites relatifs et de leurs qualités pour déborder vers Wikifonctions : chacun sera le bienvenu pour fournir des mises en œuvre de ses algorithmes favoris dans ses langages de programmation préférés et le système prendra soin de valider, tester et sélectionner automatiquement la mise en œuvre appropriée.

Un autre bienfait d’avoir des mises en œuvre multiples est que nous pouvons les tester les une contre les autres de façon rigoureuse. Bien sûr, nous aurons la suite de testeurs écrits par l’utilisateur pour vérifier l’exactitude initiale des résultats (et aussi pour commencer à collecter des métadonnées sur l’exécution). Mais quand vous disposez de plusieurs mises en œuvre d’une fonction, vous pouvez soit créer synthétiquement davantage d’entrées, soit lancer des exécutions de fonctions soumises par l’utilisateur envers différentes mises en œuvre pour collecter davantage de métadonnées sur ces exécutions. Puisque nous avons plusieurs mises en œuvre, nous pouvons les utiliser pour valider mutuellement les différentes mises en œuvre, comparer leurs résultats et dégager les incohérences qui surviennent pour les rapporter à la communauté.

Au delà de disposer de mises en œuvre d’algorithmes différents, nous nous attendons aussi à avoir des mises en œuvre dans différents langages de programmation. Les mises en œuvre dans différents langages de programmation seront utiles pour les mêmes raisons que le sont des algorithmes différents, c’est-à-dire être en mesure de les valider mutuellement et de permettre la sélection de la mise en œuvre la plus efficace pour un appel de fonction donné. Mais cela a l’avantage supplémentaire de pouvoir les exécuter sur des configurations différentes de l’évaluateur de fonction de Wikidata. Que veux-je dire par cela ?

Alors que nous prévoyons de soutenir différents langages de programmation pour ajouter des mises en œuvre dans Wikifonctions, nous ne prévoyons pas de prendre en charge l’exécution de mettre en production des évaluateurs pour chacun d’entre eux. Ceci est dû à plusieurs raisons : le coût de maintenance pour garder actifs, opérationnels tous ces évaluateurs et les mettre à jour serait probablement sévèrement élevé. Plus nous prendrons en charge de langages de programmation, plus la Fondation ou la communauté sera susceptible d’être exposée à des anomalies ou préoccupations de sécurité au sein des exécutifs nécessaires pour ces langages. Et il est probable que, au delà de cinq ou six langages de programmation, le retour sur investissement diminue largement. Aussi quel est le but de disposer de mises en œuvre dans une programmation que nous ne prévoyons pas d’exécuter en production ?

Rappelez-vous que nous prévoyons un écosystème autour de Wikifonctions, où il existera de nombreux évaluateurs de fonctions indépendants de celui exécuté par la Fondation Wikimedia. Nous espérons que des évaluateurs seront disponibles en tant qu’applications pour vos appareils et téléphones mobiles intelligents ou tablettes, ou sur votre propre machine à la maison, ou dans votre navigateur ou dans le nuage Internet, ou que des parties tierces intègrent des évaluateurs pour certaines fonctions dans leurs systèmes, ou même d’avoir un réseau pair-à-pair d’évaluateurs s’échangeant des ressources et des résultats. Dans ces contextes, les systèmes dorsaux pourraient choisir de soutenir un jeu de langages de programmation différent de celui pris en charge par Wikifonctions, soit parce que cela est favorable à leur cas d’utilisation, soit parce qu’ils sont contraints ou qu’ils se passionnent pour développer et soutenir un langage de programmation spécifique. Notamment pour exécuter des fonctions de Wikifonctions qui sont intégrées dans le système d’une application tierce, cela peut fournir un gain notable de performance pour exécuter ces fonctions dans le même langage que l’application intégrante.

Un autre avantage pour avoir des mises en œuvre dans des langages de programmation différents est que, au cas où un évaluateur a soudainement été arrêté, par ex. car un problème de sécurité a été signalé et pas encore réglé, ou parce que les coûts en ressources de cet évaluateur particulier se sont développés de façon problématique, nous pouvons déconnecter cet évaluateur et changer notre configuration afin d’exécuter un jeu différent de langages de programmation. Ceci nous donne beaucoup de flexibilité pour soutenir les opérations de Wikifonctions sans perturber ni bloquer trop de personnes voulant utiliser le service.

Une mise en œuvre d’une fonction peut également être donnée sous forme d’une composition de fonctions : au lieu d’utiliser du code contribué dans un langage de programmation, une composition prends les fonctions existantes de Wikifonctions et les imbrique ensemble afin de mettre en œuvre une fonction donnée. Voici un exemple : disons que nous voulons mettre en œuvre une fonction deuxième, qui retourne la deuxième lettre d’un mot. Supposons que nous avons déjà une fonction première qui retourne la première lettre d’un mot et une fonction queue qui tronque la première lettre d’un mot et retourne le reste, alors deuxième(m) peut être mis en œuvre comme première(queue(m)), c’est-à-dire la première lettre du résultat après avoir tronqué la première lettre du mot donné. Nous parlerons de la composition de fonctions en plus amples détails une autre fois.

La composition a l’avantage que nous n’exigeons pas des mises en œuvre de chaque fonction en code ou en tant que fonction intégrée, mais malgré cela nous pouvons évaluer ces fonctions. Le système dorsal enchainera de façon appropriée les appels de fonction et transmettra les résultats d’une fonction à la suivante jusqu’à ce qu’il arrive au résultat demandé. Ceci pourrait être particulièrement utile pour des évaluateurs de parties tierces, qui offrent un jeu différent de langages de programmation ou qui même visent un langage de programmation spécifique ; ils pourraient encore utiliser un large ensemble de fonctions, sans même en avoir des mises en œuvre locales.

Nous nous attendons à ce que la composition offre habituellement des performances moins compétitives en comparaison de l’exécution de code. Nos métadonnées seront en mesure de repérer spécifiquement les appels de fonctions les plus consommateurs de ressources. Nous prévoyons d’exposer ces résultats sur le wiki, en mettant en évidence pour la communauté là où des mises en œuvre plus efficaces pourraient avoir le plus d’impact. J’espère voir arriver une fonctionnalité qui, par exemple, permettra à un contributeur de voir combien de cycles de CPU auront pu être épargnés grâce au portage d’une fonction en WebAssembly.

Une approche intéressant à la composition de fonction pourrait être que, si nous avons du code dans un langage de programmation spécifique pour toutes les fonctions participant à une composition, il pourrait parfois être possible de synthétiser et compiler le code pour la fonction composée dans ce langage de programmation. Ceci pourrait mener à une situation où, par exemple, deux langage de programmation différents offrent la mise en œuvre la plus efficace pour certaines des fonctions participantes, mais où la fonction réelle fonctionnera encore plus efficacement dans le nouveau résultat synthétisé.

Et finalement, il y aura aussi du cache ; chacun des appels de fonctions, y compris les appels imbriquées dans les fonctions composées, pourra être mis en cache et réutilisé. Ce cache pourra être partagé entre tous nos projets et fournir une accélération significative : après tout, il est très probable que certains calculs vont être beaucoup plus populaires que d’autres, de la même manière sur certains articles sont beaucoup plus populaires que d’autres à un instant donné. Et comme justement Wikipédia épargne d’énormes quantités de cycles CPU en conservant des pages dans le cache au lieu d’effectuer à nouveau le rendu à chaque fois que quelqu’un veut les lire, nous pouvons obtenir des bienfaits similaires en conservant un cache des appels de fonctions et leurs résultats.

En résumé : disposer de multiples mises en œuvre pour une fonctions nous donne non seulement plus de flexibilité sur la façon de planifier et exécuter une fonctions, et donc de potentiellement épargner des ressources, mais cela nous donne également une plus haute confiance sur la justesse du système dans son entier du fait de la validation croisée des différentes mises en œuvre et cela réduit le potentiel de conflits lors des modifications de Wikifonctions.

Nous sommes très curieux de voir comment ceci se déroulera en pratique. Les quelques paragraphes ci-dessus décrivent des idées qui demandent beaucoup de travail avancé sur l’infrastructure dorsale et pour laquelle nous ne savons pas réellement dans quelle performance fonctionnera chaque partie. Nous nous attendons bien sûr à voir arriver bien plus d’idées (Peut-être de vous ? Peut-être d’un labo de recherche ?) et de découvrir que certaines des idées ébauchées ici ne fonctionnent pas. Nous ne promettons pas de mettre en œuvre tout ce qui est décrit ci-dessus. La bonne chose est que nombre de ces idées sont en fin de compte des optimisations : même des versions simples de tout ceci devrait produire des résultats corrects. Mais des approches plus intelligentes nous épargnerons des quantités énormes de ressources et nous permettrons de monter l’échelle vers le plein potentiel du projet.

Comme pour nos autres projets, nous prévoyons de publier nos données et métadonnées et nous invitons les organisations externes, dans le milieu académique et dans l’industrie, de même que des passionnés et développeurs indépendants et des chercheurs, à nous aider à relever ces défis intéressants et difficiles.

Enfin, rappelez-vous, notre première heure de présence au bureau arrive mardi 22 juin 2021 à 16:00 UTC sur les canaux Telegram et IRC via Libera.Chat #wikipedia-abstract^connecter.