fd 10.0.0 и bfs 3.2

Жаль, я думал, ты адекватнее.

Это очень дешевый приём, которым ты пользуешься, когда нет аргументов.

Извините Вы не правильно реагируете. Может чел. сделал ставку на Rust а вы пытаетесь включить логику. Увы так не прокатит.

Хотя видя как «развивается» RUST тут даже делать ничего не нужно, года 2-3 и о нем будут вспоминать как о рельсах.

$ ls -lh /usr/lib/libsmfm*
lrwxrwxrwx 1 root root   21 ноя 29 23:00 /usr/lib/libsmfm-core.so -> libsmfm-core.so.4.0.0
lrwxrwxrwx 1 root root   21 ноя 29 23:00 /usr/lib/libsmfm-core.so.4 -> libsmfm-core.so.4.0.0
-rwxr-xr-x 1 root root 215K ноя 29 23:00 /usr/lib/libsmfm-core.so.4.0.0
lrwxrwxrwx 1 root root   21 ноя 29 23:03 /usr/lib/libsmfm-gtk2.so -> libsmfm-gtk2.so.4.0.0
lrwxrwxrwx 1 root root   21 ноя 29 23:03 /usr/lib/libsmfm-gtk2.so.4 -> libsmfm-gtk2.so.4.0.0
-rwxr-xr-x 1 root root 432K ноя 29 23:03 /usr/lib/libsmfm-gtk2.so.4.0.0

Вот программа, которая среди прочего тоже умеет ходить по файловой системе и исполнять машину состояний для поиска, но кроме этого она умеет еще кучу всего, начиная от задач cp, df и du и заканчивая построением графического интерфейса для файлвого менеджера, а также оптимизированной многопоточной обработкой загрузки каталогов, иконок, тумбочек и т.п.

Для этого не потребовалось ни 2.8, ни 4 мегабайта кода.

Я бы тоже сделал ставку на Раст, если бы существующие на нём решение стимулировали меня это сделать, а не служили примерами, как делать не надо. =)

И думаю что тут не так, глянул на него, ну точно.

Жирный минус реакций в том, что их причину знает только реагирующий.
Клоунов могли понаставить и за «через чур». :)

а не служили примерами, как делать не надо

Покажи, как надо — напиши аналог fd на сях, который будет быстрее, или хотя бы менее, чем на 5% медленнее.

Что бинарь будет сильно меньше мегабайта, я не сомневаюсь. Мне сам код интересно сравнить для такого случая.

напиши аналог fd на сях, который будет быстрее

Почему претензия только к скорости, а как же функциональность?
Вот у fd нет -rm, как у bfs. А это гораздо быстрее, чем системный rm.

Почему претензия только к скорости, а как же функциональность?

Ну, мне лично -rm не нужно. Я даже не знал, что в fd его нет, а в bfs нет. Я всё же за юниксвей, и за то, чтобы утилита для поиска искала файлы, а не удаляла, изменяла или перемещала их куда-то самостоятельно. Но в любом случае, само наличие такой опции не влияет на скорость, ежели она не используется при конкретном запуске.

А bfs не сопоставим по скорости разве?

или хотя бы менее, чем на 5% медленнее.

5% – это разброс измерений. У меня вчера в тесте bfs оказался быстрее, а у вас медленее. Вот и как оптимизировать его, если у меня ваш кейс не воспроизводится?

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

А bfs не сопоставим по скорости разве?

У меня он в два с половиной раза медленнее там, где это важно, и в полтора на мелочёвке.

Вот и как оптимизировать его, если у меня ваш кейс не воспроизводится?

А вы на чём тестировали? Просто если на /bin, то там будет не время собственно работы, а время старта/инициализации ролять, потому что сам «поиск» выполняется за какие-то милисекунды. Надо на чём-то повнушительнее, чтобы счёт в секундах шёл. Ну хотя бы где-то вокруг одной.

upd: нашёл. Странно тогда. Хотя вообще странно, что поиск по /usr так долго занимает. У меня по /usr — 40-60 милисекунд…

Очень слабый проц? Или корень на медленном HDD?

Я всё же за юниксвей

Даже, если он медленнее?

за то, чтобы утилита для поиска искала файлы, а не удаляла

