Ctags: параллельные теги

Привет,

Хотя встроенная параллельная реализация может быть интересной, уже можно распараллелить обновление большой кодовой базы, запустив разные теги ctags в другом каталоге и затем объединяя сгенерированные файлы (что можно сделать, просто отбросив строки, начинающиеся с!, из всех файлов, кроме одного и затем с помощью sort --merge для всех файлов).

Однако я не уверен, что вы получите какое-либо ускорение за счет распараллеливания ctags, поскольку я ожидаю, что современные машины будут привязаны к вводу-выводу. Однако, чтобы убедиться, это необходимо профилировать.

@mawww Я уверен, что https://github.com/ggreer/the_silver_searcher не согласится: wink:

Выполнение нескольких ctags было бы чрезвычайно сложно координировать из стандартных emacs https://github.com/bbatsov/projectile/blob/master/projectile.el#L180 -L183

@mawww Я уверен, что https://github.com/ggreer/the_silver_searcher не согласится: wink:

Хорошая точка зрения.

Выполнение нескольких ctags было бы чрезвычайно сложно координировать из стандартных emacs https://github.com/bbatsov/projectile/blob/master/projectile.el#L180 -L183

Оболочка сценария оболочки уже может иметь большое значение, но, возможно, было бы более эффективно интегрировать ее непосредственно в ctags.

@fommil В этому поводу не очень ясно, откуда он начался и куда пошел (ну, вы можете прочитать это между строк, но хорошо), и в любом случае это действительно не так уж и много. И я не собираюсь игнорировать какую-либо его работу, но я не собираюсь полностью доверять результатам кого-то, кто, казалось бы, только что узнал о многопоточности (особенно из-за того, например, насколько неправильное использование мьютекса разрушает любую производительность, которую может дать MT). . Не говорю, что он не совсем прав, но меня нужно убедить :)
И обратите внимание, как его собственные тесты показали, что на его машинах слишком много рабочих потоков быстро становилось хуже, чем полное отсутствие распараллеливания. Это мило, но, вероятно, будет сильно зависеть от оборудования, ОС и данных, которые нужно обрабатывать, так что это, вероятно, должно быть более разумным, чем «ну, использование N потоков показало себя лучше в моих тестах».

Кроме того, еще одна причина, по которой меня это не так привлекает, заключается в том, что я не только не верю, что это даст нам так много, но и то, что это будет большой объем работы, подверженной ошибкам. В настоящее время кодовая база CTags абсолютно не в состоянии поддерживать потоки синтаксического анализа параллельных тегов. Все, что вы _ можете_ относительно легко разделить, - это переход по каталогу init / и _ один поток парсера.
И, наконец, я уверен, что у нас есть более разумные оптимизации для выполнения повсюду в кодовой базе (и особенно в парсерах).

Итак, конечно, многопоточность, вероятно, может иметь некоторые преимущества при правильном использовании, но, вероятно, это не будет самым интересным улучшением.

Кроме того, еще одна причина, по которой меня это не особо привлекает, заключается в том, что […] это будет большой объем работы, подверженной ошибкам. В настоящее время кодовая база CTags абсолютно не в состоянии поддерживать потоки синтаксического анализа параллельных тегов. Все, что вы _ можете_ относительно легко разделить, - это переход по каталогу init / и _ один поток парсера.

Кстати, я не имею в виду, что улучшение этой области кода - плохая идея, я думаю, что это так (особенно для возможных будущих libctags). Я просто имею в виду, что если целью является производительность, то, вероятно, (в настоящее время) это не стоит усилий, и что есть более важная область, на которой нужно сосредоточиться.

Кстати, запуск профилировщика и профилирование огромного количества данных множеством способов, вероятно, было бы интересно.

GNU parallel может вам помочь.

Как упоминалось ранее , оптимизация чтения может немного ускорить ctags.

Параллельное выполнение синтаксических анализаторов может немного ускорить работу, если ввод-вывод поступает из кеша (и это часто имеет место в N-й раз, когда вы запускаете ctags в каталоге из редактора).

@pragmaware IMO, библиотека не должна разветвляться.

Если вы читаете текст на японском языке, посмотрите статью https://qiita.com/dalance/items/c76141a097e25fabefe8 .
(Написав этот комментарий, я нашел репозиторий git для ptags (https://github.com/dalance/ptags). Страница написана на английском языке.)

Он сообщает об инструменте под названием ptags, разработанном автором. Инструмент написан на Rust и содержит ctags.
Он запускает ctags параллельно для набора входных данных.
Я не граблю его внутреннее. Однако очевидно, что он запускает несколько процессов ctags.

Результат весьма впечатляющий. В 5 раз быстрее, чем разовая обработка. Количество процессоров не пишется. Объема памяти может хватить (= 128ГБ). Автор запускает 10 раз ptags для одного и того же набора входных данных, чтобы сделать кеш страницы горячим.

Хотя все это следует делать в оболочках, таких как ptags, этот замечательный результат трудно игнорировать.
Взломал быстро. https://github.com/masatake/ctags/tree/parallel
Недавно введенная опция --_ parallel запускает несколько процессов ctags в _parallel.

Количество рабочих процессов, 8, жестко запрограммировано. У моего портативного ПК 8 ядер.
ПАМЯТЬ составляет 32 ГБ. Целевой ввод - это последнее дерево исходных текстов ядра Linux.
Мои .ctags достаточно волосатые.

Результат почти такой же: в 2 ~ 3 раза быстрее.

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

(Я сравнил оба файла тегов. Разницы нет.)

Далеко не удовлетворительно, но это хорошее место для начала.

Интересно, нужно ли собирать продукцию рабочих?

привет @masatake. Я пытаюсь закрыть все открытые

Я буду работать над этим в будущем. Я хотел бы оставить этот пункт открытым, потому что запись обсуждения здесь будет для меня ценна.

@masatake, вы все равно можете

@fommil , я не понимаю, как вы можете переопределить @masatake , который является движущей силой универсальных Ctags, с 2700 коммитами по сравнению с вашим нулевым счетчиком коммитов. Как только вы открываете ошибку (или, на языке GitHub, «проблему»), эта ошибка становится собственностью проекта. Я считаю, что вы можете не смотреть его и не получать никаких писем об этом.

Повторное открытие.

@dtikhonov @masatake, пожалуйста, закройте этот билет. Это единственный билет в моем представлении https://github.com/issues, который не имеет отношения к моей работе.

Невозможно удалить билет из этого представления, если он не закрыт. Даже если отпишусь.

На самом деле, я не знал, что владельцы репо будут иметь этот контроль, когда я создавал тикет, иначе я бы этого не сделал.

если вы хотите поработать над этим, создайте новый тикет и укажите ссылку на него, все обсуждения сохранятся. Или просто скопируйте и вставьте содержимое https://github.com/universal-ctags/ctags/issues/761#issuecomment -373720839 в новый тикет.

Я не думаю, что мне нужно много спрашивать.

Не могли бы вы создать временную учетную запись GitHub только для копирования и вставки?
Так что вы можете делать копипаст самостоятельно.
Затем вы можете удалить учетную запись.

конечно, если это единственный способ исправить это, я могу это сделать.

Выполнено! Спасибо, что разрешили мне закрыть этот билет. Это значительно упрощает мою задачу TODO.