Ctags: ctags parallèles

Bonjour,

bien que l'implémentation parallèle intégrée puisse être intéressante, il est déjà possible de paralléliser la mise à jour d'une grosse base de code en lançant différents ctags sur différents répertoires, puis en fusionnant les fichiers générés (ce qui peut être fait simplement en supprimant les lignes commençant par ! de tous les fichiers sauf un et en utilisant sort --merge sur tous les fichiers par la suite).

Cependant, je ne suis pas convaincu que vous obtiendrez une accélération des ctags parallélisés, car je m'attends à ce que les machines modernes soient liées aux E/S. Cela aurait besoin d'être profilé pour s'en assurer cependant.

@mawww Je suis sûr que https://github.com/ggreer/the_silver_searcher ne serait pas d'accord :wink:

L'exécution de plusieurs ctags serait extrêmement difficile à coordonner à partir de l'emacs standard https://github.com/bbatsov/projectile/blob/master/projectile.el#L180 -L183

@mawww Je suis sûr que https://github.com/ggreer/the_silver_searcher ne serait pas d'accord :wink:

Bon point.

L'exécution de plusieurs ctags serait extrêmement difficile à coordonner à partir de l'emacs standard https://github.com/bbatsov/projectile/blob/master/projectile.el#L180 -L183

Un wrapper de script shell pourrait déjà aller très loin, mais oui, il pourrait être plus efficace de l'intégrer directement dans les ctags.

@fommil L'article de blog de ce type sur le sujet n'est pas très clair d'où il a commencé jusqu'où il est allé (enfin, vous pouvez le lire entre les lignes, mais bon), et de toute façon ce n'est vraiment pas grand-chose. Et je ne veux ignorer aucun de ses travaux, mais je ne vais pas faire entièrement confiance aux résultats de quelqu'un qui vient apparemment d'apprendre le multithreading (en particulier à cause de combien un mutex mal utilisé détruit toute performance que MT peut donner) . Je ne dis pas qu'il n'a pas tout à fait raison, mais j'aurai besoin d'être convaincu :)
Et notez comment ses propres tests ont montré que sur ses machines, trop de threads de travail devenaient rapidement pire qu'une absence de parallélisation du tout. C'est mignon, mais cela dépendra probablement fortement du matériel, du système d'exploitation et des données à traiter, donc cela devrait probablement être plus judicieux que "bien, l'utilisation de N threads semblait mieux fonctionner dans mes tests".

De plus, une autre raison pour laquelle cela ne m'attire pas autant est que non seulement je ne pense pas que cela nous apportera autant, mais ce sera aussi une grande quantité de travail sujet à erreur. Actuellement, la base de code CTags n'est absolument pas en mesure de prendre en charge les threads d'analyse de balises parallèles. Tout ce que vous _pourriez_ être en mesure de diviser relativement facilement est le parcours init/répertoire et _un seul_ thread d'analyse.
Et enfin, je suis convaincu que nous avons des optimisations plus sensées à effectuer partout dans la base de code (et en particulier dans les analyseurs).

Alors bien sûr, le multithreading _peut_ probablement avoir _quelques_ avantages s'il est très bien utilisé, mais ce n'est probablement pas l'amélioration la plus intéressante.

Aussi, une autre raison pour laquelle cela ne m'attire pas tellement est que […] ce sera une grande quantité de travail sujet aux erreurs. Actuellement, la base de code CTags n'est absolument pas en mesure de prendre en charge les threads d'analyse de balises parallèles. Tout ce que vous _pourriez_ être en mesure de diviser relativement facilement est le parcours init/répertoire et _un seul_ thread d'analyse.

BTW, je ne veux pas dire que l'amélioration de cette zone dans le code n'est pas une bonne idée, je pense que c'est le cas (en particulier pour un éventuel futur libctags). Je veux simplement dire que si la performance est l'objectif, cela n'en vaut probablement pas (actuellement) la peine, et qu'il y a un domaine plus important sur lequel se concentrer.

BTW, lancer un profileur et profiler un tas de données d'un milliard de manières serait probablement intéressant.

Le parallèle GNU peut vous aider.

Comme mentionné précédemment , l'optimisation de la lecture peut accélérer considérablement les ctags.

