Помогите выбрать дистрибутив для максимального перформанса

Пакетов не так много, годами не придеться. Вот у тебя сколько пакетов бинарных, которые имеет смысл оптимизировать? Явно меньше сотни.

В понятие «максимально эффективно» входит первоначальная установка, настройка, обслуживание, обновление и исправление багов?

Пакетов не так много, годами не придеться.

как я понял, ТС хочет оптимизировать всё. пакетов ну несколько сотен. в gcc, наверное, несколько десятков небезопасных опций оптимизации. какие-то пакеты не соберутся со всеми. вычислять максимальную комбинацию опций, с которыми соберётся каждый не собравшийся со всеми пакет. потом ещё тестировать стабильность работы каждого бинарника. какие-то ошибки могут выявиться не сразу. и всё это может меняться от версии к версии. плюс нужно тестировать каждую опцию по-отдельности на производительность, т.к. какие-то опции могут наоборот снизить производительность для конкретного бинарника.
у меня вообще gcc с -pipe отказывается собираться, хотя это просто убыстрение процесса сборки.

Вот у тебя сколько пакетов бинарных, которые имеет смысл оптимизировать? Явно меньше сотни.

у меня нет бинарных пакетов.

Вот у тебя сколько пакетов бинарных, которые имеет смысл оптимизировать? Явно меньше сотни.

у меня нет бинарных пакетов.

Есть, я про разделение пакетов на чисто шрифты, и те что содержат исполняемый код.

какие-то пакеты не соберутся со всеми.
у меня вообще gcc с -pipe отказывается собираться, хотя это просто убыстрение процесса сборки.

Что за пакет?

какие-то ошибки могут выявиться не сразу

Ну и пусть, при обнаружении можно пересобрать.

и всё это может меняться от версии к версии

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

плюс нужно тестировать каждую опцию по-отдельности на производительность

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

в gcc, наверное, несколько десятков небезопасных опций оптимизации

Можно ограничиться -O*, march, lto.

Есть, я про разделение пакетов на чисто шрифты, и те что содержат исполняемый код.

ну сейчас в моей системе 321 пакет, из них 1 пакет шрифтов. пока что голые иксы, st+screen, mpv, lynx, mc, разные нужные утилиты. даже WM пока не установил. планирую установить FVWM. всё собрано с оптимизациями -O2 -march=native, опции -f*, опции препроцессору, ассемблеру, линковщику. но опции не только на производительность, но и на безопасность есть.

Что за пакет?

gcc

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

а вдруг есть какая-то опция, которая среди прочих немного замедляет? ТС хочет выжать максимум.

Можно ограничиться -O*, march, lto.

можно. но ТС то хотел агрессивные опции.

lto

а как его правильно готовить? чтоб всё с lto собиралось? я пробовал включать -flto, но оно вроде бы выдавало какие-то ворнинги, что мол нужно ещё активировать какие-то опции, то ли какой-то профайлер, уже не помню, и я в итоге забил. как его включить?

Я ищу дистрибутив Linux, который позволит мне максимально эффективно использовать возможности моего железа.

Я советую ставить «Генту» из-за того, что ты сам сможешь запускать только те службы, которые необходимы лишь тебе, а не те, которые пришли в голову сборщику «Линукса». Список процессов «Генты» всегда короче, чем у всех остальных «Линуксов».

Кроме лучшей отзывчивости работы это даст большую устойчивость работы «Линукса» в целом ибо чем меньше служб в работе, тем меньше вероятность программного сбоя.

Есть, я про разделение пакетов на чисто шрифты, и те что содержат исполняемый код.

ну сейчас в моей системе 321 пакет, из них 1 пакет шрифтов

Локали? Фирмвари? Иконки?

Что за пакет?

gcc

Там все же особый случай, он в тестировании компилятора падает, это не должно происходить с обычными пакетами. Чем pipe выгоднее компиляции в tmpfs?

а вдруг есть какая-то опция, которая среди прочих немного замедляет? ТС хочет выжать максимум.

