subscribe to this blog

Logilab.org - en VF

Des nouvelles de Logilab et de nos projets sous licences libres, ainsi que des sujets qui nous tiennent à cœur (Python, Linux, Debian, le web sémantique, le calcul scientifique...)

show 104 results
  • PyConFr

    2013/10/28 by Alain Leufroy
    http://www.pycon.fr/2013_static/pyconfr/images/banner.png

    Logilab était au rendez-vous annuel des pythonistes de tous genres : la conférence PYCONFR organisée par l'AFPy, qui avait lieu cette année à l'université de Strasbourg.

    Si vous n'y étiez pas, voici un petit aperçu de ce que vous avez raté, sachant que le programme était chargé.

    Où en est le packaging ?

    Nos amis de Unlish ont fait une présentation de l'état actuel de la distribution de paquets python.

    Après une présentation générale de PyPI, ils ont décrit les derniers changements qui ont permis d'améliorer la disponibilité des paquets python.

    L'information la plus importante concernait Wheel qui est le format désormais recommandé pour fournir des binaires précompilés. Fini les .egg de setuptools ! Ceci devrait faire sourir plus d'un mainteneur de paquet ou administrateur système.

    Wheel est un format de fichier de distribution. Ce format clair et succinct est décrit par la PEP427. Il vise à simplifier la fabrication des paquets pour les distributions de vos OS favoris.

    Les versions récentes de l'installeur pip peuvent gérer les paquets Wheel qui sont compatibles avec le système d'installation décrit dans la PEP376. Il faut toutefois, pour l'instant, dire explicitement à pip de prendre en compte ces fichiers dès qu'ils sont disponibles, grâce à l'option --use-wheel.

    Vous disposez ainsi des avantages de pip (gestion claire et simple des dépendances, freeze, désinstallation, etc.) et ceux d'une distribution de paquets précompilés (installation rapide et simple, environnement de développement non requis, etc.).

    Les paquets Wheel prennent en compte les implementations de python et leurs ABIs. Vous pouvez donc fournir des paquets Wheel (et les signer) facilement pour des versions spécifiques de Jython, Pypy, IronPython, etc.

    $ python setup.py bdist_wheel
    $ pypy setup.py bdist_wheel
    

    Cela ne vous dispense pas de distribuer les sources de votre paquet ;)

    $ python setup.py sdist
    

    Python dans Mercurial

    http://www.selenic.com/hg-logo/logo-droplets-50.png

    Pierre-Yves David et Alexis Métaireau ont fait un petit rappel des trucs vraiment géniaux dans Mercurial comme les revsets et les templates.

    Le coeur de leur présentation concernait l'utilisation de Python pour écrire Mercurial.

    D'après son auteur, Mercurial existe aujourd'hui grâce à Python. En effet Python a permis à Matt Mackall d'écrire une preuve de son concept en à peine deux semaines -- il n'avait pas plus de temps à y dédier donc l'implementation en C n'était pas envisageable.

    Rappelons qu'avant de changer le langage d'implementation il est toujours intéressant de se poser des questions sur les algorithmes utilisés. Nous avons vu quelques exemples d'optimisation en Python qui ont permis de d'accélérer Mercurial, et quelques astuces pour contourner les lenteurs que l'on rencontre avec l'interpréteur CPython (lazy import, low-level access, etc.).

    Les autres avantages notables de l'utilisation de Python viennent de sa flexibilité. Les extensions pour Mercurial peuvent grâce à cela changer le comportement interne de Mercurial. Par exemple largefiles et watchman améliorent grandement la gestion des gros fichiers et la mise à jour des informations du dépôt.

    Hy, lisp on Python

    http://docs.hylang.org/en/latest/_images/hy_logo-smaller.png

    Julien Danjou a présenté une implémentation de Lisp basé sur la VM de Python. En effet Python peut être vu comme un sous-ensemble de Lisp.

    Hy interprète un script écrit dans un dialecte de Lisp et le convertit en arbre syntaxique Python classique, qui est ensuite exécuté par l'interpréteur Python.

    [Python] .py -(parse)---> AST -(compile)-> .pyc -(run)-> python vm
                          /
    [Lisp]   .hy -(parse)/
    

    tip

    hy2py permet de montrer l'équivalent Python d'un script Lisp.

    Il y a donc une grande interopérabilité entre ce qui est implémenté en Hy et ce qui l'est en Python. Aucun souci pour importer les autres modules Python, quels qu'ils soient.

    Hy supporte presque toutes les versions de Python et beaucoup d'interpréteurs, notamment pypy.

    De nombreuses fonctions de common Lisp sont disponibles, et Hy se rapproche de Clojure pour la définition des classes.

    Pour ceux qui sont intéressés par Hy, notez qu'il manque encore quelques petites choses :

    • les cons cells sont en cours de discussion
    • il faudra faire sans les macroexpand pour vous aider dans vos macros
    • les fonctions de Common Lisp ne sont pas toutes présentes
    • le dialect de Lisp nécessite, pour l'instant, de mixer les [...]` et les (...)`, mais ceci devrait changer.
    • Hy n'est pas présent à l'exécution, il y a donc forcément des limitations.

    Python pour la Robotique

    Il y avait une présentation bien sympathique d'une équipe qui participe régulièrement aux championnats de france de robotique.

    Ils utilisent une carte basée sur un SoC ARM sur laquelle ils disposent d'un Gnu/Linux et d'un interpréteur Python (2.7).

    Ils ont codé en C/C++ quelques routines de bas niveau pour un maximum de réactivité. Mise à part cela, tout le reste est en Python, notamment leurs algorithmes pour gérer la stratégie de leurs robots.

    Python leur facilite énormément la vie grâce au prototypage rapide, à la rapidité pour corriger leur code (surtout avec le manque de sommeil durant la compétition), à la souplesse pour simuler en amont, analyser des logs, etc.

    Un Python dans la maison

    http://hackspark.fr/skin/frontend/base/default/images/logo3d_hackspark_small.png

    Il y avait aussi la présentation d'un projet (Hack'Spark!) jeune mais déjà fonctionnel de domotique. La petite démonstration en direct du système était du plus bel effet ;)

    Et, pour moins de 100 euros vous pourrez allumer la lumière chez vous depuis une interface web ! Perso, je m'y mets ce mois ;)

    Framework Graphique Kivy

    http://kivy.org/logos/kivy-logo-black-64.png

    Kivy est entièrement écrit en Python/Cython et utilise OpenGL. Il a donc un très bon support sur les machines récentes (Linux, BSD, MacOs, Android, iOS, Rpi, etc.). Et il n'a rien a envier aux autres frameworks.

    Kivy semble particulièrment pratique pour mener à bien des projets sur les plateformes mobiles comme les téléphones portables et les tablettes (Android et iOS).

    De plus, parmi les outils fournis avec Kivy vous pourrez trouver quelques trucs pour simplifier votre développement :

    • PyJNIus utilise l'interface JNI de la VM Java (via Cython). Il sert de proxy sur les classes Java et vous donne donc accès à l'ensemble de l'API Android.
    • PyObjus est le pendant de PyJNIus pour ObjectiveC sous iOS.
    • Plyer essaie de rassembler en une API commune de plus haut niveau PyJNIus et PyObjus, ce qui permet de coder une seule fois pour les deux plateformes.
    • Buildozer aide à la compilation de projet pour Android de manière plus simple qu'avec Python for Android.

    Nous avons eu droit à une présentation des concepts et comment les mettre en œuvre en direct. Je sens que ça va me simplifier la vie !


  • Rencontre autour de SaltStack lors de l'OpenWorldForum

    2013/09/25 by Arthur Lutz

    Suite à l'organisation du sprint français autour de SaltStack, nous continuons d'essayer de fédérer la communauté française utilisatrice (ou tout simplement curieuse) de solutions de gestion centralisées autour de la technologie Salt (qui est écrit en Python et que nous pouvons donc facilement adapter à nos besoins en contribuant au projet).

    http://openworldforum.org/static/pictures/Calque1.png http://saltstack.com/images/SaltStack-Logo.png

    Au sein de l'OpenWorldForum nous animons un SaltStack meetup / BOF le jeudi 3 octobre de 18h30 à 20h30 avec Thomas Hatch fondateur de SaltStack. La totalité de l’événement (dont le meetup) est gratuit, il suffit de s'inscrire.

    Logilab tiendra un stand le jeudi et le vendredi lors du forum, n'hésitez pas à venir discuter avec nous. Le TDI (Test-Driven Infrastructure), qui consiste à appliquer le TDD (Test-driven development) (développement piloté par les tests) à l'administration système sera un des thèmes de notre présence.


  • Compte rendu PGDay France 2013 (Nantes) - partie 2/2

    2013/07/01 by Arthur Lutz

    Ora2Pg: Migration à Grande Vitesse par Gilles Darold

    L'outil ora2pg permet de jouer une migration d'Oracle à Postgresql. Malgré notre absence de besoin de ce type de migration, cette présentation fut l'occasion de parler d'optimisation diverses qui peuvent être appliqué à des imports massifs tel que nous pouvons en pratiquer à Logilab.

    Par exemple :

    • utilisation prioritaire de COPY plutôt que INSERT,
    • supprimer les indexes/contraintes/triggers/sequences (les créer en fin d'import),
    • maintenir un _work_mem_ élevé (pour la création des index et contraintes),
    • augmenter les checkpoin_segments (>64/1Gb).

    Quelques réglages systèmes peuvent être mis en place le temps du chargement (on les rebranche une fois que le serveur passe en "production") :

    • fsync=off
    • full_page_writes=off
    • synchronous_commit=off
    • WAL (Write Ahead Log) sur des disques SSD
    • kernel : vm.dirty_background_ratio = 1
    • kernel : vm.dirty_ratio = 2

    Coté Postresql, les paramètres suivants sont probablement à modifier (les chiffres sont à titre d'exemple, la configuration matérielle est bien particulière, par exemple 64G de RAM, voir les diapos pour le détail):

    • shared_buffers = 10G
    • maintenacen_work_mem = 2G
    • checkpoint_segments = 61
    • checkpoint_completion_target = 0.9
    • wal_level = minimal
    • archive_mode = off
    • wal_buffer = 32 Mo
    • désactiver les logs
    http://ora2pg.darold.net/ora2pg-logo.png

    Pour aller plus loin voir le support de présentation (5).

    Vers le Peta Byte avec PostgreSQL par Dimitri Fontaine

    Dimitri Fontaine a admirablement bien traité cette question complexe qu'est la montée à l'échelle en terme de volume de données. Son approche fut très didactique, avec, à chaque concept, un rappel de ce dont il s'agisait. Par exemple, parlant du MVCC, il explique qu'il s'agit de plusieurs définitions en parallèle d'une même ligne. Ensuite on décide avec VACUUM quelle version doit être visible par tout le monde. Par défaut AUTOVACCUM se déclenche quand 20% des données ont changé.

    Face aux difficultés et aux inconvénients de stocker la totalité d'une PetaByte sur un seul serveur, Dimitri Fontaine a évoqué les solutions possible en terme d'architecture distribuée pour permettre de stocker ce PetaByte sur plusieurs serveurs répartis. La "Bi-Directional Replication" (qui sera dispo dans le futur) permetterait d'avoir plusieurs bases SQL qui séparément stockent une partie des données (cf EVENT TRIGGERS). Un approche complémentaire serait d'utiliser plproxy qui par des procédures stockées permet de répartir les requêtes sur plusieurs serveurs.

    http://www.logilab.org/file/150419/raw/Screenshot%20from%202013-07-01%2010%3A25%3A46.png

    Finalement, un point qui nous a paru pertinent : il a parlé de haute disponibilité et des flous techniques qui entourent le sujet. Il faut bien faire la différence entre la disponibilité des données et du service. Par exemple, en WARM STANDBY les données sont disponibles mais il faut redémarrer Postgresql pour fournir le service alors que en HOT STANDBY les données sont disponibles et le serveur peut fournir les services.

    Pour aller plus loin voir le support de présentation (6).

    Comprendre EXPLAIN par Guillaume Lelarge

    Utiliser EXPLAIN permet de débugger l’exécution d'une requête SQL ou de l'optimiser. On touche assez rapidement au fonctionnement interne de Postgresql qui est relativement bien documentés. Guillaume Lelarge a donc, à l'aide de nombreux exemples, présenté des mécanismes plutôt bas niveau de Postgresql.

    Notons entre autres les différents types de scans dont les noms sont relativement explicites :

    Dans la même veine, les types de tris :

    • external sort (sur disque),
    • quicksort (en mémoire).

    Mais aussi, prenez le temps de lire les exemples sur son support de présentation (7)

    Conclusion

    https://www.pgday.fr/_media/pgfr2.png

    PGDay.fr est une conférence que nous pouvons vivement vous recommander, proposant un savant mélange des différentes questions auxquelles nous sommes confrontées lorsque nous travaillons avec des bases de données. Aussi bien en tant qu'administrateur système, développeur, ou utilisateur de SQL. Il va sans dire que le niveau technique était très pointu. Les présentations restaient pourtant accessibles. Les orateurs et organisateurs étaient disponibles pour des interactions, permettant de prolonger la réflexion et les discussions au delà des présentations.

    Nous envisageons d'ores et déjà d'aller à l'édition 2014! À l'année prochaine...

    http://www.logilab.org/file/150100/raw/2e1ax_default_entry_postgresql.jpg

  • Compte rendu PGDay France 2013 (Nantes) - partie 1/2

    2013/07/01 by Arthur Lutz

    Quelques personnes de Logilab ont assisté aux PGDay 2013 à Nantes. Voici quelques points qui nous ont marqués.

    http://www.cubicweb.org/file/2932005/raw/hdr_left.png

    Gestion de la capacité des ressources mémoire d'un serveur PostgreSQL par Cédric Villemain

    Cédric Villemain nous a exposé plusieurs pistes d'investigation de la gestion mémoire de Postgresql.

    On peut employer des outils Linux tels que vmstat, pmap, meminfo, numactl, mais aussi des outils spécifiques à Postgresql, tels que pg_stat (hit ratio), pg_buffercache (audit de la mémoire cache), pgfincore (audit du cache de l'OS).

    Il faut mettre des sondes sur les tables et indexes critiques de manière à avoir une idée du fonctionnement "normal" pour ensuite détecter le fonctionnement "anormal". À Logilab, nous utilisons beaucoup munin, pour lequel plusieurs greffons Postgresql sont disponibles : munin pg plugins et pymunin.

    Pour aller plus loin voir le support de présentation (1).

    Les nouveautés de PostgreSQL 9.3 par Damien Clochard

    Damien Clochard a fait une très synthétique présentation des fonctionnalités de la nouvelle version de PostgreSQL 9.3. Le cycle de release de Postgresql dure 1 an, donc la periode de beta est courte, il faut que la communauté soit impliquée pour tester rapidement. Damien en profite pour chanter les louanges de PostgreSQL, qui est, selon lui, le SGBD le plus dynamique au monde: 1 version majeure par an, 4-5 versions mineures par an, et un support de 5 ans des versions majeures.

    Actuellement, cela signifie que 5 versions majeures sont maintenues (notamment en terme de sécurité) en parallèle : 8.4, 9.0, 9.1, 9.2, 9.3beta1. Notons donc que la version 9.3 qui sort bientôt sera donc supportée jusqu'à 2018.

    http://www.logilab.org/file/150442/raw/elephant.png

    Pour les nouveautés, difficiles à résumer, notons néanmoins :

    • des gains de performance,
    • des verrous possibles sur les clés étrangères,
    • une gestion mémoire plus fine,
    • la possibilité de faire des pg_dump en parallèle (--jobs),
    • scénarios supplémentaires de réplication,
    • possibilité de "bascule rapide" en architecture répliquée,
    • facilitation de mise en place d'un serveur clone (génération automatique du fichier recovery.conf),
    • vue matérialisées,
    • opérateurs supplémentaires pour JSON (citation "MongoDB avec la tranquilité (ACID)"),
    • les requètes LATERAL
    • extensibilité avec des processus supplémentaires permettant des opérations de maintenance, de supervision ou d'optimisation,
    • des backends supplémentaires pour les "Foreign Data Wrappers" (introduits en 9.1),
    • possibilité de séparer le fichier de configuration en plusieurs sous-fichiers (utile pour une pilotage par SaltStack par exemple).

    Damien en a profité pour parler un peu des points forts prévus pour la version 9.4 :

    • simplification de la montée en charge,
    • réplication logique (répliquer une seule table par exemple),
    • parallélisation des requêtes (multi-coeurs),
    • stockages internes

    En bref, concis et alléchant. Vivement qu'on ait cette version en production.

    En attendant on a profité pour l'installer à partir des entrepôts Debian gérés par la communauté Postgresql.

    Pour aller plus loin voir le support de présentation (2).

    "Ma base de données tiendrait-elle la charge ?" par Philippe Beaudouin

    Philippe Beaudoin a utilisé pour cette analyse une combinaison de pgbench (injection), et la table pg_stat_statements qui collecte les statistiques sur l'utilisation mémoire des requêtes : produit une table avec les query, nombre d'appels, temps passé, nombre de lignes, etc.

    L'idée générale est d'établir un profil de charge transactionnel sur la production pour pouvoir comparer avec la pré-production ou la future plateforme.

    Pour éviter de devoir copier les données de production (lent, problème de confidentialité, etc), il est conseillé d'utiliser "generate_series" pour remplir la base de données de données de test.

    pgbench utilise des scenario TPC-B (Transaction Processing Performance Council Benchmarks) Pour chaque scénario (4 scénarios dans son exemple) on a une cible TPS (transaction par secondes). Il recommande de faire attention à ne pas modifier considérablement la taille de la base avec les scénarios (ex. trop de DELETE, ou trop d'INSERTs).

    Un astuce pour charger le cache linux

    find <files> -exec dd if='{}' of=/dev/null\;
    

    Si on ne sait pas quels fichiers charger, on peut utiliser pg_relation_filepath(oid) FROM pg_class where relname like 'tbl%' pour trouver en SQL quels fichiers contiennent les données.

    Nous avons demandé si un outil de type GOR (flux UDP de la production vers la pre-production ou le serveur de développement pour les requêtes HTTP) existait pour Postgresql.

    http://www.logilab.org/file/150448/raw/gor.png

    Réponse : Tsung contient un mode proxy qui permet d'enregistrer la production, ensuite de la rejouer en pre-prod, mais pas en mode live. À priori il serait possible de combiner plusieurs outils existant pour faire cela (pgShark ?). La problématique n'est pas simple notamment lorsque les bases de données divergent (index, series, etc).

    Pour aller plus loin voir le support de présentation (3).

    PostGIS 2.x et au delà par Hugo Mercier

    Nous avons trouvé la présentation réussie. Elle introduisait les concepts et les nouveautés de PostGIS 2.x. Ayant intégré des fonctionnalités de PostGIS à CubicWeb et travaillant un peu sur la visualisation en WebGL de données stockées dans CubicWeb+Postgresql, nous avons pu réfléchir à des possibilités de délégation de traitement à la base de donnée.

    http://www.logilab.org/file/150441/raw/Screenshot%20from%202013-07-01%2010%3A30%3A00.png

    Nous nous sommes aussi interrogés sur le passage à l'échelle d'applications web qui font de l'affichage de données géographiques, pour éviter d'envoyer au navigateurs un volume de données trop important (geoJSON ou autre). Il y aurait des architectures possible avec une délégation à Postgresql du travail de niveaux de zoom sur des données géographiques.

    Pour aller plus loin voir le support de présentation.


  • Notes suite au 4ème rendez-vous OpenStack à Paris

    2013/06/27 by Paul Tonelli

    Ce 4ème rendez-vous s'est déroulé à Paris le 24 juin 2013.

    http://www.logilab.org/file/149646/raw/openstack-cloud-software-vertical-small.png

    Retours sur l'utilisation d'OpenStack en production par eNovance

    Monitoring

    Parmi les outils utiles pour surveiller des installation OpenStack on peut citer OpenNMS (traps SNMP...). Cependant, beaucoup d'outils posent des problèmes, notamment dans le cadre de l’arrêt ou de la destruction de machines virtuelles (messages d'erreur non souhaités). Il ne faut pas hésiter à aller directement se renseigner dans la base SQL, c'est souvent le seul moyen d'accéder à certaines infos. C'est aussi un bon moyen pour exécuter correctement certaines opérations qui ne se sont pas déroulées convenablement dans l'interface. L'utilisation possible de SuperNova est recommandée si on utilise plusieurs instances de Nova (multi-environnement).

    Problèmes durant les migrations

    Citation : "plus on avance en version, mieux la procédure se déroule".

    La pire migration a été celle de Diablo vers Essex (problèmes d'IPs fixes qui passent en dynamique, problèmes de droits). Même si tout semble bien se passer sur le moment, faire un redémarrage des nœuds hardware / nœud(s) de contrôle est recommandé pour vérifier que tout fonctionne correctement après le redémarrage.

    Si on veut supprimer un nœud qui fait tourner des machines, une commande existe pour ne pas recevoir de nouvelles machines (en cas de panne matérielle par exemple).

    Afin d'avoir de la redondance, ne pas utiliser les nœuds hébergeant les machines à plus de 60% permet d'avoir de la place pour héberger des machines déplacées en cas de panne / disparition d'un des nœuds nova-compute.

    Au niveau migration, ce qui est bien documenté pour KVM est la migration avec du stockage partagé ou 'live storage' (le système de fichier contenant le disque de la machine est disponible sur la source de la machine et sur la destination). Il existe un second mode, avec migration par 'block' qui permet de migrer des disques s'ils ne sont pas sur un système de fichier partagé. Ce second mécanisme a été présent, puis rendu obsolète, mais une nouvelle version semble aujourd'hui fonctionnelle.

    À propos de la fonction terminate

    La fonction terminate détruit définitivement une machine virtuelle, sans possibilité de retour en arrière. Il n'est pas évident pour une personne qui commence sur OpenStack de le comprendre : elle voit souvent ce bouton comme "juste" éteindre la machine. Pour éviter les gros problèmes (tuer une machine client par erreur et sans retour en arrière possible), il existe 2 solutions :

    Pour les admins il existe un paramètre dans la configuration d'une instance :

    UPDATE SED disable_terminate '1'
    

    Pour les autres (non-admins), on peut utiliser une fonction de verrouillage (nova lock) d'une machine afin d'éviter le problème. (Les deux utilisent le même mécanisme).

    Token

    Les tokens servent à authentifier / autoriser une transaction sur les différentes versions d'OpenStack. Il est important que la base qui les stocke soit indexée pour améliorer les performances. Cette base grossit très vite, notamment avec grizzly où les tokens reposent sur un système PKI. Il est utile de faire une sauvegarde régulière de cette base avant de la flusher (pour permettre à un client de récupérer un ancien token notamment).

    Espace de stockage

    Ce n'est pas conforme aux bonnes pratiques, mais avoir juste un /var énorme pour le stockage fonctionne bien, notamment quand on a besoin de stocker des snapshots de machines Windows ou de grosses machines.

    Ceph

    https://www.logilab.org/file/149647/raw/logo.png

    Spécial citation: "c'est du libre, du vrai".

    Ceph est un projet permettant d'avoir un stockage redondant sur plusieurs machines, et offrant trois opérations principales : get, put, delete. Le système repose sur l'utilisation par le client d'une carte, fournie par les serveurs ceph, qui lui permet de trouver et de récupérer facilement un objet stocké.

    Le pilote de stockage virtualisé est parfaitement fonctionnel et tourne déjà en production. Ce pilote permet d'utiliser Ceph comme périphérique de stockage pour des machines virtuelles. Il existe un remplacement (Rados Gateway Daemon) qui implémente l'interface swift pour OpenStack et permet d'utiliser Ceph en backend. Ce pilote est qualifié de stable.

    Le pilote noyau (librbd) permettant de voir du stockage Ceph comme des disques est encore en développement, mais devrait fonctionner à peu près correctement si le noyau est >= 3.8 (3.10 conseillé).

    Performances

    En écriture, une division par deux des performances est à prévoir par rapport à une utilisation directe des disques (il faut que les N copies ait été stockées avant de valider la transaction). En lecture, Ceph est plus rapide vu l'agrégation possible des ressources de stockage.

    Traduction de Openstack

    La communauté cherche des gens motivés pour traduire le texte des différents outils Openstack.

    Neutron (anciennement Quantum)

    Pas mal de travail en cours, la version Havana devrait avoir la capacité de passer mieux à l'échelle et permettre la haute disponibilité (ça fonctionne toujours même quand une des machines qui hébergent le service plante) pour tout ce qui est DHCP / L3.

    Sur l'organisation d'une communauté OpenStack en France

    Différents acteurs cherchent actuellement à se regrouper, mais rien n'est encore décidé.


  • PME et simulation numérique : deux mondes qui peinent à se rejoindre

    2013/06/11 by Olivier Cayrol

    Ce matin, j'ai assisté aux Rencontres INRIA Industries qui portaient sur le thème "Modélisation, simulation et calcul intensif". Y était notamment présenté l'initiative HPC-PME dont l'objet est de faciliter l'accès des PME au calcul hautes performances. Cette conférence a été pour moi l'occasion de formaliser mes réflexions sur les PME et leur recours à la simulation numérique.

    http://www.logilab.org/file/145959/raw/2013-HPC-PME.jpg

    HPC-PME : une initiative pour montrer aux entreprises l'apport du calcul hautes performances

    L'initiative HPC-PME est portée par l'INRIA, le GENCI et OSEO. Elle se propose d'accompagner des PME afin de leur montrer en quoi le calcul hautes performances peut leur être utile pour innover, gagner en compétitivité, et finalement identifier des leviers de croissance. Elle décline ses actions selon quatre axes :

    • la formation et le partage de bonnes pratiques,
    • l'accès à des ressources de calcul pour montrer l'utilité du calcul hautes performances,
    • le soutien d'experts issus de la recherche publique, qui vont transférer leurs compétences en calcul hautes performances,
    • l'intégration dans des dispositifs de financement de l'innovation.

    L'accompagnement classique d'une PME consiste à identifier avec elle quels sont les points sur lesquels la simulation numérique peut lui apporter quelque chose, à dimensionner les besoins en calcul nécessaires à ces simulations, à l'aider à porter ses codes de simulation vers des machines de calcul hautes performances, et enfin à effectuer, sur ces machines, un cas de calcul typique.

    https://www.logilab.org/file/145960/raw/Screenshot%20from%202013-06-12%2014%3A38%3A43.png

    Après deux ans de travail, l'initiative HPC-PME a permis à 30 PME d'être accompagnées et de découvrir en quoi le calcul hautes performances peut les aider à gagner en compétitivité. Ces PME sont issues de domaines d'activités très divers (hydrologie marine, électronique, gestion de l'énergie, finance, etc.) et ont comme point commun d'être centrées sur un métier donné et de ne pas avoir, généralement, de compétences internes dans le domaine du calcul numérique.

    Convaincu depuis longtemps que la simulation numérique et l'utilisation intelligente de la puissance informatique peuvent aider les entreprises à gagner en compétitivité, je ne peux qu'être ravi d'une initiative telle que HPC-PME. Toutefois, elle ne me semble pas toujours convenir aux besoins d'une PME qui se pose la question d'un recours à la simulation numérique.

    Les besoins des PME : pouvoir, sans investissement, faire des calculs pas forcément complexes

    Lors des différentes conversations que j'ai pu avoir avec des dirigeants de PME, il m'est apparu que leur principale demande est de pouvoir effectuer très simplement des simulations en fournissant un jeu de données puis en cliquant sur un bouton. L'initiative HPC-PME a pour objectif de démontrer l'intérêt du calcul hautes performances et d'aider les PME à acquérir les compétences leur permettant de mettre en œuvre des solutions de HPC. Or, la plupart des PME :

    • ne souhaitent pas mettre en place en interne une solution de calcul hautes performances (achat, configuration, maintenance),
    • ne désirent pas acquérir en interne les compétences leur permettant d'utiliser une solution de calcul hautes performances,
    • n'ont pas réellement besoin des performances extrêmes apportées par l'initiative HPC-PME (la Formule 1 de la simulation numérique), mais plutôt d'une solution solide, simple, et à coût d'entrée raisonnable (une bonne voiture haut de gamme suffit),
    • n'ont pas une demande continue leur permettant d'amortir un investissement en calcul numérique.

    Les PME ont généralement une expertise métier forte, c'est là leur facteur différenciant. Mais elles n'ont, pour la majorité d'entre elles, aucune compétence en analyse numérique ou en informatique. Attendu qu'elles n'ont que peu de calculs à effectuer, il leur est surérogatoire d'internaliser ces compétences.

    Partant de ce constat, je pense sincèrement que la meilleure façon pour une PME d'avoir accès au calcul numérique serait de disposer d'une plateforme dont l'accès est facturé à l'utilisation et qui lui permet de :

    • définir un cas de calcul en termes métier,
    • avoir accès à des ressources de calcul sur lesquelles les codes de calcul sont installés et configurés,
    • lancer en un clic le cas de calcul sur une ressource de calcul offrant des performances suffisantes,
    • pouvoir obtenir de l'aide de la part d'experts numériciens connaissant les codes de calcul (en cas de problème numérique ou de modélisation),
    • offrir des fonctionnalités de partage des cas de calcul selon des règles de sécurité strictes et entièrement contrôlables (typiquement pour faire appel à un expert numéricien, montrer ses résultats au client final ou faire travailler un fournisseur).

  • Retour OSDC 2012 - présentation mercurial DVCS

    2012/12/05 by Pierre-Yves David

    À la mi-octobre, j'ai participé à la conférence OSDC 2012 à Paris. Le but de cette conférence est de permettre à des développeurs de différentes communautés de se rencontrer dans une ambiance chaleureuse. De fait, j'ai découvert un certain nombre de projets et de pratiques intéressants.

    http://act.osdc.fr/osdc2012fr/css/logo.png

    Le samedi, j'ai découvert des outils javascript mettant l'accent sur les modèles de données comme AngularJS ou BackBone, Une présentation rapide du langage Go, le très prometteur portage des outils GCC sur Windows nommé MinGW ainsi que les nouveautés de GCC 4.8. La journée s'est conclut sur des présentations éclairs dont je retiendrai surtout la perversité des opérateurs secrets en Perl et le livre Javascript Éloquent intégralement en HTML qui en profite donc pour inclure exemples et exercices interactifs au fil du contenu.

    Le dimanche matin j'ai ouvert le bal en présentant mes travaux actuels dans le DVCS Mercurial: l'Évolution de Changeset (PDF de la présentation). Ce concept permet aux développeurs de découvrir la réécriture d'historique de manière simple et sûre. Les utilisateurs avancés ont accès de leur côté à des processus de travail et de revue encore inédits dans le monde des DVCS. Ma présentation fut suivie d'une introduction à la découverte automatique de bugs grâce à la bisection dans les DVCS.


    Changesets Evolution : Mercurial secoue le monde du dvcs par Pierre-Yves David

    La journée s'est poursuivie avec une présentation du langage Haskell, de la bibliothèque de visualisation sigmajs et la spécification SPORE apportant un peu d'espoir dans les spécifications de services Web REST.


  • Retour Agile Tour Nantes 2012 - présentation et pistes à explorer

    2012/12/04 by Arthur Lutz

    Nous utilisons les méthodes agiles depuis la création de Logilab. Nous avons parfois pris des libertés avec le formalisme des méthodes connues, en adaptant nos pratiques à nos clients et nos particularités. Nous avons en chemin développé nos propres outils orientés vers notre activité de développement logiciel (gestion de version, processus sur les tickets, intégration continue, etc).

    https://www.logilab.org/file/113044?vid=download

    Il est parfois bon de se replonger dans la théorie et d'échanger les bonnes pratiques en terme d'agilité. C'est pour cette raison que nous avons participé à l'étape nantaise de l'Agile Tour.

    Logiciels libres et agilité

    Plutôt que d'être simples spectateurs, nous avons présenté nos pratiques agiles, fortement liées au logiciel libre, dont un avantage indéniable est la possibilité offerte à chacun de le modifier pour l'adapter à ses besoins.

    Premièrement, en utilisant la plate-forme web CubicWeb, nous avons pu construire une forge dont nous contrôlons le modèle de données. Les processus de gestion peuvent donc être spécifiques et les données des applications peuvent être étroitement intégrées. Par exemple, bien que la base logicielle soit la même, le circuit de validation des tickets sur l'extranet n'est pas identique à celui de nos forges publiques. Autre exemple, les versions livrées sur l'extranet apparaissent directement dans l'outil intranet de suivi des affaires et de décompte du temps (CRM/ERP).

    Deuxièmement, nous avons choisi mercurial (hg) en grande partie car il est écrit en python ce qui nous a permis de l'intégrer à nos autres outils, mais aussi d'y contribuer (cf evolve).

    Notre présentation est visible sur slideshare :

    http://www.logilab.org/file/113040?vid=download

    ou à télécharger en PDF.

    Behaviour Driven Development

    Le BDD (Behaviour Driven Development) se combine avec des tests fonctionnels haut niveau qui peuvent être décrits grâce à un formalisme syntaxique souvent associé au langage Gherkin. Ces scénarios de test peuvent ensuite être convertis en code et exécutés. Coté Python, nous avons trouvé behave et lettuce. De manière similaire à Selenium (scénarios de test de navigation Web), la difficulté de ce genre de tests est plutôt leur maintenance que l'écriture initiale.

    https://www.logilab.org/file/113042?vid=download

    Ce langage haut niveau peut néanmoins être un canal de communication avec un client écrivant des tests. À ce jour, nous avons eu plusieurs clients prenant le temps de faire des fiches de tests que nous "traduisons" ensuite en tests unitaires. Si le client n'est pas forcément prêt à apprendre le Python et leurs tests unitaires, il serait peut-être prêt à écrire des tests selon ce formalisme.


  • Logilab à PyConFR 2012 - compte rendu

    2012/10/09 by Alain Leufroy
    http://awesomeness.openphoto.me/custom/201209/4ed140-pycon3--1-of-37-_870x550.jpg

    Logilab était à la conférence PyConFR qui a pris place à Paris il y a deux semaines.

    Nous avons commencé par un sprint pylint, coordonné par Boris Feld, où pas mal de volontaires sont passés pour traquer des bogues ou ajouter des nouvelles fonctionnalités. Merci à tous!

    Pour ceux qui ne connaissent pas encore, pylint est un utilitaire pratique que nous avons dans notre forge. C'est un outil très puissant d'analyse statique de scripts python qui aide à améliorer/maintenir la qualité du code.

    Par la suite, après les "talks" des sponsors¸ où vous auriez pu voir Olivier, vous avons pu participer à quelques tutoriels et présentations vraiment excellentes. Il y avait des présentations pratiques avec, entre autres, les tests, scikit-learn ou les outils pour gérer des services (Cornice, Circus). Il y avait aussi des retours d'information sur le processus de développement de CPython, le développement communautaire ou un supercalculateur. Nous avons même pu faire de la musique avec python et un peu d'"embarqué" avec le Raspberry Pi et Arduino !

    Nous avons, avec Pierre-Yves, proposé deux tutoriels d'introduction au gestionnaire de versions décentralisé Mercurial. Le premier tutoriel abordait les bases avec des cas pratiques. Lors du second tutoriel, que l'on avait prévu initialement dans la continuité du premier, nous avons finalement abordé des utilisations plus avancées permettant de résoudre avec énormément d'efficacité des problématiques quotidiennes, comme les requêtes sur les dépôts, ou la recherche automatique de régression par bissection. Vous pouvez retrouver le support avec les exercices .

    Pierre-Yves a présenté une nouvelle propriété importante de Mercurial: l'obsolescence. Elle permet de mettre en place des outils d'édition d'historique en toute sécurité ! Parmi ces outils, Pierre-Yves a écrit une extension mutable-history qui vous offre une multitude de commandes très pratiques.

    La présentation est disponible en PDF et en consultation en ligne sur slideshare. Nous mettrons bientôt la vidéo en ligne.

    http://www.logilab.org/file/107770?vid=download

    Si le sujet vous intéresse et que vous avez raté cette présentation, Pierre-Yves reparlera de ce sujet à l'OSDC.

    Pour ceux qui en veulent plus, Tarek Ziadé à mis à disposition des photos de la conférence ici.


  • Rencontre LLVM à l'IRILL

    2012/09/27 by Damien Garaud
    IRILL-logo LLVM-logo

    L'IRILL , Initiative de Recherche et Innovation sur le Logiciel Libre, organisait une rencontre LLVM mardi 25 septembre à Paris dans les locaux de l'INRIA Place d'Italie dans le 13e arrondissement. Les organisateurs, Arnaud de Grandmaison, Duncan Sands, Sylvestre Ledru et Tobias Grosser ont chaleureusement accueilli environ 8 personnes dont 3 de Logilab.

    L'annonce de l'IRILL indiquait une rencontre informelle avec une potentielle Bug Squashing Party sur Clang. Nous n'avons pas écrasé d'insectes mais avons plutôt discuté: discussions techniques, petits trolls, échanges de connaissances, d'outils et d'expériences accompagnés de bières, sodas, gâteaux et pizzas (et une salade solitaire et orpheline qui n'a finie dans le ventre de personne contrairement aux pizzas mexicaines ou quatre fromages).

    LLVM (Low Level Virtual Machine) est un projet développé depuis une dizaine d'années qui propose une collection d'outils et de modules facilement réutilisables pour construire des logiciels orientés langages : interpréteurs, compilateurs, optimiseurs, convertisseurs source-to-source...

    Depuis l'étage d'entrée du code dans le compilateur (ou frontend), en passant par l'optimiseur indépendant de la plate-forme, jusqu'à la génération de code machine (backend) et ce, pour plusieurs architectures (X86, PowerPC, ARM, etc.), le choix de son design en fait un outil tout à fait intéressant. Parmi ces frontends, il y a le fameux Clang (C/C++, Objective-C), GHC (Haskell). Et le projet dragonegg permet de l'utiliser comme plug-in à GCC et donc de bénéficier des différents frontends GCC (Ada, Fortran, etc.).

    De nombreux outils se sont construits autour du framework LLVM : LLDB un débugger, vmkit une implémentation de la machine virtuelle Java et .NET ou encore polly, un projet de recherche dont Tobias est l'un des deux co-fondateurs, qui a pour objectif d'optimiser un programme indépendamment du langage via des polyhedral optimizations.

    Les principaux contributeurs à ce jour sont Apple, Google, des contributeurs "individuels" dont Duncan Sands, suivis par des laboratoires de recherche et autres. Voir l'article de Sylvestre sur "Who is in control of LLVM/Clang ?".

    La clef de voûte de LLVM est sa représentation intermédiaire (IR pour Intermediate Representation). C'est une structure de données qui représente sous forme SSA (Single Static Assignment) les flux de données et de contrôle. Cette forme est plus "haut-niveau" et plus lisible que du code assembleur, elle comporte certaines informations de type par exemple. Elle constitue le pivot de l'infrastructure LLVM : c'est ce que produisent les frontends comme Clang, qui est ensuite passée aux optimiseurs de LLVM et est ensuite consommée par les backends dont le rôle est de les transformer en code machine natif.

    En voici un exemple en C:

    int add(int a)
    {
        return a + 42;
    }
    

    La représentation intermédiaire est donnée via Clang :

    $> clang -S -emit-llvm add_function.c -o add_function.ll

    L'extension *.ll désigne des "fichiers IR" et le résultat donne:

    define i32 @add(i32 %a) nounwind uwtable {
      %1 = alloca i32, align 4
      store i32 %a, i32* %1, align 4
      %2 = load i32* %1, align 4
      %3 = add nsw i32 %2, 42
      ret i32 %3
    }
    

    Cette représentation peut ensuite être bitcodée, assemblée ou compilée. Voir les différentes commandes LLVM pour assembler, désassembler, optimiser, linker, exécuter, etc.

    Une autre utilisation intéressante de cette infrastructure est l'utilisation de la bibliothèque Clang pour parser du code C/C++ afin de parcourir l'Abstract Syntax Tree (AST). Ceci offre notamment de belles possibilités d'introspection. Google a d'ailleurs rédigé un tutoriel sur les plugins Clang et ses possibilités via l'API de Clang, notamment la classe ASTConsumer. Il est possible de parcourir l'ensemble des constructeurs, de connaître la propriété d'une classe (abstraite ou non), parcourir les membres d'une classe, etc. Avant de partir, nous parlions de la possiblité de propager un changement d'API à travers toutes les bibliothèques qui en dépendent, soit la notion de patch sémantique.

    Nous avons aussi profité pour parler un peu du langage Julia ou de Numba.

    Pythonistes convaincus, nous connaissions déjà un peu Numba, projet de Travis Oliphant, contributeur NumPy et papa de SciPy. Ce projet utilise l'infrastructure LLVM pour compiler du byte-code Python en code machine (Just In Time compilation), en particulier pour NumPy et SciPy. Les exemples montrent comment passer d'une fonction Python qui traite un tableau NumPy à une fonction compilée Just In Time. Extrait issu d'un des exemples fournis par le projet Numba :

    from numba import d
    from numba.decorators import jit as jit
    
    def sum2d(arr):
        M, N = arr.shape
        result = 0.0
        for i in range(M):
            for j in range(N):
                result += arr[i,j]
        return result
    
    csum2d = jit(ret_type=d, arg_types=[d[:,:]])(sum2d)
    

    Oui, la fonction sum2d n'est pas optimale et très "naïve". Néanmoins, la fonction compilée va près de 250 fois plus vite ! Numba utilise les bindings LLVM pour Python via llvm-py afin de passer du code Python, à l'Intermediate Representation pour ensuite utiliser les fonctionnalités JIT d'LLVM.

    Entre programmeurs de langages à typage statique, nous avons aussi parlé de C et d'Ocaml (dont il existe des bindings pour LLVM) et mentionné de beaux projets tels que PIPS et Coccinelle.

    Pour finir, nous savons maintenant prononcer Clang. On dit "klang" et non "cilangue". Nous avons appris que gdb avait son propre parser et n'utilisait pas le parser de GCC. Rappelons-le, l'un des grands avantages de LLVM & Clang face à GCC est sa modularité et la possibilité d'utiliser une des pierres qui forme l'édifice pour construire sa propre maison.

    Nous finissons ce billet par une citation. David Beazley disait lors de sa présentation à Eursoscipy 2012 :

    The life is too short to write C++.

    Certes. Mais qu'on le veuille ou qu'on le doive, autant se servir d'outils biens pensés pour nous faciliter la vie.

    Encore merci aux organisateurs pour cette rencontre et à la prochaine.

    Quelques références


show 104 results