https://groups.google.com/g/llvm-dev/c/HxXbT3qKYgg/m/kvNdxP0oAgAJ #maskray

Впервые с товарищем я столкнулся, когда он пришел в уютненький тредик про busybox style multicall binary для #LLVM(я очень ХОТЕТ). Он, соответственно, рассказывал, что это не нужно, и что это не дает перфа, и что размер не улучшится. Потом я узнал, что он один из авторов LLD, и ведет блог про линкер(не, реально, пишет много про линковку) - https://maskray.me/, правда, половина там на китайском. Короче, неудивительно, что человек, постигший все тайны динамической линковки не хочет оставаться не у дел, потому что статическая линковка проста, как 3 копейки. Пчелы против меда. Ульриха Дреппера про динамическую линковку не стоит слушать по той же причине(https://gavinhoward.com/2021/10/static-linking-considered-harmful-considered-harmful/).

Правда, потом он исправился, и даже зачинил несколько багов для multicall binary(ссылку не дам, лень искать).

А вот на днях он опубликовал пост про LLD, сравнение с #mold(кстати, Mold особенно хорошо идет с Rust, хехе), и все такое. Коллега совершает стандартную ошибку тех, кто не занимается перфом профессионально - он не делает прямых измерений(perf record), а только косвенные, и строит по ним предположения, как же работает программа.

https://maskray.me/blog/2021-12-19-why-isnt-ld.lld-faster

———
Short news - последнее время вместо HN я читаю lobste.rs, чего и вам желаю. Никакой политоты, только технически интересные штуки.

———
https://tom-kaitchuck.medium.com/designing-a-new-prng-1c4ffd27124d

Товарищ решил, что ему хочется не только посмотреть на срачик Мелиссы О'Нил и автора Хороширо, но и присоединиться к ним. Еще один PRNG.

Я однажды тоже запилил свой PRNG, он был норм, и по скорости, и даже проходил DieHard, Test01, и BigCrush, но у меня хватило ума не внедрять его никуда. Ну был он на 10% лучше, чем тогдашний конкурент? Но если что пойдет не так - не отмоешься же потом(как и произошло с автором Хороширо).

(срачик его с Мелиссой я уже в этом блоге кидал)

https://maskray.me/blog/2022-01-16-archives-and-start-lib #maskray

Рассказ про изобретение thin archive.

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

История изобретения:

Однажды вышел clang с поддержкой lto, и я очень захотел собрать с ней базовый поиск. LTO там было сделано на отъебись - компилятор мог родить .o файл с промежуточным представлением, и на этом все.

Эти объектные файлы нельзя было объединить в .a, нельзя было позвать clang для линковки. Единственное, что там было - это команда "opt", которая могла слинковать несколько lto .o файлов в 1, попутно применив оптимизации, была команда, которая делала asm файл из этого .o, а дальше можно было взять этот asm, руками сделать из него настоящий .o, и слинковать все это вместе с системным кодом, для которого нет lto .o файлов.

Короче, я на петончиге соорудил подобие архиватора и линкера из этих примитивов, и оно даже заработало. В тот момент мне стало понятно, что гораздо проще в .a запиклить* пути к lto .o, чем пиклить данные, а потом разпикливать их в fs, для запуска "opt". Так я изобрел thin archives.

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

Почему их не нужно использовать.

* На HDD это приводило к бешеному росту iops, по понятным причинам. На ssd это менее релевантно.
* Даже на ssd остается проблема с readahead - мы читаем с диска существенно больше данных, чем надо.

Ладно, есть 1 случай, когда thin archives немного помогают. Если у вас до жопы памяти, и вы потребляете архивы сразу по мере изготовления(one shot build, например), некое ускорение можно наблюдать.

Но лучше не надо, потому что ускорение эфемерно, а огрести при нехватке памяти все еще можно.

* - literally. pickle.dumps(sys.argv[2:]) - вот примерное устройство моего ar.

#maskray, #mold

Коллега никак не успокаивается(и это хорошо!), написал план про ускорение LLD.

https://discourse.llvm.org/t/parallel-input-file-parsing/60164

Речь идет про распараллеливание построения таблицы символов.

