fd 10.0.0 и bfs 3.2

HDD

Эмммм….

vadim@aquila:~$ sudo sh -c 'echo 3 >/proc/sys/vm/drop_caches'
vadim@aquila:~$ time fd -u . /media/stuff2/os-archives/ | cat > /dev/null

real    3m16,882s
user    0m5,612s
sys     0m17,227s
vadim@aquila:~$ sudo sh -c 'echo 3 >/proc/sys/vm/drop_caches'
vadim@aquila:~$ time bfs /media/stuff2/os-archives/ | cat > /dev/null

real    5m54,706s
user    0m1,497s
sys     0m12,788s
vadim@aquila:~$ sudo sh -c 'echo 3 >/proc/sys/vm/drop_caches'
vadim@aquila:~$ time find /media/stuff2/os-archives/ | cat > /dev/null

real    2m47,270s
user    0m2,479s
sys     0m12,218s
vadim@aquila:~$ sudo sh -c 'echo 3 >/proc/sys/vm/drop_caches'
vadim@aquila:~$ time find /media/stuff2/os-archives/ | cat > /dev/null
real	2m48,379s
user	0m2,486s
sys	0m12,745s
vadim@aquila:~$ 

А вот разница на прогретом кэше:

vadim@aquila:~$ time fd -u . /media/stuff2/os-archives/ | cat > /dev/null

real	0m0,564s
user	0m0,691s
sys	0m1,128s
vadim@aquila:~$ time bfs /media/stuff2/os-archives/ | cat > /dev/null

real	0m0,429s
user	0m0,311s
sys	0m0,891s
vadim@aquila:~$ time find /media/stuff2/os-archives/ | cat > /dev/null

real	0m1,243s
user	0m0,405s
sys	0m0,884s
vadim@aquila:~$ 

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

У меня 226146 файлов в ‘/lib’.

Но!
$ fd . /lib/ | wc -l

225641

Лолшто, оно какие-то файлы так и не нашло?

Оно по молчанию скрытые файлы/каталоги не отображает. Дальше по треду разобрались, что нужна опция -u

Оно по умолчанию игнорирует некоторые файлы, чтобы это отменить, есть ключ -u. Читай дальше, там разобрались, и тестируют уже с -u.

У меня 226146 файлов в ‘/lib’.

Черт, это я адски затупил. Действительно, просто совпадение :D

В общем, как я и говорил, высокий уровень concurrency для HDD нафиг не нужен и ухудшает результат на минуты.

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

Сейчас на SATA SSD еще проверю со сброшенным кэшем.

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

$ fd -u ".*clang.*" . /lib/ | wc -l

1829

$ bfs -regex ".*clang.*" /lib/ | wc -l

9307

Что не так у растовских регэкспов или у fd?

Сам вывод посмотри. bfs ищет во всём пути, а fd — в имени файла.

Ну то есть, например, bfs выводит в том числе и /lib/clang/17/include/openmp_wrappers/math.h, например

man bfs

       -regex REGEX
              Find files whose entire path matches the regular expression REGEX.

Похоже, bfs не умеет искать именно имя файла по регэкспу, только по GLOB. Ну можно и GLOB сравнить, в принципе.

А чтоб по всему пути искать, у fd ключ -p. Но это довольно странный юзкейс, честно говоря. Обычно надо всё же именно по имени файла.

Сейчас на SATA SSD еще проверю со сброшенным кэшем.

SATA SSD:

vadim@aquila:~$ find /media/stuff/vadim/ | wc -l
4073638
vadim@aquila:~$ du -hs /media/stuff/vadim/
472G	/media/stuff/vadim/
vadim@aquila:~$ sudo sh -c 'echo 3 >/proc/sys/vm/drop_caches'
vadim@aquila:~$ time fd -u . /media/stuff/vadim/ | cat > /dev/null

real	2m4,084s
user	0m22,079s
sys	1m7,188s
vadim@aquila:~$ sudo sh -c 'echo 3 >/proc/sys/vm/drop_caches'
vadim@aquila:~$ time bfs /media/stuff/vadim/ | cat > /dev/null

real	2m43,246s
user	0m10,557s
sys	1m7,726s
vadim@aquila:~$ sudo sh -c 'echo 3 >/proc/sys/vm/drop_caches'
vadim@aquila:~$ time find  /media/stuff/vadim/ | cat > /dev/null

