Xavier Richez
La fonction explore_state_dutch est utilisée par l'outil Polylex lors du traitement en néerlandais.
Elle prend en entrée une chaîne de caractères Unicode "word_to_analyze" qui est traité de manière récursive, en incrémentant l'index "pos_in_word_to_analyze".
Ne devrait-on pas vérifier, à un moment où un autre, que pos_in_word_to_analyze est bien dans les limites de word_to_analyze ?
Je pose cette question car nous sommes confrontés à un cas étrange où Polylex s'affole : la mémoire utilisée par le processus grimpe, grimpe... jusqu'à ce qu'il soit tué par le serveur (SIGKILL) peu avant 4 Go (capacité mémoire du serveur).
Avez-vous déjà rencontré ce type de comportement ?
Ci-joint le fichier qui fait planter Polylex (zippé pour ne pas l'altérer).
La commande exacte est :
PolyLex --dutch -aAlphabet.txt -dnl.bin -opolylex.txt -ipolylex_decomp.txt polylex.input
Merci pour votre aide :)
Laurent Kevers
Bonjour,
Petite précision concernant le message de Xavier : le comportement décrit ci-dessous (utilisation de toute la mémoire disponible en très peu de temps) est obtenu lorsque polyLex est confronté à des mots assez longs.
Dans le fichier fourni en pièce jointe, il y a par exemple :
- deeerstebeslissingwerdingetrokkennadatdoorverzoekereenofficieelarrestatiebevel
- tezijnaangemaandwerdhervatmiddelsuitnodigingtotherverhoor
- vierjaarsamenwerkingindezelfdeomstandighedenishetredelijkteverwachtendatmenditmeerdanvoldoendekan
Ces mots sont, selon toute évidence incorrects, et probablement issus d'une concaténation lors d'un prétraitement (peut-être lors de l'OCRisation d'un document).
Si c'est bien la longueur du mot qui pose problème, et étant donné :
1. la nature agglutinante des mots composés en néerlandais, il est compliqué de déterminer une longueur au delà de laquelle le mot est à coup sur le fruit d'une telle erreur;
2. d'autre part, il n'est pas exclu qu'un mot correct atteigne une longueur qui pose problème à polyLex;
il semble donc difficile de contourner le problème en se basant uniquement sur le critère de la longueur du mot...
Je rebondis donc sur le message de Xavier qui a localisé le problème dans la fonction explore_state_dutch.
Est-ce que quelqu'un aurait une idée plus précise de ce qui peut poser des difficultés à ce niveau avec des mots longs tels que ceux mentionnés ci-dessus?
REM: il s'agit bien ici d'un problème différent de la fuite mémoire signalée dans le message de Xavier du 11 septembre.
Merci !
Laurent
Gilles Vollant
je n'ai pas l'impression que pos_in_word_to_analyze dépasse la taille du (très grand) mot, mais que l'on fait beaucoup de récursion d'une fonction très gourmande en pile
explore_state_dutch en effet alloue beaucoup de tableau énorme sur la pile...
Gilles Vollant
Bonjour
Où peut-on trouver nl.bin (et.inf) ?
De : unitex-...@googlegroups.com [mailto:unitex-...@googlegroups.com] De la part de Gilles Vollant
Envoyé : lundi 20 octobre 2014 08:46
À : unitex-...@googlegroups.com
Objet : [Unitex-GramLab] Re: Unitex-C++ / fonction explore_state_dutch
--
You received this message because you are subscribed to the Google Groups "Unitex-GramLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unitex-gramla...@googlegroups.com.
To post to this group, send email to unitex-...@googlegroups.com.
Visit this group at http://groups.google.com/group/unitex-gramlab.
To view this discussion on the web visit https://groups.google.com/d/msgid/unitex-gramlab/bc48b6b5-f5bc-4930-b572-e62af249ae46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Gilles Vollant
Gilles Vollant
Voici deux versions de test de DutchCompounds.cpp (il faut les souces Unitex de la révision 3673 ou supérieur) dans le zip
DutchCompounds.cpp.v1
DutchCompounds.cpp.v2
La v2 est une évolution de la v1 qui doit consommer mois de mémoire. Je ne vous donne la v1 que par précaution, si la v2 ne fonctionne pas
En début de fichier, j’ai ajouté une constante MAX_NB_WORD_DECOMPOSITION_LIST_POSSIBLE qui fixe le nombre maximum d’élément dans la liste chainée word_decomposition_list avant d’abandonner (et il vaut mieux abandonner à un moment l’exploration que de planter).
Justement, la V2 doit permettre de « monter » plus haut, car dans le code original et dans la v1, chaque item prend 16 Ko et dans la v2 la taille est calculée au plus juste.
Essayez aussi différente valeur de MAX_NB_WORD_DECOMPOSITION_LIST_POSSIBLE. On peut monter à au moins 100 000.
Commencer par vérifier que tout fonctionne toujours (et sans perte de performance) dans les cas normaux
Après, ma limite est que je ne connais pas la logique linguistique sous-jacente…
A bientôt
Gilles Vollant
Le vendredi 12 septembre 2014 19:00:15 UTC+2, Xavier Richez a écrit :
Laurent Kevers
Merci pour ces deux versions. Je viens de tester cela. Elles tournent toutes deux sans le problème de mémoire (on reste en dessous des 3% utilisés) et ramènent le même nombre de résultats.
J'ai fait varier la constante MAX_NB_WORD_DECOMPOSITION_LIST_POSSIBLE, le résultat a été identique pour chaque test. Il y a cependant de grandes différences de performances:
- 100000/10: 1.4s (valeur initiale)
- 500000/10: 16.4s
- 1000000/10: 60s
- 10000/10: 0.091s
- 1000/10: 0.43s
- 100/10: 0.35s
Petite nuance, lorsque je dis que le résultat est identique, cela signifie que PolyLex sort le même message "xxx words decomposed as compound words". J'ai cependant pu observer certaines différences dans les fichiers de sortie obtenus avec les options -o et/ou -i. En fonction de la valeur de la constante, il y a plus ou moins de variantes de décompositions qui sont proposées. A noter que, contrairement à ce qu'on pourrait attendre, ce nombre ne varie pas nécessairement de manière croissante/décroissante lorsque la valeur de la constante est augmentée/diminuée (est-ce logique, je ne saurais le dire... ? Peut-être y-a-t'il des règles qui éliminent des décompositions très fragmentées au profit de celles qui le sont moins, lorsque ces dernières sont découvertes. Je n'ai malheureusement pas une connaissance suffisante du code pour pouvoir le dire).
J'ai également testé la v2 sur plusieurs documents qui étaient analysés sans problème par la version originale de PolyLex. J'ai obtenu les même résultats avec la version modifiée (MAX_NB_WORD_DECOMPOSITION_LIST_POSSIBLE=10000/10). Les temps d'exécution sur ces documents ne posant pas de problème (c.-à-d. n'incluant pas de mots très longs) sont relativement similaires quelque soient les valeurs de la constante et restent dans l'ordre de grandeur obtenu avec le code original (svn 3675).
D'après ces tests, la modification me semble donc bénéfique pour éviter le plantage obtenu lorsque des mots très longs sont rencontrés. Je ne suis par contre pas certain de savoir quelle serait la valeur la plus indiquée pour MAX_NB_WORD_DECOMPOSITION_LIST_POSSIBLE. A priori, parmi les valeurs testées, celles qui me semblent possibles sont 10000/10 (les valeurs plus faibles donnent des décompositions qui, dans le cas des mots longs, me semblent plus/trop fragmentées) et 100000/10 (les valeurs plus élevées semblent ralentir beaucoup l'analyse lorsqu'on rencontre des mots très longs).
Laurent
Gilles Vollant
Gilles Vollant
Xavier Richez
Le vendredi 12 septembre 2014 19:00:15 UTC+2, Xavier Richez a écrit :