Уверен подразумевается что он хочет это сделать за разумную цену.

Можно ограничиться -O*, march, lto.

можно. но ТС то хотел агрессивные опции.

А что тогда агрессивные оптимизации?

а как его правильно готовить? чтоб всё с lto собиралось?

Нужно прописать "-flto -ffat-lto-objects" в CFLAGS и LDFLAGS. Флаги оптимизации тоже нужно прокинуть в LDFLAGS.

Зачем его продавать? Поколение уже не сломанное, патч вышел в августе, работает идеально.

Локали? Фирмвари? Иконки?

иконок нет пока. из фирмварей тока linux-firmware. а что за пакеты с локалями? у себя не нашёл таких.

Чем pipe выгоднее компиляции в tmpfs?

не знаю. я всё с -pipe собираю (кроме gcc) и в tmpfs (кроме clang и вроде бы llvm — не помещается).

А что тогда агрессивные оптимизации?

ну всякие -funsafe-math-optimizations и которые небезопасны, как я понял.

и LDFLAGS. Флаги оптимизации тоже нужно прокинуть в LDFLAGS

с этого места по-подробнее. все -f* продублировать в LDFLAGS?

Это уже максимальный пердолинг.

ну всякие -funsafe-math-optimizations и которые небезопасны, как я понял.

Оно входит в -Ofast

с этого места по-подробнее. все -f* продублировать в LDFLAGS?

В стадии LD тоже оптимизации идут, поэтому да.

-Ofast

ChatGPT4 сказал, что оно не безопасное. и он мне назвал минимум полтора десятка небезопасных -f опций.

Небезопасное, все верно, ведь туда включен как минимум вышеприведенный unsafe math. Вместо ChatGPT советую прочесть это https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

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

вопрос про -fPIE, -pie и -fPIC.
вроде как нельзя задать все 3, т.к. gcc не поймёт, какие использовать для библиотек, а какие для исполняемых файлов.
спросил у ChatGPT, он ответил задать CFLAGS_LIB LDFLAGS_LIB и CFLAGS_EXEC LDFLAGS_EXEC. но он это говорил про кастомный Makefile. стал искать наличие этих переменных в документации gcc и не нашёл. но я даже не нашёл в документации gcc упоминание CFLAGS.
CFLAGS это переменная чисто Makefile'ов? но её принимают все системы сборки, правильно?
CFLAGS_LIB LDFLAGS_LIB и CFLAGS_EXEC LDFLAGS_EXEC понимают системы сборки?

хотелось бы задать -fPIE -pie для всех исполняемых файлов и -fPIC для всех библиотек...

Всегда думал что достаточно только -fPIC. Посмотрел как сделано в других дистрибутивах, и вот что придумал:

Файл /usr/local/bin/gcc-pie

#!/bin/bash
hardened_flags="           \
  -D_FORTIFY_SOURCE=2      \
  -D_GLIBCXX_ASSERTIONS    \
  -fstack-protector-strong \
  -fstack-clash-protection \
  -fcf-protection=full"

if [[ " $* " =~ [[:space:]]-shared[[:space:]] ]]; then
  gcc $hardened_flags -no-pie $*
else
  gcc $hardened_flags -fPIC -pie -Wl,-z,relro,-z,now $*
fi

$ CC=gcc-pie ./curl.SlackBuild
...

$ if $(file /usr/bin/curl | grep pie -q); then echo pie; fi
pie

Бери Linux From Scratch и сделай его полностью под себя.

неплохая идея.

только непонятно, когда в аргументах gcc есть -shared, у тебя вызывается с -no-pie, когда без -shared — с -fPIC -pie.
но чатгпт мне сказал, что бинарники нужно с -fPIE -pie, а библиотеки — с -fPIC.

у тебя -Wl,-z,relro,-z,now только для бинарников. для библиотек оно не нужно?

Бери Linux From Scratch и сделай его полностью под себя.

но зачем? все уже собрано до нас, смотри CRUX

только непонятно, когда в аргументах gcc есть -shared, у тебя ...