real	4m24,600s
user	0m16,980s
sys	1m14,148s
vadim@aquila:~$ 

А чтоб по всему пути искать, у fd ключ -p.

$ fd -u --full-path ".*clang.*" . /lib/ | wc -l

9326

$ fd -u --full-path --glob "*clang*" . /lib/ | wc -l

0

$ bfs -regex ".*clang.*" /lib/ | wc -l

9307

$ bfs -iregex ".*clang.*" /lib/ | wc -l

9325

bfs повторяет логику ключа -regex у find, поскольку совместимость с find – одна из заявленных целей проекта.

Искать по полному пути иногда нужно.

У тебя точка лишняя.

$ fd -p -u ".*clang.*" /lib/ | wc -l
514
$ bfs -regex ".*clang.*" /lib/ | wc -l
510
$ bfs -iregex ".*clang.*" /lib/ | wc -l
514

У тебя точка лишняя.

Разве?

Arguments:
  [pattern]
          the search pattern which is either a regular expression (default)

У тебя между паттерном ".*clang.*" и путём, где искать /lib/ ещё один аргумент — точка.

Хотя вообще, она просто как ещё один путь воспринимается, и должно больше найтись. Очень странно, что 0 выдаёт, у меня работает как надо.

А! Стал добавлять после этого:

If you want to search for all files inside the '/lib/' directory, use a match-all pattern:

  fd . '/lib/'
Instead, if you want your pattern to match the full file path, use:

  fd --full-path '/lib/'

О каком стабильном ABI идёт речь

О стабильном ABI библиотек на Rust (которые вынуждены быть статическими, а не динамическими, из-за отсутствия такового).

когда программа и так линкуется с glibc?

Где связь?

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

Как-то так получается.

Какой собеседник — такой и приём.

когда нет аргументов

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

грамотная статическая линковка

Что такое «грамотная статическая линковка» и чем она отличается от того, что делает Rust?

Ты всё ближе к пути EXL, который врывается в рандомные треды с криками «Иксы говно!» и так же стремительно убегает. А ведь грамотный специалист. Был.

Осторожнее, intelfx.

Что такое «грамотная статическая линковка» и чем она отличается от того, что делает Rust?

Это когда у тебя линковка ограниченного подмножества функций на от силы сотню килобайт не приводит к линковке 4 мегабайт бесполезного мусора в бинарник.

А ведь грамотный специалист. Был.

Осторожнее

Кто бы что говорил по поводу дешёвых приёмов :-) ЧТД.

Какой собеседник — такой и приём.

У тебя даже своих атак на личность нет, мои передираешь :-)

Уже третий тред подряд сливаешься.

У тебя даже своих атак на личность нет

Спасибо. Мне приятно, что ты заметил.

Было бы еще приятнее, если бы ты брал с меня пример.

Уже третий тред подряд сливаешься.

Уважаемый intelfx. «Сливаешься» – это когда вместо аргументов чел ставит фейспальмы. Возможно, ты научишься не путать это.

Было бы еще приятнее, если бы ты брал с меня пример.

В чём? В том, чтобы игнорировать любые попытки обсуждения по существу и технические аргументы и мгновенно скатываться в тупое улюлюканье насчёт технологий, к которым питаешь неприязнь?

Спасибо, я, пожалуй, не буду. Это дорога в никуда.

игнорировать любые попытки обсуждения по существу и технические аргументы и мгновенно скатываться в тупое улюлюканье

Уже третий тред подряд я пытаюсь вытащить из тебя какое-нибудь обсуждение по существу, но слышу только какое-то невнятное улюлюкание.

Спасибо, я, пожалуй, не буду.

Как обычно. Пакеда.

Все аргументы были приведены выше — не моя вина, что ты решил их проигнорировать.

«Никогда не спорьте с дураками — они стащат вас на свой уровень и задавят опытом» (c) Так что я, пожалуй, не буду.

Все аргументы были приведены выше — не моя вина, что ты решил их проигнорировать.

Да, совершенно верно:

«Динамически линковаться не умеет, а грамотная статическая линковка – это уже тайное, забытое и утерянное в веках знание.»

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

Для сравнения размеры некоторых ключевых для современного десктопного софта библиотек:

