Pour vous authentifier, privilégiez eduGAIN / To authenticate, prefer eduGAINeu

Réunion TAcq/Sophya - c++ std-11-17

Europe/Paris
200/0-Bleue - Salle Bleue (IJCLab)

200/0-Bleue - Salle Bleue

IJCLab

30
Montrer la salle sur la carte

Réunion TAcq/SOPHYA du jeudi 22 juillet 2021 

OdJ: le point sur le passage de SOPHYA à un standard récent de c++ ( >= c++11) pour permettre le développement du corrélateur logiciel optimisé dans TAcq.

  • Présents: Réza Ansari, Hadrien Grasland, Christophe Magneville , O. Perdereau (en salle bleue) 
  • Guy Barrand et Jean-Eric Campagne ( à distance , en zoom)  

• Discussion sur le passage de SOPHYA en standard c++11

Test de compilation en cours sur MacOS - parmi les petits problèmes rencontré, la confusion entre la fonction bind() de la librairie standard (en lien avec les sockets et primitives réseau) et la fonction std::bind() qui permet l'application partielle de fonction avec certains arguments fixés. Autre problème, différence sur la définition de ptr_diff. En effet, parmi les modifications introduites, il y a la définition des types d'entier et de float utilisés par sophya (int_4, int_8 ...) à travers les types c++ définies dans stdint.h : int_16_t , int_32_t , int_64_t ... (définitions de sophya en octets, et celles du c++ en bits)  - Le type utilisé pour les index de tableaux dans sophya (sa_size_t ) a été défini comme ptrdiff_t, mais cela pose problème, étant donné ptrdiff_t est défini comme long int ou long long int selon les plateformes/compilos. On décide de revenir à la définition de sa_size_t comme int_8 ou int_4.  

Pour les essais de compilation de la branche stdint de sophya, avec les flags de compilations pour >= c++11, destinée à devenir la branche standard : 

  • Hadrien teste sur Linux avec compilo récent
  • Reza teste sur Mac-OS
  • Christophe fait les tests sur linux avec le compilo standard / par défaut 

• Système de build et de test automatique de SOPHYA sur la plateforme gitlab  

Hadrien a mis en place le système de build et de test automatique de SOPHYA , sur une branche privée pour le moment. Ce test automatique prend en charge tout le build, y compris ProjectPI en 2 versions, X11 et wxWidget. Il lance aussi les programmes de test (au moins ceux qui renvoient un code de retour) et exécute les exemples (runcxx). Hadrien fait une demo du système  et décrit les principales étapes - On part en effet de l'instanciation d'une machine virtuelle Linux, sur laquelle Hadrien installe le compilo, puis les librairies externs, puis sophya...  Excellent travail,  très impressionnant ! 

