Ctags: ctags paralelos

Hola,

Si bien la implementación en paralelo puede ser interesante, ya es posible paralelizar la actualización de una gran base de código lanzando diferentes ctags en diferentes directorios y luego fusionando los archivos generados (lo que se puede hacer simplemente eliminando las líneas que comienzan con! de todos los archivos excepto uno y usando sort --merge en todos los archivos después).

Sin embargo, no estoy convencido de que obtenga ninguna aceleración de los ctags paralelizados, ya que espero que las máquinas modernas estén vinculadas a la E / S. Sin embargo, eso tendría que ser perfilado para asegurarse.

@mawww Estoy seguro de que https://github.com/ggreer/the_silver_searcher no estaría de acuerdo: wink:

Ejecutar múltiples ctags sería extremadamente difícil de coordinar desde el emacs estándar https://github.com/bbatsov/projectile/blob/master/projectile.el#L180 -L183

@mawww Estoy seguro de que https://github.com/ggreer/the_silver_searcher no estaría de acuerdo: wink:

Buen punto.

Ejecutar múltiples ctags sería extremadamente difícil de coordinar desde el emacs estándar https://github.com/bbatsov/projectile/blob/master/projectile.el#L180 -L183

Un contenedor de script de shell ya podría ser de gran ayuda, pero sí, podría ser más eficiente integrarlo directamente en ctags.

@fommil La entrada de blog de ese tipo sobre el tema no está muy clara desde dónde comenzó hasta dónde fue (bueno, puedes leerla entre líneas, pero bueno), y de todos modos no es tanto. Y no quiero ignorar nada de su trabajo, pero no voy a confiar plenamente en los resultados de alguien que aparentemente acaba de aprender sobre el multihilo (especialmente por, por ejemplo, cuánto un mutex mal utilizado destruye cualquier rendimiento que MT puede dar) . No digo que no tenga toda la razón, pero tendré que estar convencido :)
Y observe cómo sus propias pruebas mostraron que en sus máquinas demasiados subprocesos de trabajo rápidamente se volvieron peores que una falta de paralelización. Es lindo, pero probablemente dependa en gran medida del hardware, el sistema operativo y los datos a procesar, por lo que probablemente debería ser más sensato que "bueno, el uso de N subprocesos pareció funcionar mejor en mis pruebas".

Además, otra razón por la que no me atrae tanto es que no solo no creo que nos dé tanto, sino que será una gran cantidad de trabajo propenso a errores. Actualmente, la base del código CTags no está en ninguna forma para admitir subprocesos de análisis de etiquetas paralelas. Todo lo que _podría_ ser capaz de dividir con relativa facilidad es el recorrido del directorio init / y _un hilo del analizador único_.
Y finalmente, estoy seguro de que tenemos optimizaciones más sensatas para realizar en todas partes del código base (y especialmente en los analizadores).

Así que seguro, el multihilo probablemente _puede_ tener _algunos_ beneficios si se usa muy bien, pero probablemente no sea la mejora más interesante.

Además, otra razón por la que no me atrae tanto es que […] será una gran cantidad de trabajo propenso a errores. Actualmente, la base del código CTags no está en ninguna forma para admitir subprocesos de análisis de etiquetas paralelas. Todo lo que _podría_ ser capaz de dividir con relativa facilidad es el recorrido del directorio init / y _un hilo del analizador único_.

Por cierto, no quiero decir que mejorar esta área en el código no sea una buena idea, creo que sí lo es (especialmente para una posible futura biblioteca). Solo quiero decir que si el objetivo es el rendimiento, probablemente (actualmente) no valga la pena el esfuerzo y que hay áreas más importantes en las que concentrarse.

Por cierto, activar un generador de perfiles y generar perfiles de una gran cantidad de datos en un billón de formas probablemente sería interesante.

El paralelo GNU puede ayudarte.

Como se mencionó anteriormente , optimizar la lectura puede acelerar un poco las etiquetas.