vadim@aquila:~$ ls -lhH /usr/lib/libglib-2.0.so
-rwxr-xr-x 1 root root 1,3M мая  2 08:59 /usr/lib/libglib-2.0.so
vadim@aquila:~$ ls -lhH /usr/lib/libgobject-2.0.so
-rwxr-xr-x 1 root root 383K мая  2 08:59 /usr/lib/libgobject-2.0.so
vadim@aquila:~$ ls -lhH /usr/lib/libgio-2.0.so
-rwxr-xr-x 1 root root 1,8M мая  2 08:59 /usr/lib/libgio-2.0.so

Кто-нибудь возьмётся аргументированно доказывать, что fd содержит больше программной логики, чем вся glib-2?

Я последние лет 10 стал замечать такую особенность: при почти каждом обновлении Арча перестаёт работать одна и более программ, причём, важных для моей работы: Блендер, Хром-браузер, и почти всё что связано с Qt. Проблема эта частично решается различными способами изоляции программ (nixpkgs). Но в сухом остатке я прихожу к заключению, что динамические библиотеки постепенно теряют свою актуальность. Ведь единственное их преимущество - это возможность экономить память. А необходимость изолировать программы как раз это приемущество сводят на нет. Вот и получается что когда нужна стабильность - то либо нужны точные версии библиотек, либо статическая линковка. Раст умеет и в статику и в динамику, но на практике статика упрощает жизнь, особенно, когда используются нестабильные библиотеки - явление обыденное, когда быстро развивающиеся проекты, особенно на ранних этапах разработки не хотят обременять себя обратной совместимостью. Там вообще только строго определённые комбинации версий библиотек между собой работают.

Но в сухом остатке я прихожу к заключению, что динамические библиотеки постепенно теряют свою актуальность. Ведь единственное их преимущество - это возможность экономить память

единственное их преимущество

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

Некоторые HDD умеют принимать несколько команд на выполнение, и контроллер может их переупорядочивать для более быстрого исполнения. Многопоточные программы более активно используют буфер команд.

Это актуально лишь на системах с острым дефицитом ОЗУ. С тех пор как перестал работать закон Мура, именно производительность стала бутылочным горлышком, а не ОЗУ.

В рамках существующей модели десктопного софта не получится всё засунуть в статику.

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

Есть два кейса, когда это прямо сейчас реально возможно для приложений:

• Приложения, имеющие интерфейс командной строки, либо TUI.
• Приложения, имеющие веб-интерфейс на localhost:port.

Не даром, именно такие приложения активно пишут на статически линкуемых Rust и Go.

Да никто такого даже утверждать не собирался, не то что доказывать. Просто кому-то пофиг на размер исполняемого файла, кому-то нет. Кому-то с оговорками, как мне например — не нравится, что 4 МБ весит искалка файлов, но я готов платить эту цену за преимущества, даваемые ею.

Приложения, имеющие интерфейс командной строки, либо TUI.

Эмуляторы терминала, а также мультиплексоры типа tmux, zellij и twin — это правильный путь развития архитектуры.

Особенно успех tmux и нарождающийся будущий успех zellij это демонстрируют.

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

Очевидно, что архитектура должна быть не

клиент <-> сервер

, а

клиент <-> сервер <-> дисплей

как у tmux.

А вот вейланд и предлагаемые к нему «решения на уровне тулкитов» – это два шага назад. И никакого эволюционного будущего у него нет.

Да никто такого даже утверждать не собирался, не то что доказывать.

Мой вчерашний собеседник как раз делал вид, что что-то «доказывает». Правда не смог сформулировать, что конкретно.

Когда речь идёт о графических приложениях, там всё сильно завязано на аппаратные возможности. Всякие видео-потоки (вплоть до потока DRM, который должен идти от приложения до монитора) с довольно большим битрейтом и критичные к джиттеру. Всякие потоки команд к видеокарте, где критично отрабатывать уже даже не за 16.6 мс, а за 7 мс.

Поэтому тут особо с абстракциями не разгуляешься. А то сожрут геймеры со смотрителями ютуба.

Это должно быть «ресурсами», которые сервер умеет отдавать клиенту. А не краеугольным камнем протокола, как в вейланд.

Типа:

«Сервер, мне нужна поверхность для того, чтобы рисовать на неё прямо средствами видеокарты. Есть у тебя такое?»

«Есть, вот держи дескриптор для доступа.»

Пора самому uring io поковырять…

А и не надо ВСЁ линковать статически.