Что насчёт -delete у find? Скорее всего, у bfs это действие было добавлено для совместимости с find.

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

Я давно использую bfs для удаления больших директорий.

Сразу видно что Debian у человека…

Почти, но в середине «vu». :)

Я всё же за юниксвей

Даже, если он медленнее?

Зависит от задачи. И от того, насколько медленнее. В идеале надо и быстрее и юниксвейнее.

Что насчёт -delete у find?

В POSIX его нет, это в GNU добавили. А GNU знатные антиюниксвейщики.

Скорее всего, у bfs это действие было добавлено для совместимости с find.

Да, почти наверняка.

Я давно использую bfs для удаления больших директорий.

Сильно быстрее получается, чем rm -R? Надо попробовать. Никогда даже не задумывался о таком. Впрочем, не помню, чтобы меня хоть раз напрягало медленное удаление большой директории. Но всё равно интересно. А можно какой-нибудь синтетический пример (прям начиная с создания директории в /tmp и кучи файлов в ней, или могу распаковать что-нибудь скачанное, ядро там или ещё что), чтоб проверить?

Если оно сильно быстрее, возможно имеет смысл написать какой-нибудь fastrm (и сделать на него алиас), который делает конкретно это.

upd: да, удалось воспроизвести. В tmpfs разница небольшая, но на HDD вдвое. Интересно.

Сильно быстрее получается, чем rm -R?

Мне однажды нужно было удалить большой и уже ненужный репозиторий (не помню, какой), так я устал ждать, когда rm закончит работу. bfs закончил быстро.

А можно какой-нибудь синтетический пример
что-нибудь скачанное, ядро там

Наверное, ядро подойдёт. Если использовать hyperfine, то добавить --prepare <распаковать архив>.

возможно имеет смысл написать какой-нибудь fastrm

У меня простой скрипт surm. :)

Кстати, о hyperfine. Есть альтернативы не на Rust? :)

Я сейчас глянул, удаление с fd таки тоже быстрее получается. И быстрее чем rm -R и чем bfs -rm.

hyperfine -p "tar -xJf linux-6.8.9.tar.xz" -w2 -i "fd -u . linux-6.8.9 -x rm -R ; rm -R linux-6.8.9" "bfs -rm linux-6.8.9" --export-markdown finders.md 
Benchmark 1: fd -u . linux-6.8.9 -x rm -R ; rm -R linux-6.8.9
  Time (mean ± σ):     544.1 ms ± 106.8 ms    [User: 3720.0 ms, System: 2880.5 ms]
  Range (min … max):   423.6 ms … 714.5 ms    10 runs
 
Benchmark 2: bfs -rm linux-6.8.9
  Time (mean ± σ):      1.135 s ±  0.045 s    [User: 0.050 s, System: 1.147 s]
  Range (min … max):    1.113 s …  1.261 s    10 runs
 
  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs.
 
Summary
  fd -u . linux-6.8.9 -x rm -R ; rm -R linux-6.8.9 ran
    2.09 ± 0.42 times faster than bfs -rm linux-6.8.9

Сделаю себе минискрипт purge для удаления больших директорий. Спасибо за идею :)

Мне всё равно, на чем написано приложение, пока его размер как-то соотносится с реализуемыми фичами.

Что бы не говорили, но размер имеет значение.

А дальше варианты использования:

• запуск из скриптов на небольших каталогах - на первое место выходит скорость запуска программы, а это размер + динамические библиотеки и скорость их подгрузки
• запуск на монструозных каталогах - параллелизм и возможности оборудования дисковой подсистемы.

Я сейчас глянул, удаление с fd таки тоже быстрее получается.

А точно правильно меряем, или это всё синтетический тест?

hyperfine прогоняет по несколько раз, оно всё оказывается в кешах (ОЗУ, контроллера дисковой системы).

А как параллелизм помогает при доступе к «холодным» каталогам?

А точно правильно меряем, или это всё синтетический тест?

Любой тест в чём-то синтетический, ведь нам надо сравнивать результаты в одинаковых условиях, а не одну сиюминутную хотелку. Но да, вне синтетики, на холодную, по идее будет ещё заметнее.

hyperfine прогоняет по несколько раз, оно всё оказывается в кешах (ОЗУ, контроллера дисковой системы).