Hadrien précise qu'il n'est pas actuellement possible de déployer le système de build automatique sur gitlab dans un environnement Mac OS (sans doute pour des raisons de licence Darwin

Changer le statut de Hadrien en maintainer , SOPHYA  et TAcq -> FAIT 

 

• Corrélateur et TAcq

 Hadrien ne prévoit pas de problème particulier pour le développement de son code optimisé de calcul de calcul des corrélations et son intégration dans la structure de TAcq avec les threads (tâches) de traitement et le système de partage de mémoire entre ces tâches. Par contre il envisage d'utiliser  le standard c++17 pour le code de TAcq qui comprend plusieurs fonctionalités utiles, parmi lesquelles aligned_alloc (allocateur avec spécification d'alignement mémoire, et qui est disponible depuis c version 2011. aligned_alloc permet par exemple d'allouer des std::vector correctement alignés. 

TAcq ne compilera donc qu'avec c++17 . Il faudra être attentif à l'alignement des données des paquets  BRPaquet, et surtout, les les paquets après FFT qui seront manipulés par le code du corrélateur. 

Question de Christophe (cmv) sur la disponibilité de compilo c++17 sur les machines de Nançay. Hadrien précise que CentOS 8 a un compilo suffisamment récent, mais la durée de vie courte de CentOS8 limite son usage dans le temps. CentOS 7 bénéficie d'un support de plus longue durée, mais  mais il faut installer un compilo plus récent

• PI/piapp  

Réza donne brièvement quelques nouvelles du développement de PI/piapp, la version avec wxWidget. Guy approuve la décision de maintenir une version de PI avec X11/Motif. Plus de détails lors d'une prochaine réunion.

 

Notes concernant des tests et essais faits après la réunion   

• Compilation et test de la branche git stdint sophya 

Hadrien a modifié la définition de sa_size_t sur la branche stdint et Réza a vérifié la compilation et l'exécution de tous les programmes de tests  listés dans la documentation sophya. Il s'agit au total de plus de 20 programmes de tests, et plus de 70 cas de tests avec le jeu des options et arguments. Hadrien propose de compléter si possible les quelques programmes qui ne renvoie pas de code retour (exemples; spar, tluc ...) afin d'étendre l'étendue de couverture des tests automatiques.

• Erreurs lors de l'exécution des tests 

Il y a effectivement deux programmes de test, plus exactement 2 cas qui renvoient un code d'erreur, comme Hadrien l'avait signalé. J'ai (Reza) détecté un troisième cas avec le programme tfitsdt - voir ci-dessous. Note: ces problèmes n'ont rien à voir avec la compilation c++11.

  1. Le programme tspm renvoie un code d'erreur pour le cas d'exécution avec les cartes sphériques de type ECP ( tspm E ). Il s'agit en effet d'une inconsistance dans les différentes routines du numéro de pixel de/vers les coordonnées angulaires (theta, phi). Il s'agit de savoir si le premier pixel d'un anneau (couverture complète) est à phi=0 ou phi=1/2 taille de pixel. Même question se pose pour theta, au moins dans le case de couverture partielle. Il faudra corriger cette erreur. L'opération est assez simple, mais il faut le faire avec soin, afin de ne pas introduire de bug supplémentaire. Il faut aussi vérifier l'exécution correcte de tlegpsht et tstisharp. Réza fera la correction avec Christophe.
  2. L'exécution du programme tmtdt se bloque lorsque le programme est lancé avec l'argument SWFITS (swap sur fichier fits, même si on spécifie un seul thread. Je (Réza) n'ai pas identifié le problème. Il se peut que cela soit une protection au niveau de c-fitsio, en effet, dans ce programme, le fichier fits est ouvert dans un thread différent de celui qui l'utilise. Même avec un seul thread pour le remplissage ou lecture de NTuple/DataTable, le programme utilise deux threads, le thread principal qui ouvre le fichier et un thread fils qui fait le travail, alors que le thread principal est en attente. En cherchant sur le web, on voit que c-fitsio a des limitations spécifiques et qu'il faut le compiler avec une option si on veut l'utiliser en multi-thread ( voir https://heasarc.gsfc.nasa.gov/docs/software/fitsio/c/c_user/node15.html )      
  3. En lancement le programme tfitsdt qui effectue des vérification de création, remplissage, relecture de DataTable avec I/O fits (et aussi PPF), j'ai détecté un cas où le programme indique une erreur d'exécution. Il faut exécuter le programme avec l'option -useptr, ( tfitsdt -useptr 6 ) où on utilise l'accès au données d'une ligne de la table avec les pointeurs de l'objet DataTableRowPtr . C'est un mode d'utilisation sans filet de sécurité qui pose problème si on se trompe sur le type de donnée d'une colonne. Le code de retour renvoyé par tfitsdt a révélé en effet indirectement une petite inconsistance dans le code de la classe FitsHandler<BaseDataTable>. La DataTable relue depuis le fichier FITS modifiait le type des colonnes de type string. La table était créée avec trois colonnes string de type S, S16, S64  (S chaîne de longueur indéfinie, non fixée, S16 et S64 de longueur fixe, maximale de 16, 64 caractères), et à la relecture, on obtenait S,S64,S provoquant l'erreur à l'exécution. Cette erreur est due à la différence de type entre le pointeur de donnée de champ utilisé dans le code, et la donnée de la colonne. L'utilisation de DTCell et les opérateurs de conversion assure un accès aux données conforme à la nature des données, et n'occasionnait pas d'erreur à l'exécution, malgré la petite différence des types de chaînes de caractères après relecture des tables depuis le fichier fits (cas d'exécution tfitsdt 6 ) L'action du programme était conforme à la logique du code du handler fits dans le fichier FitsIOServer/fitshdtable.cc. Les trois colonnes S,S16,S64 donnent comme type de champ ds le BINTABLE 72A,16A,64A (72 étant la valeur demandée par défaut pour les chaînes de caractères ds  tfitsdt.cc). A la relecture, le test sur la largeur en caractères des colonnes dans le code était <16  et <64  (tests d'inégalité stricte) pour la création de colonnes S16 et S64 respectivement. J'ai changé les tests d'inégalité strict en <=16 et <=64 pour retrouver les types de colonnes chaînes de caractères après relecture identiques à ceux de la table écrite, ce qui de fait élimine l'erreur à l'exécution de tfitsdt -useptr 6 . Notons que ce changement ds  fitshdtable.cc peut occasionner un effet de bord dans de rares cas, où pour un champ FITS 16A (ou 64A) par exemple, le dernier caractère d'une chaîne avec 16 (ou 64) caractères significatifs est perdu. En effet la longueur S16 et S64 des DataTable de SOPHYA inclue le caractère zéro (0) de terminaison de chaîne de caractère  c.  

Action : correction de le fichier fitshtable.cc - tests d'inégalité stricte transformé en <=16 , <=64 pour la création de champs de type S16 S64 lors de la lecture de BINTABLE fits . commit fait dans gitlab 

• Les typedefs stdint.h et  ptrdiff_t 

Hadrien avait proposé de vérifier la définition des types c++ int32_t int64_t , std::ptrdiff_t, comme indiqué ici https://stackoverflow.com/questions/4160945/long-long-int-vs-long-int-vs-int64-t-in-c

Reza a complété le petit programme qui est recopié ci-dessous. 

Les résultats d'exécution sur MacOS  10.14 , compilo Apple clang version 11.0.0 (clang-1100.0.33.17) :

 ---- Checking if is_int64<T> ... 
int:        0  -sizeof=4
int64_t:    1  -sizeof=8
long int:    0  -sizeof=8
long long int:    1 -sizeof=8
std::ptrdiff_t     0  -sizeof=8
---- Checking if is_longint<T> ... 
int32_t:    0  -sizeof=4
int64_t:    0  -sizeof=8
long int:    1  -sizeof=8
long long int:    0  -sizeof=8
std::ptrdiff_t     1  -sizeof=8

et sur Linux (machine deco) ,  g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)

