Ctags: ctags paralelas

Olá,

embora a implementação paralela possa ser interessante, já é possível paralelizar a atualização de uma grande base de código lançando ctags diferentes em um diretório diferente e, em seguida, mesclando os arquivos gerados (o que pode ser feito simplesmente eliminando as linhas que começam com! de todos os arquivos menos um e usando sort --merge em todos os arquivos posteriormente).

No entanto, não estou convencido de que você obterá qualquer aumento de velocidade com ctags paralelizados, pois espero que as máquinas modernas sejam vinculadas a E / S. Isso precisaria ser traçado para ter certeza.

@mawww Tenho certeza de que https://github.com/ggreer/the_silver_searcher discordaria: wink:

A execução de vários ctags seria extremamente difícil de coordenar a partir do emacs padrão https://github.com/bbatsov/projectile/blob/master/projectile.el#L180 -L183

@mawww Tenho certeza de que https://github.com/ggreer/the_silver_searcher discordaria: wink:

Bom ponto.

A execução de vários ctags seria extremamente difícil de coordenar a partir do emacs padrão https://github.com/bbatsov/projectile/blob/master/projectile.el#L180 -L183

Um wrapper de script de shell já pode percorrer um longo caminho, mas sim, pode ser mais eficiente integrá-lo diretamente em ctags.

@fommil A sobre o assunto não é muito clara de onde começou até para onde foi (bem, você pode ler nas entrelinhas, mas bem) e, de qualquer forma, não é muito. E não quero desconsiderar seu trabalho, mas não vou confiar totalmente nos resultados de alguém que aparentemente acabou de aprender sobre multithreading (especialmente por causa de quanto um mutex mal utilizado destrói qualquer desempenho que o MT pode dar) . Não estou dizendo que ele não está totalmente certo, mas preciso ser convencido :)
E observe como seus próprios testes mostraram que em suas máquinas muitos threads de trabalho rapidamente se tornaram piores do que a ausência de paralelização. É bonito, mas provavelmente depende muito do hardware, sistema operacional e dados para processar, então provavelmente deve ser mais sensato do que "bem, usar N threads parece ter um desempenho melhor em meus testes".

Além disso, outra razão pela qual isso não me atrai tanto é que não só não acredito que isso nos dará tanto, mas será uma grande quantidade de trabalho sujeito a erros. Atualmente, a base de código CTags não tem absolutamente nenhuma forma de suportar tags paralelas que analisam threads. Tudo que você _pode_ ser capaz de dividir com relativa facilidade é a travessia de diretório init / e _um single_ thread do analisador.
E, finalmente, estou confiante de que temos otimizações mais sensatas para executar em qualquer lugar na base de código (e especialmente nos analisadores).

Portanto, com certeza, o multithreading provavelmente _pode_ ter _alguns_ benefícios se usado muito bem, mas provavelmente não é o aprimoramento mais interessante.

Além disso, outra razão pela qual não me atrai tanto é que [...] será uma grande quantidade de trabalho sujeito a erros. Atualmente, a base de código CTags não tem absolutamente nenhuma forma de suportar tags paralelas que analisam threads. Tudo que você _pode_ ser capaz de dividir com relativa facilidade é a travessia de diretório init / e _um single_ thread do analisador.

BTW, não quero dizer que melhorar esta área no código não seja uma boa ideia, eu acho que é (especialmente para uma possível libctags futura). Só quero dizer que, se o objetivo é o desempenho, provavelmente não vale (atualmente) o esforço e que há uma área mais importante em que se concentrar.

BTW, iniciar um profiler e traçar um perfil de uma grande quantidade de dados de zilhões de maneiras provavelmente seria interessante.

Paralelo GNU pode ajudá-lo.

Como mencionado antes , otimizar a leitura pode acelerar um pouco as ctags.

A execução paralela de analisadores pode acelerar um pouco as coisas se a E / S vier do cache (e este é freqüentemente o caso na enésima vez que você executa ctags em um diretório a partir de um editor).

@pragmaware IMO, uma biblioteca não deve se bifurcar.

Se você lê um texto em japonês, consulte o artigo https://qiita.com/dalance/items/c76141a097e25fabefe8 .
(Depois de escrever este comentário, encontrei o repositório git para ptags (https://github.com/dalance/ptags). A página está escrita em inglês.)

Ele relata uma ferramenta chamada ptags desenvolvida pelo autor. A ferramenta foi escrita em Rust e envolve ctags.
Ele executa ctags em paralelo para o conjunto de entrada.
Eu não saqueio em seu interior. No entanto, ele obviamente executa vários processos ctags.

O resultado é bastante impressionante. 5 vezes mais rápido do que o processamento único. O número de cpus não é escrito. O tamanho da memória pode ser suficiente (= 128 GB). O autor executa 10 vezes ptags para o mesmo conjunto de entrada para tornar o cache de página ativo.

Embora essas coisas devam ser feitas em invólucros como ptags, é difícil ignorar esse ótimo resultado.
Eu cortei rapidamente. https://github.com/masatake/ctags/tree/parallel
A opção recém-introduzida --_ parallel executa vários processos ctags em _parallel.

O número de processos de trabalho, 8, é codificado. Meu note PC tem 8 núcleos.
MEMÓRIA tem 32 GB. A entrada de destino é a árvore de origem do kernel Linux mais recente.
Minhas .ctags são bastante cabeludas.

O resultado é basicamente o mesmo: 2 ~ 3 vezes mais rápido.

[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% 

(Eu copiei os dois arquivos de tags. Não há diferença.)

Longe de ser satisfatório, mas é um bom lugar para começar.

Eu me pergunto se a produção dos trabalhadores deve ser recolhida ou não.

oi @masatake , estou tentando fechar todos os meus tíquetes abertos nos quais não pretendo trabalhar. Se você estiver interessado em trabalhar neste tíquete, por favor, copie o texto em um novo tíquete?

Vou trabalhar neste item no futuro. Eu gostaria de manter este item aberto porque o registro da discussão aqui será valioso para mim.

@masatake você ainda pode criar um link para este tíquete a partir de um novo e manter o histórico completo. Isso realmente me ajudaria, pois estou tentando limpar minha guia "Problemas" para um novo trabalho e não quero uma desordem como este tíquete no caminho.

@fommil , não vejo como você pode substituir @masatake , que é a força motriz por trás do Universal Ctags, com 2.700 commits contra sua contagem de commit de zero. Depois de abrir um bug (ou, no jargão do GitHub, "problema"), ele se torna propriedade do projeto. Acredito que você pode desbloqueá-lo e não receber nenhum e-mail sobre ele.

Reabertura.

@dtikhonov @masatake feche este tíquete. É o único tíquete na minha visualização https://github.com/issues que não é relevante para o meu trabalho.

Não é possível remover um tíquete desta visualização, a menos que o tíquete seja fechado. Mesmo se eu cancelar.

Na verdade, eu não sabia que os proprietários do repo teriam esse controle quando criei o tíquete, caso contrário, não o teria feito.

se você quiser trabalhar nisso, crie um novo tíquete e faça referência a esse tíquete, toda a discussão será preservada. Ou apenas copie e cole o conteúdo de https://github.com/universal-ctags/ctags/issues/761#issuecomment -373720839 em um novo tíquete.

Não creio que seja pedir muito.

Você poderia fazer uma conta GitHub temporal apenas para copiar e colar?
Assim, você mesmo pode copiar e colar.
Então, você pode remover a conta.

claro, se essa é a única maneira de consertar isso, eu posso fazer isso.

feito! Obrigado por me deixar fechar este tíquete. Ele limpa minha tarefa TODO significativamente.