vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2023-05-12T16:09:40+02:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/5144Large amount of memory used by Vidjil-algo2023-05-12T16:09:40+02:00Mikaël SalsonLarge amount of memory used by Vidjil-algoUn étudiant me signale que sur une machine avec 30G de RAM, Vidjil-algo utilise trop de mémoire : DRR346909, DRR346911 et DRR346910. Les jeux de données font une trentaine de Go.Un étudiant me signale que sur une machine avec 30G de RAM, Vidjil-algo utilise trop de mémoire : DRR346909, DRR346911 et DRR346910. Les jeux de données font une trentaine de Go.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4691--filter-reads : débrancher complètement la gestion des windows2021-03-18T14:23:30+01:00Mathieu Giraud--filter-reads : débrancher complètement la gestion des windowsThe following discussion from !906 should be addressed:
> D'ailleurs, en `--filter-reads`, on n'aurait pas besoin de stocker les windows... mais bon, on peut supposer que c'est négligeable (en temps, peut-être pas en mémoire).
Si on va...The following discussion from !906 should be addressed:
> D'ailleurs, en `--filter-reads`, on n'aurait pas besoin de stocker les windows... mais bon, on peut supposer que c'est négligeable (en temps, peut-être pas en mémoire).
Si on va par là, refactor nécessaire (ou bien nouvelle commande vraiment indépendante qui lance juste le KmerSegmenter).
Ping #1180.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4678Reproductibilité valgrind_functional / gzip2024-02-06T07:47:44+01:00Mathieu GiraudReproductibilité valgrind_functional / gzip
Voir https://gitlab.inria.fr/vidjil/vidjil/-/merge_requests/884#note_460619
Actuellement on a `allow_failure: true` pour #4460, mais à terme ce serait bien de ne plus l'avoir
Comprendre ce qui loupe. Éventuellement récupérer cela avec...
Voir https://gitlab.inria.fr/vidjil/vidjil/-/merge_requests/884#note_460619
Actuellement on a `allow_failure: true` pour #4460, mais à terme ce serait bien de ne plus l'avoir
Comprendre ce qui loupe. Éventuellement récupérer cela avec should pour qu'un test du par exemple à un timeout soit simplement marqué `skip` et qu'on puisse se focaliser sur les vrais problèmes décelés par `valgrind`.Algo 2022.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/4445fuse.py : se souvenir de tous les clones, mais ne pas les sortir ?2020-08-03T10:49:48+02:00Mathieu Giraudfuse.py : se souvenir de tous les clones, mais ne pas les sortir ?Vu avec @flothoni
Actuellement, pour avoir un calcul exact, il faudrait `-t 10000` ou plus, mais soucis de mémoire ou autre...
Peut-être une nouvelle option `-T` qui garde "tout" en mémoire (mais de manière la plus légère possible pou...Vu avec @flothoni
Actuellement, pour avoir un calcul exact, il faudrait `-t 10000` ou plus, mais soucis de mémoire ou autre...
Peut-être une nouvelle option `-T` qui garde "tout" en mémoire (mais de manière la plus légère possible pour ceux après le `-t`, comme ce qu'on veut pour !724).
Mais finalement cela a probablement peu d'impact pour !465 dans la plupart des cas, on expérimentera déjà !465 avec ce qu'on a.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4285Profiler la gestion du cache2020-05-07T18:46:56+02:00Mathieu GiraudProfiler la gestion du cacheExtrait de https://gitlab.inria.fr/vidjil/vidjil/-/merge_requests/687#note_333367 :
>>> Au passage, j'ai essayé également `'F'` ("major, or I/O-requiring, page faults"), mais ce sont les swaps, on n'en n'est pas à là, cela donnait 0. C...Extrait de https://gitlab.inria.fr/vidjil/vidjil/-/merge_requests/687#note_333367 :
>>> Au passage, j'ai essayé également `'F'` ("major, or I/O-requiring, page faults"), mais ce sont les swaps, on n'en n'est pas à là, cela donnait 0. Ce sont les "caches miss" qui seraient intéressants, mais je n'ai pas l'impression que `/usr/bin/time` les donne. Peut-être `perf` un jour (mais impacte ce que l'on mesure ?).
>>
>> Mais `perf` compte les instructions, pas le temps qu'elles prennent, si ?
>
> Oui, mais ce sont des comptes très pertinents. Probablement réduire les `cache-misses` serait décisif. Mais pas l'habitude de l'utiliser. http://www.brendangregg.com/perf.html
> `perf stat -e task-clock,cycles,instructions,cache-references,cache-misses ./vidjil-algo -c clones -g germline/homo-sapiens.g:IGH -3 demo/Stanford_S22.fasta`
> donne chez moi (pendant que... d'autres grosses choses tournent) :
```
3 041,65 msec task-clock # 0,974 CPUs utilized
7 425 138 862 cycles # 2,441 GHz
4 823 469 985 instructions # 0,65 insn per cycle
164 216 352 cache-references # 53,989 M/sec
114 336 345 cache-misses # 69,625 % of all cache refs
3,123097672 seconds time elapsed
2,744731000 seconds user
0,297908000 seconds sys
```https://gitlab.inria.fr/vidjil/vidjil/-/issues/3559Avoir explicitement un test valgrind dans les should-get2018-10-16T13:37:44+02:00Mathieu GiraudAvoir explicitement un test valgrind dans les should-getOn a certes des tests valgrind poussés dans le stage qu'il faut, mais cela fait du bien d'avoir un test valgrind simple qui tourne tout le temps et décèle des erreurs en amont, quand on fait des tests sur nos machines. Actuellement `bugs...On a certes des tests valgrind poussés dans le stage qu'il faut, mais cela fait du bien d'avoir un test valgrind simple qui tourne tout le temps et décèle des erreurs en amont, quand on fait des tests sur nos machines. Actuellement `bugs/bug20141024.should-get` joue ce rôle, mais ce n'est pas très explicite.
Il pourrait y avoir un test ~"dev\-tests\-should\-get" qui fait cela.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3392Profilage de l'espace mémoire utilisé par Vidjil-algo2020-04-29T12:50:19+02:00Mikaël SalsonProfilage de l'espace mémoire utilisé par Vidjil-algoOn se pose des questions sur l'espace mémoire qu'on pourrait gagner dans l'algo (#3389) mais en fait on ne sait pas vraiment où est dépensé l'espace mémoire.
#2120 nous montre un exemple où, hors pic de la fin d'exécution, on arrive à e...On se pose des questions sur l'espace mémoire qu'on pourrait gagner dans l'algo (#3389) mais en fait on ne sait pas vraiment où est dépensé l'espace mémoire.
#2120 nous montre un exemple où, hors pic de la fin d'exécution, on arrive à environ 1,5 Go. Or on a 1M de reads, on trouve des fenêtres dans 500k d'entre eux. On stocke des informations relatives uniquement à ces 500k reads.
Ces reads ont une longueur moyenne de 260bp. Dans #3389 on a listé les différents champs stockés pour les reads. En voyant large on doit arriver à 1ko par read. Cela nous ferait 500 Mo. Il manque environ 1Go. Qu'est-ce que je loupe d'important ?
Il y a bien des informations stockées par rapport au statut de la segmentation, aux longueurs moyennes, mais ça me semble assez négligeable à côté des reads.
Si on n'est pas capable de déterminer l'origine du Go manquant, cela signifie qu'on a besoin d'un profilage de la mémoire utilisée par le programme pour mieux situer les axes d'amélioration.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3391Stocker les k-mers pour la représentative au lieu de stocker les séquences2018-07-17T20:38:47+02:00Mathieu GiraudStocker les k-mers pour la représentative au lieu de stocker les séquencesDepuis https://gitlab.inria.fr/vidjil/vidjil/issues/3389#note_106473 :
> stocker directement les informations qui nous intéressent (comptages de k-mers pour l'instant pour la représentative,Depuis https://gitlab.inria.fr/vidjil/vidjil/issues/3389#note_106473 :
> stocker directement les informations qui nous intéressent (comptages de k-mers pour l'instant pour la représentative,https://gitlab.inria.fr/vidjil/vidjil/-/issues/3389Séquences stockées dans `seqs_by_window` : champs, compression ?2018-07-18T09:58:40+02:00Mathieu GiraudSéquences stockées dans `seqs_by_window` : champs, compression ?Une réflexion parallèle à #2120/#3387 : l'espace mémoire au cours de la phase 1 provient quasi totalement de
`map<junction, BinReadStorage > seqs_by_window`. Vu ce qu'il y a dans le `BinReadStorage`, il est probable que cela soit dominé ...Une réflexion parallèle à #2120/#3387 : l'espace mémoire au cours de la phase 1 provient quasi totalement de
`map<junction, BinReadStorage > seqs_by_window`. Vu ce qu'il y a dans le `BinReadStorage`, il est probable que cela soit dominé par les `list<Sequence> *bins`. Dans une `Sequence`, il y a :
```
typedef struct read_t
{
string label_full;
string label;
string sequence; // Sequence: original string representation
string quality;
int* seq; // Sequence: seq representation
size_t marked_pos; // Some marked position in the sequence
} Sequence;
```
Est-ce que tout cela est vraiment conservé et utile ?
- La `quality` double la taille (mais elle est utile pour la representative, c'est cela ?)
- `label_full` et `label` pourraient être supprimés (mais bon, quasi-négligeable ?), sauf quand on veut `-a` ou `-u`
- Est-ce que cela aurait un intérêt de stocker `sequence` et `quality` de manière compressée ?
cc @boreechttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3114Filtrage de BioReader sans re-réserver de la mémoire2018-04-03T17:03:11+02:00Mathieu GiraudFiltrage de BioReader sans re-réserver de la mémoireÉchange par mail, @magiraud, à propose de #3080 :
> Actuellement on a pas de moyen d’accéder à une séquence quelconque d’un BioReader.
>- effectivement #3080 est possible (comme méthode de `BioReader` ?). J’ai l’impression qu’elle va re...Échange par mail, @magiraud, à propose de #3080 :
> Actuellement on a pas de moyen d’accéder à une séquence quelconque d’un BioReader.
>- effectivement #3080 est possible (comme méthode de `BioReader` ?). J’ai l’impression qu’elle va recréer un autre `BioReader` en O(répertoire filtré) avec *réservation mémoire* et écritures, c’est un peu bourrin… on pourrait certes dire que c’est peu comparé au O(répertoire filtré x taille read) de `align_against_collection` (qui réserve aussi de la mémoire au passage).
>- y aurait-il sinon une manière de le faire avec une méthode d’un `BioReader` qui, à partir d’une liste d’identifiant, itère et renvoie les séquences ? Même si c’est en O(répertoire initial) au début, il pourrait y avoir ensuite des changements dans `BioReader` qui fait cela en O(répertoire filtré)
@mikael-s :
> Oui ça serait possible mais pas sûr que cela change grand chose : l'utilisation mémoire restera négligeable par rapport à celle de la programmation dynamique.
Bref on fait #3080 comme prévu, pas de soucis pour cela.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2251Minimisation de l'automate2017-03-16T07:20:25+01:00Mathieu GiraudMinimisation de l'automateÀ table, Laurent demandait si on avait essayé de minimiser l'automate. Cela pourrait faire gagner de la mémoire (mais est-ce vraiment une limite ?). Tout dépend de la topologie de notre automate...
cc @mikael-sÀ table, Laurent demandait si on avait essayé de minimiser l'automate. Cela pourrait faire gagner de la mémoire (mais est-ce vraiment une limite ?). Tout dépend de la topologie de notre automate...
cc @mikael-s