---- Checking if is_int64<T> ... 
int:        0  -sizeof=4
int64_t:    1  -sizeof=8
long int:    1  -sizeof=8
long long int:    0 -sizeof=8
std::ptrdiff_t     1  -sizeof=8
---- Checking if is_longint<T> ... 
int32_t:    0  -sizeof=4
int64_t:    1  -sizeof=8
long int:    1  -sizeof=8
long long int:    0  -sizeof=8
std::ptrdiff_t     1  -sizeof=8


Source du programme de  vérification des typedefs de stdint.h de c++ 

sh> g++ -std=c++11 -o tst_type tst_type.cc


#include <iostream>
#include <cstdint>

template <typename T>
bool is_int64() { return false; }

template <>
bool is_int64<int64_t>() { return true; }

template <typename T>
bool is_longint() { return false; }

template <>
bool is_longint<long int>() { return true; }

int main()
{
  std::cout << "---- Checking if is_int64<T> ... " << std::endl;
  std::cout << "int:    \t" << is_int64<int>() << "  -sizeof="<<sizeof(int) << std::endl;
  std::cout << "int64_t:\t" << is_int64<int64_t>() << "  -sizeof="<<sizeof(int64_t) << std::endl;
  std::cout << "long int:\t" << is_int64<long int>() << "  -sizeof="<<sizeof(long int)  << std::endl;
  std::cout << "long long int:\t" << is_int64<long long int>() << " -sizeof="<<sizeof(long long int) << std::endl;
  std::cout << "std::ptrdiff_t \t" << is_int64<std::ptrdiff_t >() << "  -sizeof="<<sizeof(std::ptrdiff_t ) << std::endl;
  
  std::cout << "---- Checking if is_longint<T> ... " << std::endl;
  std::cout << "int32_t:\t" << is_longint<int32_t>() << "  -sizeof="<<sizeof(int32_t) << std::endl;
  std::cout << "int64_t:\t" << is_longint<int64_t>() << "  -sizeof="<<sizeof(int64_t) << std::endl;
  std::cout << "long int:\t" << is_longint<long int>() << "  -sizeof="<<sizeof(long int) << std::endl;
  std::cout << "long long int:\t" << is_longint<long long int>() << "  -sizeof="<<sizeof(long long int) << std::endl;
  std::cout << "std::ptrdiff_t \t" << is_longint<std::ptrdiff_t >() << "  -sizeof="<<sizeof(std::ptrdiff_t ) << std::endl;

  return 0;
}

 

 