Мне такая параллелизация не очень к месту, не раз уже рассказывал, почему(потому что она не уменьшает количество нужных для линковки CPU циклов, а вот равномерность потребления процессора ухудшает).

КМК, тут коллегам нужно уже перестать сцать менять форматы файлов, и подумать на предмет непарсируемых .o/.a файлов, например, используя flatbuffers, или capnproto.

Но, к сожалению, в мире дедов с ABI С/C++ это малореалистично.

https://maskray.me/blog/2022-11-13-odr-violation-detection

Текст от #maskray, про то, как разные фреймворки реализуют поиск ODR violation.

Сухо, скучно, без огонька, как будто коллега пишет не зажигательный текст про линкер, а зарплату отрабатывает!

Но я вот не знал, как это делает asan runtime, красивое.

https://maskray.me/blog/2022-11-21-relocatable-linking

Знаменитый блоггер #maskray продолжает серию постов про линкер.

На этот раз про опцию линкера "-r", которая, по сути, умеет сливать два .o файла в один, делая частичную линковку в процессе.

Не спрашивайте, зачем, если вам не нужно - то не нужно, а если нужно - то вы уже знаете.

Я-то надеялся из этой статьи узнать, что делает мутная опция gnu ld "-Ur":

"-Ur
For anything other than C++ programs, this option is equivalent to -r: it generates relocatable output--i.e., an output file that can in turn serve as input to ld. When linking C++ programs, -Ur does resolve references to constructors, unlike -r. It does not work to use -Ur on files that were themselves linked with -Ur; once the constructor table has been built, it cannot be added to. Use -Ur only for the last partial link, and -r for the others"

Вот вы понимаете, что она actually do? Я - не очень.

Мое лучшее предположение - что она включает генерацию секций .ctor(и подобных), что никто больше делать не умеет, потому что зачем???

Я так понимаю, что релевантный кусок текста от #maskray - это вот это вот:

"The linker does not create synthesized sections (.interp, .gnu.hash, .got, .plt, .comment, etc)"

Собственно, мне было бы на это пофиг, но у меня есть ровно одна программа в репозитории, которая хочет от линкера такую опцию - это https://github.com/pg83/ix/blob/main/pkgs/bin/nix/ix.sh (да, да, Nix package manager, тот самый)

В итоге, я решил, что имею полное право заменить -Ur на просто -r, https://github.com/pg83/ix/blob/main/pkgs/bld/scripts/wrapcc/kuroko/wrapcc.krk#L32, потому что какого хрена? Ну сгенерят таблицу конструкторов чуть позже, ну и ладно.

Писал, что Столлман и его проект GNU, на самом деле, очень похожи на Гейтса, и MS. #gnu hate speech