Тут небольшая сложность в том, что CFLAGS и LDFLAGS принимает одна программа, поэтому приходится совмещать их, но это никакого лишнего эффекта не должно давать, в момент создания объектных файлов -pie работать не будет, поэтому библиотеки будут создаваться.

но чатгпт мне сказал, что бинарники нужно с -fPIE -pie, а библиотеки — с -fPIC.

Тут так же смешанно все, -fPIE работает при создании объектных файлов, а -pie на финальной стадии. -fPIE действительно нет, его заменяет -fPIC, он подходит для создания объектных файлов как для будущих динамических библиотек, так и для объектный файлов будущих исполняемых файлов. А в момент линковки он просто игнорируется.

у тебя -Wl,-z,relro,-z,now только для бинарников. для библиотек оно не нужно?

Очень сложно везде написано, а подробно я не читал, но вроде нет.

-fPIE работает при создании объектных файлов, а -pie на финальной стадии. -fPIE действительно нет, его заменяет -fPIC, он подходит для создания объектных файлов как для будущих динамических библиотек, так и для объектный файлов будущих исполняемых файлов. А в момент линковки он просто игнорируется.

да, слегка запутано. но почему у тебя библиотеки с -no-pie и нет -fPIC? потому что с -shared вызывается только на стадии линковки?

Очень сложно везде написано, а подробно я не читал, но вроде нет.

у меня прописано -Wl,-znoexecstack,-znow,-zseparate-code,-zstart-stop-visibility=hidden,-zrelro. с этим всё кроме libclc и spirv-llvm-translator собирается.

да, слегка запутано. но почему у тебя библиотеки с -no-pie и нет -fPIC? потому что с -shared вызывается только на стадии линковки?

Да. Можно добавить -fPIC, он он влияет только на комплияцию объектных файлов, поэтому ничего не произойдет. -no-pie потому что библиотеки нельзя собирать с -pie, если он включен по умолчанию, то этот флаг его точно отключит.

у меня прописано -Wl,-znoexecstack,-znow,-zseparate-code,-zstart-stop-visibility=hidden,-zrelro. с этим всё кроме libclc и spirv-llvm-translator собирается.

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

В стадии LD тоже оптимизации идут, поэтому да.

достаточно просто перечислить в LDFLAGS через пробел, или нужно ещё в CFLAGS через -Wl,... ? или лучше и там и там? я просто у себя опции линковщику продублировал и через LDFLAGS и через -Wl, т.к. подозреваю, что LDFLAGS не всегда задействуется.

Еще не встречал пакетов где LDFLAGS игнорируется. В любой сборке можешь включить подробный вывод комманд, там увидеть передались ли флаги на финальном этапе или нет. Передавать достаточно через LDFLAGS, а -Wl лишний, потому что работу по оптимизациям выполняет компилятор а не линковщик, то есть сначала gcc обработает объектные файлы, а потом передаст ее линковщику, линковщик может быть вообще любым, про LTO ему знать необязательно.

я у себя сделал

#!/bin/bash -e


if [[ " $* " =~ [[:space:]]-shared(-.*)?[[:space:]] ]]; then
        "${compiler[@]}" -no-pie -fPIC "$@"  
elif [[ " $* " =~ [[:space:]]-static(-.*)?[[:space:]] ]]; then
        "${compiler[@]}" -no-pie -static-pie -fPIC "$@" 
else
        "${compiler[@]}" -pie -fPIC "$@"
fi

MOPKOBKA, -fPIC добавил для библиотек, потому что может быть ситуация, когда gcc вызывается один раз сразу для стадий компиляции и стадии линковки gcc -shared -o libexample.so example.c

для такого старого железа подойдёт Bodhi Linux, Puppy Linux, Tiny Core Linux

Я себе так, вроде static-pie нуждается в флагах -fPIE. Добавил еще flto, curl собирает, потом попробую собрать другие системные библиотеки.

set -e

