Mirror of YDB github repos https://code.mastervirt.ru/ydb/atom?h=CLI_2.11.0 2024-06-12T21:14:04Z 2024-06-12T21:14:04Z deshevoy deshevoy@yandex-team.com 2024-06-12T21:04:21Z urn:sha1:3069c8835032617846ef6fc3a911daf67b9d3f72 bddf00bb1bd387adf17502c2af8be1e265c8f5a8 2024-06-09T16:25:39Z deshevoy deshevoy@yandex-team.com 2024-06-09T16:12:05Z urn:sha1:c191ecd15978bda625d24c6cd94e63618fa0174f 4ef12dd52c1d38cd7a1018ec1bc40800644ea775 2024-05-29T06:51:01Z mikhnenko mikhnenko@yandex-team.com 2024-05-29T06:34:12Z urn:sha1:2b58663bc4bdccdb1a66be41b4a5024e30129676 b7ff75f77e1a1818aac0062ec06948dad92af1bc 2024-05-16T07:54:44Z zhukoff-pavel zhukoff-pavel@yandex-team.com 2024-05-16T07:44:11Z urn:sha1:e64cac4257cf05ee71df00f27cc399cf44a58d81 d9beae52f9300e65eddec8c2b865f132ea6b5833 2024-03-29T11:31:49Z spreis spreis@yandex-team.com 2024-03-29T11:18:43Z urn:sha1:f39261a434c46274b5eaef0927ee3b2e0d95b41a Это откат коммита https://a.yandex-team.ru/arcadia/commit/rXXXXXX И соответственно возврат коммитов https://a.yandex-team.ru/arcadia/commit/rXXXXXX и https://a.yandex-team.ru/arcadia/commit/rXXXXXX Починка причины отката влилась здесь: https://a.yandex-team.ru/arcadia/commit/rXXXXXX ae529e54d3ef7992b0e9f152373bc300061c1293 2024-03-28T08:17:45Z spreis spreis@yandex-team.com 2024-03-28T08:07:37Z urn:sha1:2de742ce97267f0469cf0c9bd384488c91442bce Эта история про второй питон подразнесла нам графогенерацию . Нам придется этот коммит откатить. Суть проблемы в том, что генерация для 2го и 3го раньше была одной и той же командой. Ты сделал так, что команда стала разной, но аутпут этих двух команд одинаковый. Имя результата команды является ключом и сейчас берётся какая-то рандомная команда из двух. При этом команда влияет на UID и все UIDы питонячей протогенерации мигают. От фатальных проблем нас спасает только то, что protobuf-ы на самом деле одинаковые. И даже это не факт - сейчас ты патчишь какие-то рандомные либы включая таковые для 3го питона. Мы тут конечно редиски - мы в целом контролируем клэши аутпутов, но не в мультимодулях - там часто бывает что одна и та же команда оказывается в нескольких вариантах мультимодуля (потому что оно по дефолту сейчас так себя ведёт). Мы хотим это зачинить (сделать отдельный подмодуль под кодген и отселить всякие RUN_PROGRAM туда) - но это много работы и мы не успели. План такой: 1. мы откатываем твой фикс 2. отдельно стабилизируем раздельные команды генерации для 2го и 3го питона 3. накатываем обратно отревеченные тут правки. 916a5456c4e901ab2cda0841b4167e16397e83c4 2024-03-27T17:59:16Z pg pg@yandex-team.com 2024-03-27T17:45:52Z urn:sha1:0a9f70229b9ddccbd4a09d389642ddafcbe8fd57 2024-03-07T20:15:23Z toshiksvg toshiksvg@yandex-team.com 2024-03-07T19:57:59Z urn:sha1:7c1f60188c1081eafec304ac8ca36dcbfd5b8f93 Добавил функцию, чтобы все библиотеки из CUDA пакетов, которые статически линкуются, гарантировано имели символы в секции `.array_init`, а не в `.ctors`, как происходит сейчас. В противном случае некоторые библиотеки не работают в случае статической линковки (например, `nvrtc`). 1362e42f94015ba083431caa04d7ae436fd6bf99 2024-02-03T10:24:17Z kickbutt kickbutt@yandex-team.com 2024-02-03T10:02:23Z urn:sha1:fc1e67a2ad8c64bea6ca9301aa220764eac1dd03 2024-02-02T13:56:43Z kickbutt kickbutt@yandex-team.com 2024-02-02T13:23:03Z urn:sha1:4de76318534d06a55933c377704772a57e80165b ~~большой~~ PR по переключению дефолтной версии CUDA с cuDNN в Аркадии Обновляем CUDA: 10.1 -> 11.4 Обновляем cuDNN: 7.6.5 -> 8.0.5 Помимо простого обновления версий, данный PR содержит следующее: * От перехода на CUDA 11.4 честно сломался только [один проект](https://a.yandex-team.ru/arcadia/cv/imgclassifiers/danet/backend/gpu_cuda?rev=rXXXXXX), поэтому просто там правим * Где-то поменялись тесты на объём потребляемой памяти, поэтому их просто переканонизируем * По поводу удаления таргетов из clang_prev_targets: - `ld.lld` из поставки clang14 не справляется с линковкой - не может найти символы в попруненных либах, хотя они там есть - но можно просто переключиться на автосборку, потому что те проблемы [совместимости cuDNN и clang](https://st.yandex-team.ru/#655b977f30316b33e3a5ec87), для которых gpu-шные таргеты добавляли в clang_prev_targets, в автосборке уже не существуют * По поводу удаления таргетов из cuda11_targets - теперь cuda11_targets отличается от автосборки версией TensorRT (5 в автосборке vs 7 в cuda11) и режимом сборки (relwithdebinfo в автосборке vs release в cuda11), но есть два момента - те, таргеты, которые я удаляю, не зависят от TensorRT, поэтому их не имеет смысла их тестить и в автосборке, и в cuda11 (про таргет `ads/quality/sis/tests/cuda11_arch80` мне сейчас ничего не известно; если что - выпилим его отдельным таргетом) - на самом деле дублирование даже вредно - в `dict/mt/daemon/tests/gpu` есть тест на потребление памяти gpu, который имеет разные результаты в зависимости от release vs relwithdebinfo, поэтому для этого таргета мы в принципе не можем собираться одновременно и в автосборке, и в cuda11 По поводу дефолтной автосборки в принципе пришлось сделать четыре приседания: * пишем кастомный скрипт для линкера: - идея скрипта: переставляем большую секцию с gpu-шным кодом (`.nv_fatbin`) после `.bss` (самая дальняя секция, куда можно ожидать ссылки из кода бинаря), чтобы было меньше шансов нарваться на проблемы с relocation overflow в (`.bss`) - замечание: в самом скрипте используем в нём только `INSERT AFTER`, чтобы [ld.ldd и дальше применял свои дефолтные правила для остальной программы](https://releases.llvm.org/16.0.0/tools/lld/docs/ELF/linker_script.html#sections-command) - сделал замеры перфа генезисного инференса через `ml/zeliboba/libs/ynmt_lm/translate/bin` на том сценарии, который оказался под рукой - не заметил каких-то изменений * добавляем nvcc-флаг `-Xfatbin=-compress-all`, чтобы наш fatbin сжимался и занимал меньше пространства в бинаре (далее он будет разжиматься на старте программы, так что оверхеда быть не должно) - сделал замеры перфа генезисного инференса через `ml/zeliboba/libs/ynmt_lm/translate/bin` на том сценарии, который оказался под рукой - не заметил каких-то изменений * добавляем флаг линкера `--no-relax`, так как опция "relaxation of relocatable symbols" (когда мы load в регистр + jump по адресу в регистре заменяем на относительный jump) уменьшает допустимый диапазон оффсетов, которые мы можем кодировать, что также приводит к relocation overflow - больше информации можно найти в https://maskray.me/blog/2023-05-14-relocation-overflow-and-code-models - сделал замеры перфа генезисного инференса через `ml/zeliboba/libs/ynmt_lm/translate/bin` на том сценарии, который оказался под рукой - не заметил каких-то изменений * ещё чуть более гранулярно выпиливаем лобзиком архитектуры из либ в поставках CUDA / cuDNN - в категории "ассемблерный код" (`compute_XX`) оставляем только для последней версии поддерживаемой архитектуры (то есть `compute_86`), так как на новых GPU-шках мы будем JIT-компилироваться из него, а на старых GPU-шках мы возьмём готовый машинный код для них Эти идеи были в основном взяты из следующих источников: - https://maskray.me/blog/2021-07-04-sections-and-overwrite-sections#insert-before-and-insert-after и https://discourse.llvm.org/t/lld-relocation-overflows-and-nv-fatbin/58889 (про перемещение `.nv_fatbin`) - https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#nvprune (про `nvprune`) - https://maskray.me/blog/2023-05-14-relocation-overflow-and-code-models#relocation-overflow (`-Wl,--no-relax`) - https://discourse.llvm.org/t/lld-relocation-overflows-and-nv-fatbin/58889/6 + https://github.com/pytorch/pytorch/pull/43074/files#diff-1e7de1ae2d059d21e1dd75d5812d5a34b0222cef273b7c3a2af62eb747f9d20aR360 (про `-Xfatbin=-compress-all`) Дополнительные комментарии: - можно дополнительно не выпиливать ненужные архитектуры, но этот флаг дополнительно уменьшает размеры бинарей (например, таргет `ml/zeliboba/libs/ynmt_lm/translate/bin`уменьшается на 120 MiB, что составляет примерно 5% от размера бинаря) - кастомный скрипт для линкера позволяет не развлекаться с ещё более гранулярным выпиливанием архитектур (например, для таргетов `TENSORFLOW_WITH_CUDA`) Оставшийся технический долг, который будет делать в других PRах * донести функциональность из `link_exe.py` в `link_dyn_lib.py` * перейти на TensorRT 7 * выпилить cuda11_targets * выпилить флаг `TENSORFLOW_WITH_CUDA` в пользу `CUDA_REQUIRED` и удалить tensorflow_with_cuda_targets (??) * поднять версию стандарта c++ для гпушного кода с 14 до 17