La ejecución paralela de analizadores podría acelerar un poco las cosas si la E / S proviene de la caché (y este suele ser el caso la enésima vez que ejecuta ctags en un directorio desde un editor).

@pragmaware En mi opinión , una biblioteca no debería bifurcarse.

Si lee texto en japonés, consulte el artículo https://qiita.com/dalance/items/c76141a097e25fabefe8 .
(Después de escribir este comentario, encontré el repositorio de git para ptags (https://github.com/dalance/ptags). La página está escrita en inglés).

Informa sobre una herramienta llamada ptags que desarrolló el autor. La herramienta está escrita en Rust y envuelve ctags.
Ejecuta ctags en paralelo para el conjunto de entrada.
No saqueo en su interior. Sin embargo, obviamente ejecuta múltiples procesos ctags.

El resultado es bastante impresionante. 5 veces más rápido que el procesamiento único. No se escribe el número de cpus. El tamaño de la memoria puede ser suficiente (= 128 GB). El autor ejecuta ptags 10 veces para el mismo conjunto de entrada para hacer que la caché de la página esté activa.

Aunque estas cosas deben hacerse en envoltorios como ptags, es difícil ignorar este gran resultado.
Pirateé rápidamente. https://github.com/masatake/ctags/tree/parallel
La opción recién introducida --_ paralelo ejecuta múltiples procesos ctags en _parallel.

El número de procesos de trabajo, 8, está codificado de forma rígida. Mi PC de notas tiene 8 núcleos.
La MEMORIA es de 32 GB. La entrada de destino es el último árbol de fuentes del kernel de Linux.
Mi .ctags es bastante peludo.

El resultado es prácticamente el mismo: 2 ~ 3 veces más 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% 

(He comparado el archivo de ambas etiquetas. No hay diferencia).

Lejos de ser satisfactorio, es un buen punto de partida.

Me pregunto si la producción de los trabajadores debe recopilarse o no.

hola @masatake Estoy tratando de cerrar todos mis tickets abiertos en los que no planeo trabajar. Si está interesado en trabajar en este boleto, ¿podría copiar el texto en un boleto nuevo?

Trabajaré en este tema en el futuro. Me gustaría mantener este tema abierto porque el registro de la discusión aquí será valioso para mí.

@masatake todavía puede vincular a este ticket desde uno nuevo y conservar el historial completo. Esto realmente me ayudaría, ya que estoy tratando de limpiar mi pestaña "Problemas" para un nuevo trabajo y no quiero que un desorden como este boleto se interponga en mi camino.

@fommil , no veo cómo se puede anular a @masatake , que es la fuerza impulsora detrás de Universal Ctags, con 2700 confirmaciones frente a su recuento de confirmaciones de cero. Una vez que abre un error (o, en el lenguaje de GitHub, "problema"), este error se convierte en propiedad del proyecto. Creo que puedes dejar de mirarlo y no recibir ningún correo electrónico al respecto.

Reapertura.

@dtikhonov @masatake por favor cierre este ticket. Es el único ticket en mi vista https://github.com/issues que no es relevante para mi trabajo.

No es posible eliminar un ticket de esta vista a menos que el ticket esté cerrado. Incluso si me doy de baja.

De hecho, no sabía que los propietarios de repositorios tendrían este control cuando creé el ticket, de lo contrario no lo habría hecho.

Si desea trabajar en esto, cree un nuevo ticket y haga referencia a este ticket, se conserva toda la discusión. O simplemente copie y pegue el contenido de https://github.com/universal-ctags/ctags/issues/761#issuecomment -373720839 en un ticket nuevo.

No creo que esto sea mucho para pedir.

¿Podrías crear una cuenta temporal de GitHub solo para copiar y pegar?
Para que pueda copiar y pegar usted mismo.
Luego, puede eliminar la cuenta.

seguro, si esa es la única forma de solucionar este problema, puedo hacerlo.

¡hecho! Gracias por dejarme cerrar este ticket. Limpia significativamente mi tarea TODO.