hardened_flags="               \
  -D_FORTIFY_SOURCE=2          \
  -D_GLIBCXX_ASSERTIONS        \
  -fasynchronous-unwind-tables \
  -fexceptions                 \
  -fstack-protector-all        \
  -fstack-protector-strong     \
  -fstack-clash-protection     \
  -ftrivial-auto-var-init=zero \
  -fcf-protection=full"

pie_ldflags="-Wl,-z,defs,-z,relro,-z,now"
extra_flags="                        \
  -flto -ffat-lto-objects            \
  -march=raptorlake -mtune=alderlake \
  -fsplit-paths                      \
  -fuse-linker-plugin"

if [[ "$0" == "g++-pie" ]]; then
  cc=${PIE_CXX:-g++}
else
  cc=${PIE_CC:-gcc}
fi

if [[ ! " $* " =~ [[:space:]]-O(s|g|f|[[:digit:]])(ast)?[[:space:]] ]]; then
  # -flto requires
  extra_flags+=" -O2 "
fi

if [[ " $* " =~ [[:space:]]-shared[[:space:]] ]]; then
  $cc $hardened_flags -fPIC -no-pie $* $extra_flags
elif [[ " $* " =~ [[:space:]]-static[[:space:]] ]]; then
  $cc $hardened_flags -fPIC -pie -static-pie $pie_ldflags $* $extra_flags
else
  $cc $hardened_flags -fPIC -pie $pie_ldflags $* $extra_flags
fi

CPU Cooler: Thermaltake Contac Silent 12 (Noctua NF-P12 PWM)

А вот тут точно будут проблемы. К сожалению, поддержка появилась только в последней BolgenOS. Когда до генты и никсоси докатится – вопрос философский. Не исключено, что никогда.

-fstack-protector-all \ -fstack-protector-strong \

лучше поменять местами. all сильнее, а задействована будет последняя.

вот мой список, но в нём также оптимизации для производительности:

-O2
-march=bdver2
-fstack-clash-protection
-fstack-protector-strong
-fstack-protector-all
-fzero-call-used-regs=skip
-fipa-cp-clone
-fira-loop-pressure
-floop-interchange
-floop-unroll-and-jam
-fpredictive-commoning
-fstdarg-opt
-ftree-loop-distribution
-ftree-partial-pre
-ftrivial-auto-var-init=zero
-fvariable-expansion-in-unroller
-fweb
-fharden-control-flow-redundancy
-funroll-loops
-ftree-vectorize
-fmerge-all-constants
-fipa-pta
-fexceptions
-fsanitize=address
-fsanitize=signed-integer-overflow
# -fsanitize=unsigned-uninteger-overflow
-fsanitize-trap=signed-integer-overflow
# -fsanitize-trap=unsigned-integer-overflow
-flto="$JOBS"
-ffat-lto-objects
-fuse-linker-plugin
-fno-strict-overflow
-fno-delete-null-pointer-checks

-Wa,-mamd64,-O2,--strip-local-absolute #,--relax
-Wl,-O2,-znoexecstack,-znow,-zseparate-code,-zstart-stop-visibility=hidden,-zrelro,--no-omagic,--relax

перформанс

Не нужно.

я у себя в начале ещё прописал

case "${0##*/}" in

cc)             compiler=(/usr/bin/cc);;

c++|g++)        compiler=(/usr/bin/g++);;

gcc)            compiler=(/usr/bin/gcc)

esac

через LDFLAGS, а -Wl лишний

т.е. -Wl и -Wa вообще не надо передавать, достаточно ASFLAGS и LDFLAGS?
просто иногда сталкивался с тем, что если дополнительно указываешь -Wl, с теми же опциями, что и LDFLAGS, также -Wa, с теми же опциями, что и ASFLAGS, некоторые пакеты при сборке ругаются на одну какую-нибудь опцию линковщика (или асемблера), при этом все перечисленные опции корректно отрабатывают если перечислены только в LDFLAGS (или ASFLAGS) без заданного -Wl, и -Wa, соответственно. Вот я и подумал, что ASFLAGS и LDFLAGS не всегда подгружаются.

Год назад еще был хорош Gentoo, но он скатился в чертовую яму... Остается NixOS.