L'exécution parallèle d'analyseurs peut accélérer un peu les choses si les E/S proviennent du cache (et c'est souvent le cas la énième fois que vous exécutez des ctags sur un répertoire depuis un éditeur).

@pragmaware IMO, une bibliothèque ne doit pas bifurquer.

Si vous lisez du texte japonais, consultez l'article https://qiita.com/dalance/items/c76141a097e25fabefe8 .
(Après avoir écrit ce commentaire, j'ai trouvé le référentiel git pour les ptags (https://github.com/dalance/ptags). La page est écrite en anglais.)

Il signale un outil nommé ptags que l'auteur a développé. L'outil est écrit en Rust et enveloppe les ctags.
Il exécute des ctags en parallèle pour l'ensemble des entrées.
Je ne pille pas son interne. Cependant, il exécute évidemment plusieurs processus ctags.

Le résultat est assez impressionnant. 5 fois plus rapide qu'un traitement unique. Le nombre de processeurs n'est pas écrit. La taille de la mémoire peut être suffisante (=128 Go). L'auteur exécute 10 fois des ptags pour le même jeu d'entrées pour rendre le cache de page chaud.

Bien que ces choses doivent être faites dans des wrappers comme les ptags, il est difficile d'ignorer cet excellent résultat.
J'ai piraté rapidement. https://github.com/masatake/ctags/tree/parallel
L'option nouvellement introduite --_parallel exécute plusieurs processus ctags dans _parallel.

Le nombre de processus de travail, 8, est codé en dur. Mon PC note a 8 cœurs.
La MÉMOIRE est de 32 Go. L'entrée cible est la dernière arborescence des sources du noyau Linux.
Mon .ctags est assez poilu.

Le résultat est pratiquement le même : 2 à 3 fois plus rapide.

[yamato@master]~/var/ctags-github% cat run.sh
cat run.sh
for i in $(seq 1 5); do
    echo "#"
    echo "# TRAIL #$i"
    echo "#"
    echo "# parallel 8"
    time  ./ctags    --_parallel -R  ~/var/linux > /dev/null
    echo "# single"
    time  ./ctags -o - --sort=no -R  ~/var/linux > /dev/null
done
[yamato@master]~/var/ctags-github% bash run.sh 
bash run.sh 
#
# TRAIL #1
#
# parallel 8

real    0m29.073s
user    3m5.791s
sys 0m32.347s
# single

real    1m21.397s
user    1m14.601s
sys 0m6.521s
#
# TRAIL #2
#
# parallel 8

real    0m29.746s
user    3m4.601s
sys 0m32.175s
# single

real    1m26.660s
user    1m19.176s
sys 0m7.191s
#
# TRAIL #3
#
# parallel 8

real    0m28.290s
user    3m2.524s
sys 0m31.081s
# single

real    1m21.927s
user    1m14.775s
sys 0m6.896s
#
# TRAIL #4
#
# parallel 8

real    0m28.644s
user    3m3.839s
sys 0m31.756s
# single

real    1m13.319s
user    1m7.294s
sys 0m5.843s
#
# TRAIL #5
#
# parallel 8

real    0m29.274s
user    3m9.387s
sys 0m32.363s
# single

real    1m13.621s
user    1m7.487s
sys 0m5.941s
[yamato@master]~/var/ctags-github% 

(J'ai comparé les deux fichiers de balises. Il n'y a pas de différence.)

Loin d'être satisfaisant, mais c'est un bon point de départ.

Je me demande si la production des travailleurs doit être collectée ou non.

salut @masatake j'essaye de fermer tous mes tickets ouverts sur lesquels je n'ai pas l'intention de travailler. Si vous souhaitez travailler sur ce ticket, pourriez-vous copier le texte dans un nouveau ticket ?

Je travaillerai sur cet article à l'avenir. Je voudrais garder ce point ouvert car le compte rendu de la discussion ici sera précieux pour moi.

@masatake, vous pouvez toujours

@fommil , je ne vois pas comment vous pouvez remplacer @masatake , qui est la force motrice derrière Universal Ctags, avec 2 700 commits par rapport à votre nombre de commits de zéro. Une fois que vous ouvrez un bogue (ou, dans le jargon GitHub, "problème"), ce bogue devient la propriété du projet. Je pense que vous pouvez ne plus le regarder et ne pas recevoir d'e-mails à ce sujet.

Réouverture.

@dtikhonov @masatake veuillez fermer ce ticket. C'est le seul ticket dans ma vue https://github.com/issues qui n'est pas pertinent pour mon travail.

Il n'est pas possible de supprimer un ticket de cette vue à moins que le ticket ne soit fermé. Même si je me désinscris.

En effet, je ne savais pas que les propriétaires de repo auraient ce contrôle lorsque j'ai créé le ticket, sinon je ne l'aurais pas fait.

si vous souhaitez travailler dessus, veuillez créer un nouveau ticket et référencer ce ticket, toutes les discussions sont préservées. Ou copiez simplement le contenu de https://github.com/universal-ctags/ctags/issues/761#issuecomment -373720839 dans un nouveau ticket.

Je ne pense pas que ce soit beaucoup pour moi de demander.

Pourriez-vous créer un compte GitHub temporel juste pour copier-coller ?
Vous pouvez donc faire un copier-coller vous-même.
Ensuite, vous pouvez supprimer le compte.

bien sûr, si c'est la seule façon de résoudre ce problème, je peux le faire.

Fini! Merci de m'avoir permis de fermer ce ticket. Cela nettoie considérablement ma tâche TODO.