TAcq merge requestshttps://gitlab.in2p3.fr/baoradio/tacq/-/merge_requests2022-08-16T15:51:09+02:00https://gitlab.in2p3.fr/baoradio/tacq/-/merge_requests/13Correction de divers problèmes dans BRVisibilityCalculator2022-08-16T15:51:09+02:00GRASLAND HadrienCorrection de divers problèmes dans BRVisibilityCalculator- Ajout du dossier de sortie des binaires à gitignore
- Correction d'une erreur d'indexation dans BRVisCalcBase::Message conduisant à une boucle infinie avec augmentation indéfinie de la consommation de RAM.
- Amélioration du traitement ...- Ajout du dossier de sortie des binaires à gitignore
- Correction d'une erreur d'indexation dans BRVisCalcBase::Message conduisant à une boucle infinie avec augmentation indéfinie de la consommation de RAM.
- Amélioration du traitement des fins de lignes surnuméraires dans BRVisCalcBase::Message permettant de rendre le code appelant plus idiomatique
- Correction d'un message de log peu lisible et élimination d'une gestion d'erreur incorrecte et verbeuse.
- Correction du test permettant de détecter le type de données à utiliser.
- Correction de la taille des matrices allouées.
- Correction de l'ordre d'allocation des matrices (BRVisCalcBase avant BRVisibilityCalculatorV2).
- Initialisation correcte des flags indiquant si les paquets sont corrects.
- Gestion correcte de la fin d'acquisition.
- Ajout d'un test qui vérifie que l'exemple d'acquisition continue de marcher à la CI.
- Rebascule vers brviscalcv2 pour que la CI tourne plus vite ;)
- Ajout d'un chemin SOPHYA:: oublié.https://gitlab.in2p3.fr/baoradio/tacq/-/merge_requests/12Support minimal des complexes entiers 16-bit2022-07-19T11:00:21+02:00GRASLAND HadrienSupport minimal des complexes entiers 16-bit- Le type TwoByteComplex est remplacé par un template IntegerComplex paramétré par un type entier signé. Son API est légèrement modifiée pour prendre en compte les changements de sémantique (le paramètre n'est plus forcément un octet, ni...- Le type TwoByteComplex est remplacé par un template IntegerComplex paramétré par un type entier signé. Son API est légèrement modifiée pour prendre en compte les changements de sémantique (le paramètre n'est plus forcément un octet, ni convertible vers int sans overflow).
- Le code qui peut facilement être rendu générique pour supporter tous les IntegerComplex est rendu générique. Le reste du code est adapté pour utiliser `IntegerComplex<int8_t>`, l'équivalent de TwoByteComplex dans le nouveau formalisme
- BRVisibilityCalculatorV1 supporte désormais `IntegerComplex<int16_t>`. BRVisibilityCalculatorV2 supporte désormais `IntegerComplex<int8_t>` et `IntegerComplex<int16_t>`.https://gitlab.in2p3.fr/baoradio/tacq/-/merge_requests/11Optimisations et simplifications du prototype de corrélateur2022-02-02T17:33:17+01:00GRASLAND HadrienOptimisations et simplifications du prototype de corrélateurEn avançant dans l'intégration du corrélateur, j'ai remarqué plusieurs choses :
- L'autotuning de la taille du bloc de paquets qu'on traite est d'une complexité inutile quand la valeur 3 tunée manuellement semble optimale sur tous les C...En avançant dans l'intégration du corrélateur, j'ai remarqué plusieurs choses :
- L'autotuning de la taille du bloc de paquets qu'on traite est d'une complexité inutile quand la valeur 3 tunée manuellement semble optimale sur tous les CPUs que j'ai sous la main.
- Telle qu'elle est écrite actuellement, l'accumulation ne tire pas pleinement profit des instructions FMA (fused multiply-add) du CPU. Il est possible de les utiliser davantage avec une modif relativement simple de l'algorithme.
- Ma logique de prefetch est inutilement complexe, on peut faire aussi bien avec moins d'instructions prefetch.
- Au cours d'un refactoring de la fonction de prefetch, j'ai accidentellement cassé la compatibilité clang. C'est corrigé (et d'ailleurs, clang génère du code plus optimal que GCC maintenant, il y a longtemps c'était le contraire...).
- En fait, c'est ok de changer l'ordre des paquets dans le RAcqMemZoneMgr, c'est juste l'intérieur des paquets que je ne peux pas toucher. Du coup, je peux utiliser un layout de données un peu plus optimal : paquet 1 du flux 1, paquet 1 du flux 2, ..., paquet 1 du flux N, paquet 2 du flux 1, ...
Tout ça combiné permet quand même un gain de perf de +73% sur les processeurs AMD actuels (Zen 3). Bon, malheureusement sur nos processeurs Intel Cascade Lake l'impact n'est pas aussi énorme, on est plutôt dans les +10%, même si c'est toujours bon à prendre...https://gitlab.in2p3.fr/baoradio/tacq/-/merge_requests/10Draft: Develop2021-12-17T11:01:45+01:00GRASLAND HadrienDraft: Develophttps://gitlab.in2p3.fr/baoradio/tacq/-/merge_requests/9Intégration du nouveau corrélateur2022-03-04T11:38:54+01:00GRASLAND HadrienIntégration du nouveau corrélateurAu programme:
- [X] Un mécanisme pour générer des erreurs/warnings de compilation personnalisés.
- [X] Des outils pour contrôler les optimisations effectuées par le compilateur.
- [X] Des defines pour configurer le matériel cible (confi...Au programme:
- [X] Un mécanisme pour générer des erreurs/warnings de compilation personnalisés.
- [X] Des outils pour contrôler les optimisations effectuées par le compilateur.
- [X] Des defines pour configurer le matériel cible (configurés automatiquement quand c'est possible).
- [X] Une couche d'abstraction pour utiliser la vectorisation SIMD du CPU.
- [X] `RAcqMemZoneMgr` alloue des tampons bien alignés pour le SIMD.
- [x] Le contenu des tampons `RAcqMemZoneMgr` est rendu compatible avec cette nouvelle politique d'alignement (headers, taille des paquets...).
- [x] Du padding est injecté entre les FFTs par `RAcqMemZoneMgr` pour éviter les problèmes d'associativité de cache.
- [ ] Le code qui utilise `RAcqMemZoneMgr` est adapté à ces évolutions d'organisation des données en mémoire. **=> Réza s'est porté volontaire pour cette tâche.**
- [x] Le corrélateur est séparé entre une classe de base et une classe dérivée (avec un hook pour la réorganisation des données qui ne fait rien dans le corrélateur actuel).
- [x] Une nouvelle classe dérivée est créée utilisant le nouvel algorithme. **=> En cours**
- [x] mfacq est modifié pour utiliser la nouvelle classe.https://gitlab.in2p3.fr/baoradio/tacq/-/merge_requests/8Modernisation de TAcq2021-09-24T07:59:07+02:00GRASLAND HadrienModernisation de TAcqCette MR profite de la migration C++17 de TAcq pour aligner un peu plus le code TAcq avec les bonnes pratiques actuelles en C++:
**Préférer l'utilisation de `constexpr` à celle du préprocesseur**
Contrairement aux `#define` du préproce...Cette MR profite de la migration C++17 de TAcq pour aligner un peu plus le code TAcq avec les bonnes pratiques actuelles en C++:
**Préférer l'utilisation de `constexpr` à celle du préprocesseur**
Contrairement aux `#define` du préprocesseur...
- Une valeur `constexpr` possède un type bien défini et documenté au point de déclaration.
- Les erreurs dans la définition d'un constexpr ne sont signalées qu'au point de déclaration par le compilateur (et non à chaque point du code où la valeur est utilisée).
- `constexpr` est géré au niveau du langage, pas du préprocesseur, ce qui permet des fonctionnalités plus avancées comme effectuer des calculs non triviaux à la compilation.
- `constexpr` obéit aux règles normales de scoping du C++ : un `constexpr` n'est utilisable que dans le scope où il est déclaré, et les variables qu'il utilise sont obtenues depuis ce scope.
- `constexpr` obéit aux règles normales d'évaluation d'expressions du C++, pas de copier-coller pouvant avoir des conséquences inattendues en présence d'effets de bord.
- `constexpr` a un rôle bien défini (calculer et nommer des constantes de compilation), contrairement aux defines du preprocesseur qui sont utilisés pour tout et n'importe quoi : stocker des valeurs, rendre la compilation configurable, faire des calculs simples selon un formalisme piégeux, définir des types, afficher à la fois le code et la valeur d'une expression en debugging, faire des "fonctions" qui n'apparaissent pas dans les backtraces...
- Lorsque `constexpr` est utilisé pour activer/désactiver des fonctionnalités, il est possible de s'assurer que ces fonctionnalités restent compilées, et subissent donc une vérification minimale du compilateur. C'est un avantage par rapport au `#ifdef` classique qui ne vérifie pas que le code continue de compiler tant que le define n'est pas activé.
L'élimination du préprocesseur dans les endroits où il n'est pas nécessaire a nécessité des changements un peu invasifs dans certaines parties du code, notamment `dmamgrv6`. Si vous le souhaitez, je peux vous faire un petit tour de ce que j'ai fait spécifiquement dans ce module, et pourquoi je l'ai fait.
**Préférer l'utilisation de `nullptr` à celle de NULL**
Le C++ hérite du C la définition de NULL comme `#define NULL 0`. Cette définition est problématique car elle signifie que NULL peut, dans certains cas, être interprété comme un entier plutôt que comme un pointeur. `nullptr` n'a pas ce problème (il sera toujours traité comme un pointeur par le compilateur), et c'est donc la constante recommandée pour définir un pointeur nul depuis C++11.
**Préférer l'utilisation de la directive `#pragma once` à celle du trio `#ifndef GUARD`/`#define GUARD`/`#endif`**
Même si la directive `#pragma once` ne fait pas, stricto senso, partie de la norme C++17, elle est supportée par [tous les compilateurs C++17 que j'aie jamais utilisés](https://en.wikipedia.org/wiki/Pragma_once#Portability). Son intérêt par rapport aux header guards classique est de réduire la verbosité du code et éviter les erreurs liées au copier-coller du GUARD.
**Préférer l'utilisation de `noexcept` à celle de `throw()`**
La spécification d'exception vide `throw()` de C++98 souffre d'un défaut de conception qui l'empêche de fournir les bénéfices attendus en termes de qualité du code généré. La directive `noexcept` de C++11 n'a pas ce problème et répond à quasiment tous les cas d'utilisation de `throw()`, donc `throw()` est déprécié en C++17 et supprimé du langage en C++20.
**Préférer l'utilisation de `using` à celle de `typedef`**
La syntaxe de `using` est cohérente avec celle des expressions C++, donc moins perturbante, et elle a aussi le gros avantage de permettre la définition d'alias de types templatés. `using` est donc privilégié par rapport à `typedef` dans tous les nouveaux projets C++.
---
Globalement, suite à cette migration, j'aurais quelques questions concernant ce qui me semble être des `#define` dupliqués et qui devraient à mon humble avis être regroupés. Vous trouverez mes commentaires à ce sujet dans [le nouveau fichier `config.h`](https://gitlab.in2p3.fr/baoradio/tacq/-/blob/modernization/config.h).https://gitlab.in2p3.fr/baoradio/tacq/-/merge_requests/7Un peu de ménage dans le formatage du code2021-09-14T16:47:00+02:00GRASLAND HadrienUn peu de ménage dans le formatage du codeLe code de TAcq a accumulé au fil du temps un certain nombre de petites imperfections de formatage indésirables, comme par exemple l'ajout d'espace blanc superflu en fin de ligne ou l'utilisation du caractère tabulation (dont le rendu va...Le code de TAcq a accumulé au fil du temps un certain nombre de petites imperfections de formatage indésirables, comme par exemple l'ajout d'espace blanc superflu en fin de ligne ou l'utilisation du caractère tabulation (dont le rendu varie en fonction de la configuration de l'éditeur de texte du spectateur).
Cette MR enlève les défauts les plus gênants. Comme elle ne contient aucun changement de la sémantique du code, une revue ne me semble pas utile donc je vais la fusionner telle quelle. La fusionner séparément me permet de rendre plus lisible le diff de la MR de modernisation que je prépare qui essaie d'exploiter quelques nouvelles fonctionnalités de C++17 et des compilateurs modernes dans TAcq.https://gitlab.in2p3.fr/baoradio/tacq/-/merge_requests/6Migration vers les types stdint2021-09-08T17:22:57+02:00GRASLAND HadrienMigration vers les types stdintLa principale raison pour laquelle je voulais migrer les typedefs SOPHYA vers les types stdint de C99 est que cela permet ensuite de migrer l'ensemble du code de TAcq vers les types en question.
De cette façon, nous éliminons, au sein d...La principale raison pour laquelle je voulais migrer les typedefs SOPHYA vers les types stdint de C99 est que cela permet ensuite de migrer l'ensemble du code de TAcq vers les types en question.
De cette façon, nous éliminons, au sein de TAcq, la dichotomie piégeuse entre types entiers Sophya dont la taille se mesure en octets et types entiers TAcq dont la taille se mesure en bits, ce qui rend le code beaucoup plus facile à lire et modifier.
J'ai pris la liberté de migrer au passage les quelques utilisations de "short" et "long" vers leur équivalent sous Linux (où le code a vraisemblablement été testé), ce qui rend le code plus portable.https://gitlab.in2p3.fr/baoradio/tacq/-/merge_requests/5WIP: Compatibilité avec la branche stdint de Sophya2021-08-25T10:06:19+02:00GRASLAND HadrienWIP: Compatibilité avec la branche stdint de SophyaPuisque tacq définit ses propres types entiers de taille fixe, il faut synchroniser le code tacq avec le code Sophya quand on appliquera https://gitlab.in2p3.fr/SOPHYA/SophyaLib/-/merge_requests/3 à Sophya.
Mais je pense que c'est une e...Puisque tacq définit ses propres types entiers de taille fixe, il faut synchroniser le code tacq avec le code Sophya quand on appliquera https://gitlab.in2p3.fr/SOPHYA/SophyaLib/-/merge_requests/3 à Sophya.
Mais je pense que c'est une excellente occasion de faire un grand ménage au sed pour n'utiliser que les types stdint au sein de tacq, et c'est donc ce que je ferai ultérieurement dans cette branche, après m'être convaincu qu'elle fonctionne.https://gitlab.in2p3.fr/baoradio/tacq/-/merge_requests/4WIP: Unification des types entiers sur stdint2021-07-05T16:51:33+02:00GRASLAND HadrienWIP: Unification des types entiers sur stdintC'est une variante de la soumission !3 qui utilise les types standard C++ au lieu d'utiliser les types Sophya. Elle nécessite que https://gitlab.in2p3.fr/SOPHYA/SophyaLib/-/merge_requests/3 soit intégrée côté Sophya.C'est une variante de la soumission !3 qui utilise les types standard C++ au lieu d'utiliser les types Sophya. Elle nécessite que https://gitlab.in2p3.fr/SOPHYA/SophyaLib/-/merge_requests/3 soit intégrée côté Sophya.https://gitlab.in2p3.fr/baoradio/tacq/-/merge_requests/3WIP: Unification du jeu de types entiers de taille fixe2021-07-05T16:51:15+02:00GRASLAND HadrienWIP: Unification du jeu de types entiers de taille fixe**(Attention, cette merge request est basée sur !2 . On devrait probablement discuter de celle-là en premier, mais si vous voulez voir juste les modifs supplémentaires proposées ici, faites un tour par l'onglet "commits" de l'interface g...**(Attention, cette merge request est basée sur !2 . On devrait probablement discuter de celle-là en premier, mais si vous voulez voir juste les modifs supplémentaires proposées ici, faites un tour par l'onglet "commits" de l'interface gitlab et cliquez sur le deuxième commit dans l'ordre chronologique pour n'avoir que la partie du diff qui vient de cette merge request)**
Actuellement, le code TAcq mélange joyeusement deux ensembles de types entiers de taille fixe:
- Un ensemble de types entiers qui vient de Sophya (machdefs.h), où les tailles d'entiers sont données en octets (ex: uint_1 = entier non signé 8 bits).
- Un ensemble de types entiers spéficiques à TAcq (brtypes.h), où les tailles d'entiers sont généralement données en bits (ex: UInt32 = entier non signé 32 bits), mais pas que (exception Byte/SByte).
Personnellement, je trouve ce mélange fragile et piégeux:
- Je ne sais pas pour vous, mais de mon côté je suis sûr et certain qu'à un moment je vais me planter et écrire uint_8 quand je veux un entier 8 bits.
- Il suffit que les définitions Sophya et TAcq se désynchronisent pour que ça crée des problèmes. Par exemple, si Sophya est configurée pour utiliser long pour les entiers 64-bit alors que TAcq utilise long long, le code ne compilera pas, même si c'est effectivement le même type entier sous-jacent pour de nombreux compilateurs!
Je vous propose donc faire un peu de ménage et de s'accorder sur un seul jeu de types entiers de taille fixe utilisés pour l'ensemble du code TAcq.
Dans un monde idéal, on pourrait employer pour ça les [types entiers qui existent dans la bibliothèque standard du C et du C++](https://en.cppreference.com/w/cpp/header/cstdint), depuis les révisions C99 et C++11 du standard respectivement. Mais j'ai essayé pour vous dans une autre branche, ça ne marchera pas sans migrer d'abord Sophya vers ces types entiers (cf https://gitlab.in2p3.fr/SOPHYA/SophyaLib/-/issues/2 ), ce qui sera peut-être un peu trop invasif à votre goût.
Je vous propose donc, au moins dans un premier temps, le compromis moins invasif de migrer l'ensemble du code TAcq vers les types entiers de Sophya.https://gitlab.in2p3.fr/baoradio/tacq/-/merge_requests/2Proposition de reformatage automatique2021-07-05T16:51:25+02:00GRASLAND HadrienProposition de reformatage automatiqueJ'ai essayé de passer le code tacq dans le reformateur automatique clang-format dans l'espoir d'augmenter sa lisibilité via une plus grande régularité des espacements, de l'indentation, etc.
Voici le résultat que j'obtiens avoir un peu ...J'ai essayé de passer le code tacq dans le reformateur automatique clang-format dans l'espoir d'augmenter sa lisibilité via une plus grande régularité des espacements, de l'indentation, etc.
Voici le résultat que j'obtiens avoir un peu raffiné les réglages. Qu'en pensez-vous ?https://gitlab.in2p3.fr/baoradio/tacq/-/merge_requests/1Première version du corrélateur2021-03-04T12:35:00+01:00GRASLAND HadrienPremière version du corrélateurVoici une première version du corrélateur, qui devrait déjà vous permettre de lancer un premier benchmark sur pc-bao2 pour voir comment les choses se passent en attendant une intégration plus poussée au code tacq.Voici une première version du corrélateur, qui devrait déjà vous permettre de lancer un premier benchmark sur pc-bao2 pour voir comment les choses se passent en attendant une intégration plus poussée au code tacq.Reza ANSARIReza ANSARI