а ты как запускаешь?

.   /etc/env/gcc-pie # export CXX=/usr/local/bin/g++-pie CC=/usr/local/bin/gcc-pie ... 
./program.SlackBuild

т.е. -Wl и -Wa вообще не надо передавать, достаточно ASFLAGS и LDFLAGS?

Я понимаю что так, вот из документации gcc

gcc -c -O2 -flto foo.c
gcc -c -O2 -flto bar.c
gcc -o myprog -flto -O2 foo.o bar.o

заметил одну странность
отсутствуют pie ключи

Makefile же выполняет твой скрипт, а ключи внутри него, а не передаются в него. В самом скрипте можешь сделать перед последним шагом set -x

Можно ускорять тормозной файловый менеджер, тормозную отрисовку всего, загрузку

Пожалуйста, расскажи подробнее про ускорение загрузки KDE.

Она медленная, ее нужно ускорить, все. Как ускорять я не знаю, но в других DE таких проблем нету, поэтому пусть скопируют процесс загрузки любого DE из существующих.

Загрузка действительно медленная. Также интересно про отрисовку. Dolphin редко используется, гораздо быстрее ls, cd, cp, mv, rm в konsole.

ИМХО, любой.

Поставить любой нормальный дистр)

а как быть с ключём -fPIC, который нужен для сборки статических библиотек? вроде как для сборки статических библиотек не задаётся -static, да и -pie и -static-pie можно использовать только для сборки статически линкованных исполняемых файлов.

ещё у меня почему-то при сборке с pie-ключами статически линкованного исполняемого файла из пакета pkgutils возникает ошибка (уже после того, как собрал с pie-ключами весь core из CRUX):