Только MS жаден до ваших денег, а GNU - до вашего кода. (я лично считаю, что любая жадность - это плохо, потому что все, в итоге - время, и я уважаю open source, который #charity)

Вот вам интересный факт - GNU переняла тактику MS, которая https://ru.wikipedia.org/wiki/Embrace,_Extend,_and_Extinguish

У них, на самом деле, есть целый проект про это, называется #gnulib (!= glibc, != glib) (это такая попытка привязать софт к API несуществующей OS, да так, чтобы невозможно было выпилить), но про него надо написать отдельно.

Сегодня - вот про такой забавный #EEE, от гнутого линкера.

https://cgit.freedesktop.org/libbsd/tree/src/setproctitle_ctor.c#n51

Что здесь написано?

Здесь написано, что произвольная so может получить доступ к argc и argv процесса в момент инициализации, для этого достаточно положить указатель на функцию в секцию .init_array. Может ли она их творчески модифицировать, или линкер передает туда RO копию, я хз.

https://maskray.me/blog/2021-11-07-init-ctors-init-array

#maskray пишет, что эту дырень придумали в HP, потом GNU скопировала к себе, а потом разошлось по другим free unix.

"glibc and BSD implementations call the constructors with argc, argv, environ while musl's calls the constructors with no argument"

Классический EEE - запилили странную фичу, а потом конкуренты вынуждены это повторять, для совместимости: "FreeBSD added support in 2012-03. OpenBSD added support in 2016-08. NetBSD made DT_INIT_ARRAY available for all ports in 2018-12"

Не думаю, что BSD добавили это от хорошей жизни, видно, что долго сопротивлялись.

Интересный текст про то, как санитайзерные рантаймы перехватывают библиотечные функции, от зажигательного блоггера #maskray https://maskray.me/blog/2023-01-08-all-about-sanitizer-interceptors

Читал я этот текст ради одной строчки, "On Apple platforms, sanitizers use a dyld feature to intercept symbols. Only dynamic runtime is supported", печаль-беда.

Знаменитый блоггер #maskray продолжает радовать нас зануднейшими текстами про устройство линкера. КМК, читать такое можно только либо за зарплату, ну или если вы - фанат. https://maskray.me/blog/2023-05-14-relocation-overflow-and-code-models

Основной текст интересен только тем, кто сталкивается со статической линковкой библиотек от nvidia (e.g. cuda), потому что они огромные, и не помещаются в 2GB. TL;DR - чуда не произошло, хотя, иногда, возможно, станет чуть лучше (когда из .text не получается дотянуться до .data в large code model, если я все верно понял).

Мякотка для моего блога в:

Static linking also offers performance benefits in several aspects:

* Link-time optimization is more effective when all dependencies are known. Providing shared object information during executable optimization is possible, but it may not be a worthwhile engineering effort.

* Profiling techniques are more efficient dealing with one single executable.

* The traditional ELF dynamic linking approach incurs overhead to support symbol interposition.

* Dynamic linking involves PLT and GOT, which can introduce additional overhead. Static linking eliminates the overhead.

* Loading libraries in the dynamic loader has a time complexity O(|libs|^2*|libname|). The existing implementations are designed to handle tens of shared objects, rather than a thousand or more.

В копилочку преимуществ статической линковки, конкретно, почему "быстрее".

#maskray #rant

https://maskray.me/blog/2021-11-07-init-ctors-init-array

А вот еще один классный текст от знаменитого блоггера MaskRay!

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

Наткнулся я на этот текст по рабочей необходимости.

Старая версия CUDA (<= 10), которую все еще иногда приходится использовать, содержит в себе секции .ctors, но не содержит .init_array. А используемый нами линкер пару лет назад перестал поддерживать секцию .ctors. Ну и нам приходилось поддерживать патчи на линкер, чтобы он умел в .ctors, а не только в .init_array.

При переходе на новую версию линкера мне надоело накладывать эти патчи, и я, пользуясь этой заметкой, бинарно переделал библиотеки от nvidia, переместив конструкторы из .ctors в .init_array.

Примерно вот такой командой:

objcopy --rename-section .ctors=.init_array file

Что нам говорит этот вызов?

Что формат .ctors и .init_array ничем не отличаются, это одна и та же секция, просто ее назвали иначе.

Чем же кому-то не угодила секция .ctors, почему в новых стандартах пришлось заводить .init_array, который, по сути, ничем не отличается, и зачем нужно было убирать поддержку .ctors, история (и MaskRay) умалчивают:

"Under the hood, on ELF platforms, the initialization functions or constructors are implemented in two schemes. The legacy one uses .init/.ctors while the new one uses .init_array"

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

#maskray, #llvmweekly

Очередной зажигательный текст от нашего коллеги - https://reviews.llvm.org/rG904b3f66f59e

TL;DR - новая эвристика в алгоритме, который пытается наиболее оптимальным образом (видимо, с точки зрения заданного perf/call graph) распределить код функций по бинарнику.

Говорят, более хорошо учли instruction cache, и все такое.

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

Наверное, можно примерно себе представить самый тупой алгоритм, который попробует все возможные взаиморасположения функций, посчитает для каждого такого расположения теоретический perf (с точки зрения кеша инструкций), например, запустив монтекарлу (вероятности перехода между функциями мы знаем из call graph, вроде, больше ничего и не нужно).

Ну а как сделать что-то такое "быстро", с ходу совсем не очевидно.

Пишут, что ажно +1% перфа, по сравнению с предыдущим алгоритмом.