Без кэша как раз rm -R ещё медленнее. И даже на /tmp разница невелика. Велика она как раз на HDD, на SSD чуть поменьше.

Чуть попозже попробую.

upd: пыхтит. Займёт некоторое время, так как сама по себе чистка кэшей — дело медленное. Пока всё подтверждается, но случайный разброс в разных запусках сильно выше, чем в изначальной синтетике.

Ну на HDD никакое программное ускорение не поможет, скорее многопоточность наоборот навредит.

Домерял. Вот так вот получается:

$ cat `which purge`
#!/bin/sh
fd -u . "$1" -x rm -R
rm -R "$1"

$ hyperfine -p "tar -xJf linux-6.8.9.tar.xz && sudo sync && echo 3 | sudo sponge /proc/sys/vm/drop_caches" -w 2 -i "purge linux-6.8.9" "bfs -rm linux-6.8.9" "rm -R linux-6.8.9" --export-markdown finders.md

Benchmark 1: purge linux-6.8.9
  Time (mean ± σ):      2.093 s ±  1.232 s    [User: 7.262 s, System: 4.056 s]
  Range (min … max):    0.537 s …  3.570 s    10 runs
 
Benchmark 2: bfs -rm linux-6.8.9
  Time (mean ± σ):      4.000 s ±  2.634 s    [User: 0.042 s, System: 1.496 s]
  Range (min … max):    1.290 s …  8.213 s    10 runs
 
Benchmark 3: rm -R linux-6.8.9
  Time (mean ± σ):      5.176 s ±  4.154 s    [User: 0.034 s, System: 1.361 s]
  Range (min … max):    1.867 s … 16.378 s    10 runs
 
Summary
  purge linux-6.8.9 ran
    1.91 ± 1.69 times faster than bfs -rm linux-6.8.9
    2.47 ± 2.46 times faster than rm -R linux-6.8.9

Разброс, конечно, зело большой. Но всё же разница вполне заметная. Разбросы перекрываются, но самый долгий медленный через fd всё ещё быстрее среднего значения через bfs и rm.

P.S. Это со сбросом кэшей сразу перед каждым тестом, если не очевидно из того, что происходит в -p

fd -u . "$1" -x rm -R
rm -R "$1"

А зачем второй rm в purge?

Простой проход через fd оставляет пустые каталоги из-под удалённого в них содержимого. Может можно как-то это обойти опциями самого fd. Но я не стал пока заморачиваться.

А вот пока тред совсем не исчез может мне кто нибудь из сообщества rust объяснит такую картину:

(rpm базед дистр)

Возьмем к примеру

1. python, куча пакетов python-xxx это понятно.
2. ruby - куча пакетов rubygem-xxx это тоже понятно.
3. go - куча пакетов golang-xxx и это понятно.
4. а где куча либ под rust ? не понимаю. Это как так ?

а где куча либ под rust ?

Какой дистрибутив? В Debian их куча.

https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/r/

А понятно, просто сам rust есть, а ни одной с ним проги нет.

ок.

Да, здесь не в многопоточности дело, а в том, как дерево обходится.

Тут ещё такое дело, что пакеты python-xxx и rubygem-xxx нужны для запуска софта, написанного с использованием этих модулей/либ. В rust они нужны только для компилляции, для запуска не требуются, потому и пакеты с ними конечному юзеру не нужны. Как в go — не знаю.

Сразу видно что Debian у человека…

А что это означает? Почему это число связано с дистрибутивом?

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

там макрос build …

На Go то же самое. Всё Go-шное вкомпилируется внутрь. Остаётся только:

$ ldd /usr/bin/syncthing
	linux-vdso.so.1 (0x00007ffc34569000)
	libc.so.6 => /usr/lib/libc.so.6 (0x000079e399dcc000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x000079e39b7b2000)

Кстати сказать, бинарь весит 23 МБ.

ну как не статическая, для glibc не статическая, а для rust-std статическая

А что собственно мешает написать такое?

Решил всё же перепроверить своё изначальное согласие и… Оказалось, что каким-то неведомым образом многопоточность всё же помогает. Даже на HDD и с очищенным кэшем. Смотри, какие дела:

hyperfine -p "tar -xJf linux-6.8.9.tar.xz && sudo sync && echo 3 | sudo sponge /proc/sys/vm/drop_caches" -r 3 -i "fd --threads=1 -u . linux-6.8.9 ; rm -R linux-6.8.9" "fd --threads=2 -u . linux-6.8.9 ; rm -R linux-6.8.9" "fd --threads=4 -u . linux-6.8.9 ; rm -R linux-6.8.9" "fd --threads=32 -u . linux-6.8.9 ; rm -R linux-6.8.9" --export-markdown finders.md 

Benchmark 1: fd --threads=1 -u . linux-6.8.9 ; rm -R linux-6.8.9
  Time (mean ± σ):      1.421 s ±  0.007 s    [User: 0.125 s, System: 1.317 s]
  Range (min … max):    1.413 s …  1.426 s    3 runs
 
  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.
 
Benchmark 2: fd --threads=2 -u . linux-6.8.9 ; rm -R linux-6.8.9
  Time (mean ± σ):      1.358 s ±  0.012 s    [User: 0.086 s, System: 1.322 s]
  Range (min … max):    1.350 s …  1.372 s    3 runs
 
Benchmark 3: fd --threads=4 -u . linux-6.8.9 ; rm -R linux-6.8.9
  Time (mean ± σ):      1.335 s ±  0.001 s    [User: 0.081 s, System: 1.302 s]
  Range (min … max):    1.334 s …  1.337 s    3 runs
 
Benchmark 4: fd --threads=32 -u . linux-6.8.9 ; rm -R linux-6.8.9
  Time (mean ± σ):      1.332 s ±  0.001 s    [User: 0.092 s, System: 1.352 s]
  Range (min … max):    1.331 s …  1.333 s    3 runs
 
Summary
  fd --threads=32 -u . linux-6.8.9 ; rm -R linux-6.8.9 ran
    1.00 ± 0.00 times faster than fd --threads=4 -u . linux-6.8.9 ; rm -R linux-6.8.9
    1.02 ± 0.01 times faster than fd --threads=2 -u . linux-6.8.9 ; rm -R linux-6.8.9
    1.07 ± 0.01 times faster than fd --threads=1 -u . linux-6.8.9 ; rm -R linux-6.8.9

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

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

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

А что это означает?

Это означает, что я померил средний размер бинарника у себя. И он оказался - 226132. Что как бы намекает на то, что у меня примерно то же самое, что и у него. А конкретно у меня - Debian 12.2.

fd --threads

У bfs тоже есть -jN.

Там вроде же не размер бинарника, а число файлов в каталоге.

а тесты со сложными условиями и регэкспами были уже?

Насколько я слежу, то нет. :)

echo 404777336 / 1790 | bc

т.е., всё-таки размер.

Вроде не было. Но не думаю, что это как-то повлияет на разницу между fd, bfs и find. Всё же там больше в I/O всё упирается, сам парсинг регэкспа по времени будет где-то на уровне погрешности. Но если предложишь, каким регэкспом потетить (можно опять на том же ядре, раз уж с ним экспериментируем, чтоб не качать кучу всего), могу потестить.

Почти, но в середине «vu». :)

Как и ожидалось, влияние systemd оказалось в пределах статпогрешности )))

Да, я заметил. Думаю, там точно так же будет, многопоточное чуть побыстрее, чем однопоточное. Лень проверять. По умолчанию там 8 тредов, но оно всё равно ощутимо медленнее, чем fd даже с одним.

По умолчанию там 8 тредов

Точнее – зависит от CPU.

Да, но не больше восьми.

Судя по тому, что мне показывает htop, fd создаёт столько потоков, сколько ядер доступно, + 1 общий поток, который не выполняет обращения в ФС.

Ничосе телепатия. Я тот коммент написал, не читая то, что тут это же обсуждается.

bfs создал 13 потоков – ??

но при этом в состоянии D находятся только 3 из них – ????

Не, сначала размер суммируется у исполняемых:

find /usr/bin -type f | xargs file -i | grep ‘/x-.*-executable’ | grep -E -o ‘^/[^:]+’ | xargs stat -c «%s» | awk ‘{s+=$1} END {print s}’

Собрал bfs без liburing:

Summary
  bfs /lib/ ran
    1.30 ± 0.06 times faster than fd . /lib/
    2.25 ± 0.09 times faster than bfs_no_uring /lib/