/S//PM/g++ -O2  -march=bdver2  -Wall -fdiagnostics-color=auto   -DNDEBUG -O2 -Wall -pedantic -D_GNU_SOURCE -DVERSION=\"5.40.10\" -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -MM main.cc pkgutil.cc pkgadd.cc pkgrm.cc pkginfo.cc > .depend
/S//PM/g++ -O2  -march=bdver2  -Wall -fdiagnostics-color=auto   -DNDEBUG -O2 -Wall -pedantic -D_GNU_SOURCE -DVERSION=\"5.40.10\" -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64   -c -o main.o main.cc
/S//PM/g++ -O2  -march=bdver2  -Wall -fdiagnostics-color=auto   -DNDEBUG -O2 -Wall -pedantic -D_GNU_SOURCE -DVERSION=\"5.40.10\" -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64   -c -o pkgutil.o pkgutil.cc
/S//PM/g++ -O2  -march=bdver2  -Wall -fdiagnostics-color=auto   -DNDEBUG -O2 -Wall -pedantic -D_GNU_SOURCE -DVERSION=\"5.40.10\" -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64   -c -o pkgadd.o pkgadd.cc
/S//PM/g++ -O2  -march=bdver2  -Wall -fdiagnostics-color=auto   -DNDEBUG -O2 -Wall -pedantic -D_GNU_SOURCE -DVERSION=\"5.40.10\" -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64   -c -o pkgrm.o pkgrm.cc
/S//PM/g++ -O2  -march=bdver2  -Wall -fdiagnostics-color=auto   -DNDEBUG -O2 -Wall -pedantic -D_GNU_SOURCE -DVERSION=\"5.40.10\" -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64   -c -o pkginfo.o pkginfo.cc
sed -e "s/#VERSION#/5.40.10/" pkgmk.in > pkgmk
sed -e "s/#VERSION#/5.40.10/" rejmerge.in > rejmerge
sed -e "s/#VERSION#/5.40.10/" pkgadd.8.in > pkgadd.8
sed -e "s/#VERSION#/5.40.10/" pkgrm.8.in > pkgrm.8
sed -e "s/#VERSION#/5.40.10/" pkginfo.8.in > pkginfo.8
sed -e "s/#VERSION#/5.40.10/" pkgmk.8.in > pkgmk.8
sed -e "s/#VERSION#/5.40.10/" rejmerge.8.in > rejmerge.8
sed -e "s/#VERSION#/5.40.10/" pkgmk.conf.5.in > pkgmk.conf.5
sed -e "s/#VERSION#/5.40.10/" pkgfile.5.in > pkgfile.5
/S//PM/g++ main.o pkgutil.o pkgadd.o pkgrm.o pkginfo.o -o pkgadd -static -larchive -lz -lbz2 -llzma -lzstd -lcrypto -lexpat -lacl -lssl
/usr/bin/ld: pkgutil.o: in function `pkgutil::pkg_footprint(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) const':
pkgutil.cc:(.text+0x58cc): warning: Using 'getgrgid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: pkgutil.cc:(.text+0x5863): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /tmp/ccGIrjlU.ltrans1.ltrans.o: in function `lookup_gid.lto_priv.0':
/w/w/src/libarchive-3.7.5/libarchive/archive_write_disk_set_standard_lookup.c:132: warning: Using 'getgrnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /tmp/ccGIrjlU.ltrans1.ltrans.o: in function `lookup_uid.lto_priv.0':
/w/w/src/libarchive-3.7.5/libarchive/archive_write_disk_set_standard_lookup.c:201: warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/12.4.0/crtbeginT.o: relocation R_X86_64_32 against hidden symbol `__TMC_END__' can not be used when making a PIE object
/usr/bin/ld: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status
make: *** [Makefile:46: pkgadd] Error 1

а как быть с ключём -fPIC, который нужен для сборки статических библиотек?

Он у меня везде прописывается, в чем там проблема?

ещё у меня почему-то при сборке с pie-ключами статически линкованного исполняемого файла из пакета pkgutils возникает ошибка (уже после того, как собрал с pie-ключами весь core из CRUX):

Попробуй сделать в скрипте замену аргумента -static на -static-pie

Он у меня везде прописывается, в чем там проблема?

туплю

Попробуй сделать в скрипте замену аргумента -static на -static-pie

попробовал заменить в Makefile, там оно через LDFLAGS задаётся. теперь такая ошибка: https://sebsauvage.net/paste/?fce86dc874b0f07c#hCwfpgs ieO071FIpPz8zHkmyhdPpA...
вот Makefile: https://sebsauvage.net/paste/?cb224f12df00ab24#Sg83PwqszI6VaFBYKzjwMgblq3irDl...

Хм, не встречал, а если отключить LTO для этой сборки?

нашёл причину. если перед сборкой pkgutils — bzip2 был собран с -flto, то при сборке pkgutils возникает ошибка. вот Makefile bzip2: https://pastebin.com/TVWPcZPh
там вообще .a собирается как-то странно, через ar собирается из .o. может, можно как-то подправить Makefile, чтобы .a собирался нормально?

и да, пришлось поменять -static на -static-pie в Makefile pkgutils.

там вообще .a собирается как-то странно, через ar собирается из .o. может, можно как-то подправить Makefile, чтобы .a собирался нормально?

Это же и есть нормальный способ

нашёл причину. если перед сборкой pkgutils — bzip2 был собран с -flto, то при сборке pkgutils возникает ошибка. вот Makefile bzip2

А ты используешь -ffat-lto-objects в bz2+pkgutils? А если -Wl,--as-needed убрать из pkgutils?

А ты используешь -ffat-lto-objects в bz2+pkgutils?

да. попробовал собрать bzip2 с -flto -fno-fat-lto-objects — выдаёт undefined reference'ы.

А если -Wl,--as-needed убрать из pkgutils?

вроде как его и не было, но прописывание -Wl,--no-as-needed не помогло.

А если попробовать pkgutils собрать без отладочной информации? В ней основные ошибки, и нужно будет еще добавить ubsan в -l, пишет что он вызывается в bz2 но не подлинковывается у тебя.

не помогло.

Хочу чтобы нейронки работали быстрее.

По-настоящему ускоряет это:

https://coral.ai/products/m2-accelerator-dual-edgetpu/