Il y a un compte-rendu associé à cet événement. Les afficher.
    • 10:00 10:20
      Passage de sophya en c++11 20m
    • 10:20 10:40
      Système de build et test automatisé de sophya sur gitlab 20m
      Orateur: Hadrien Grasland (IJCLab)

      Mail envoyé le 20/8:

      Bonjour,

      Après quelques jours de boulot de plus pour mettre les choses au propre, je pense qu'on peut intégrer une première version de mon système de test automatique / intégration continue à la branche master des dépôts SOPHYA et PAON-4.

      Cette première version permet, à chaque fois qu'on pousse une branche sur l'un des dépôts...

      • L'installation automatique d'un environnement de compilation à partir d'une distribution Ubuntu 20.04 nue
        • Ceci a l'avantage de garder quelque part des instructions complètes de référence pour l'installation d'un environnement de dev Sophya : liste des packages requis, etc...
      • Une vérification que le code compile avec toutes les options activées
        • En mode C++11 et en mode C++17 dans le cas de SophyaLib/SophyaExtLibs/SophyaProgs, les autres projets travaillant avec une seule norme C++ pour plus d'efficacité (C++17 pour TAcq et C++11 pour les autres, conformément à nos discussions précédentes)
        • En mode X11/Motif et WxWidgets pour ProjectPI.
      • La vérification des tests de SophyaLib/SophyaExtLibs/SophyaProgs qui fonctionnent et que je sais faire fonctionner (cf mail précédent).
      • L'exécution des exemples de DocSophya que je sais faire fonctionner.
      • La compilation de TAcq et de mon prototype de corrélateur, et le test automatique de ce dernier.
      • Pour les contributions aux trois projets du coeur de Sophya, la vérification que l'on ne casse rien qui dépend de Sophya: les exemples DocSophya continuent de s'exécuter, ProjectPI continue de compiler, et TAcq continue à bien fonctionner selon les critères ci-dessus.

      Contrairement à ce qu'on pourrait penser à la longueur de ma liste, l'exécution est relativement rapide grâce au parallélisme des ressources offertes par le CC :

      • 9 minutes pour l'ensemble des vérifs Sophya quand on ne touche pas à la définition de l'environnement de compilation (sinon c'est plutôt autour de 10-11 minutes)
      • 8 minutes pour SophyaExtLibs et SophyaProgs (un peu plus rapide car on sait que l'environnement de compilation ne change pas, vu qu'il est défini par SophyaLib)
      • 1 minute pour les tests d'exemples de DocSophya
      • 5 minutes pour la compilation ProjectPI (limité par la build WxWidgets, qui est un peu plus lente)
      • 1-3 minutes pour TAcq (dépend de la charge des serveurs car le test du corrélateur n'est pas découplé des mesures de performances, mais bon le destin de ce corrélateur est d'être intégré dans le code TAcq principal de toutes façon donc je pourrai mieux séparer les choses à ce moment-là...)

      Par conséquent, on peut raisonnablement envisager de s'en servir comme outil de test : on pousse une branche de développement sur le dépôt, on attend que l'intégration continue fasse son travail, et on vérifie que le résultat est positif avant de fusionner dans la branche master...

      Une petite démo pour la frime :

      Du côté de ce qu'il faut discuter, il y a d'abord les prérequis pour l'intégration d'une v1 de ce système à la branche master :

      • L'intégration continue Sophya se base sur ma branche stdint, donc si on la fusionne, on fusionne implicitement stdint. Dans le rapport que Réza nous a transmis récemment, j'avais l'impression qu'il était satisfait des tests qu'il avait fait sur la branche stdint, donc peut-être qu'on peut y aller ?
      • Pour que TAcq reste compatible avec Sophya une fois cette fusion effectuée, il faut synchroniser les types TAcq avec les types Sophya en migrant aussi TAcq à stdint. Sinon, il y a conflit entre TAcq qui définit Int64 comme un typedef de long long int et Sophya qui définit maintenant int_8 comme un typedef de int64_t, qui n'est pas forcément un typedef de long long int (dépend de l'OS, de la libc et du compilateur). Voici une MR qui effectue ce changement, comme vous pouvez le constater c'est simple et efficace : https://gitlab.in2p3.fr/baoradio/tacq/-/merge_requests/5/diffs .

      Et éventuellement, on peut aussi passer en revue la liste des choses que j'aimerais bien avoir à l'avenir, mais dont je pense qu'on n'a pas besoin pour activer le système sur la branche master :

      • Un des tests de Sophya contient un sleep de 100s. Cela me semble exagérément long. Voici un patch qui le ramène à 4 secondes: https://gitlab.in2p3.fr/SOPHYA/SophyaProgs/-/merge_requests/2 .
      • Actuellement, le résultat de certains des tests de Sophya est ignoré pour des raisons que je vous ai expliquées précédemment. Dès qu'un test aura été corrigé ou qu'un exemple d'utilisation aura été fourni (selon le cas), il me sera très facile de le réactiver pour qu'il soit pris en compte par la validation automatique.
      • Actuellement, la validation de TAcq ne vérifie que la bonne compilation du code, pas son bon fonctionnement en exécution. Certaines choses ne peuvent pas être raisonnablement testées en intégration continue (tout ce qui a trait aux cartes PCIe), d'autres peuvent être testées mais ça nécessite un peu de boulot que je n'ai pas encore fait. Je me suis dit que c'était déjà bien de commencer par vérifier que ça compile, puis ajouter des vérifications plus élaborés dans un 2e temps.
      • Idem pour ProjectPI. Ce n'est vraiment pas facile de tester des applis graphiques automatiquement (le mieux qu'on peut faire c'est souvent de simuler des interactions utilisateur, prendre des captures d'écran et les comparer avec des images de référence via des outils comme OpenCV), mais si un jour quelqu'un a le courage d'écrire de tels tests, ce ne sera sans doute pas difficile de les ajouter à l'intégration continue.
      • Côté DocSophya, on pourrait envisager d'effectuer automatiquement le rendu de la documentation et la mettre en ligne via le mécanisme Gitlab Pages, ce qui est quand même plus sympathique que de mettre en ligne un site à la main. Mais c'est pas mal de boulot en plus, et ça me semble éminemment non prioritaire.

      A bientôt,
      Hadrien

       

    • 10:40 11:00
      TAcq/code optimisé du corrélateur 20m
    • 11:00 11:20
      PI/piapp 20m