| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
0863674d44d570c182d324e821946e3f4d898d94
|
| |
|
|
| |
ac03c8c8d7beb99b5a8fcda8c0c6bf948ca2bb2e
|
| |
|
|
| |
bddf00bb1bd387adf17502c2af8be1e265c8f5a8
|
| |
|
|
| |
4ef12dd52c1d38cd7a1018ec1bc40800644ea775
|
| |
|
|
| |
b7ff75f77e1a1818aac0062ec06948dad92af1bc
|
| |
|
|
| |
d9beae52f9300e65eddec8c2b865f132ea6b5833
|
| |
|
|
|
|
|
|
| |
Это откат коммита 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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Эта история про второй питон подразнесла нам графогенерацию . Нам придется этот коммит откатить.
Суть проблемы в том, что генерация для 2го и 3го раньше была одной и той же командой. Ты сделал так, что команда стала разной, но аутпут этих двух команд одинаковый. Имя результата команды является ключом и сейчас берётся какая-то рандомная команда из двух. При этом команда влияет на UID и все UIDы питонячей протогенерации мигают. От фатальных проблем нас спасает только то, что protobuf-ы на самом деле одинаковые. И даже это не факт - сейчас ты патчишь какие-то рандомные либы включая таковые для 3го питона.
Мы тут конечно редиски - мы в целом контролируем клэши аутпутов, но не в мультимодулях - там часто бывает что одна и та же команда оказывается в нескольких вариантах мультимодуля (потому что оно по дефолту сейчас так себя ведёт). Мы хотим это зачинить (сделать отдельный подмодуль под кодген и отселить всякие RUN_PROGRAM туда) - но это много работы и мы не успели.
План такой:
1. мы откатываем твой фикс
2. отдельно стабилизируем раздельные команды генерации для 2го и 3го питона
3. накатываем обратно отревеченные тут правки.
916a5456c4e901ab2cda0841b4167e16397e83c4
|
| | |
|
| |
|
|
|
|
|
| |
Добавил функцию, чтобы все библиотеки из CUDA пакетов, которые статически линкуются, гарантировано имели символы в секции `.array_init`, а не в `.ctors`, как происходит сейчас.
В противном случае некоторые библиотеки не работают в случае статической линковки (например, `nvrtc`).
1362e42f94015ba083431caa04d7ae436fd6bf99
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
~~большой~~ 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
|
| |
|
|
|
|
| |
Чиним две проблемы, обнаруженные опытным путём:
* во-первых, cudart не содержит никакого девайсного кода, поэтому её не имеет смысла прунить
* во-вторых, нам для линковки могут передать несуществующие директории, поэтому делаем код проверок чуть более многословным
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Добавляю переменную `CUDA_ARCHITECTURES`, в которых указываю, для каких архитектур оставлять device-код в гпушных либах CUDA / cuDNN
* Выставляю для неё разумные дефолты для тех архитектур, которые потенциально страдают от избыточного размера кода (сейчас это 11.4, потом можно будет расширить для других архитектур)
* Пробрасываю эту переменную и путь до бинарника `nvprune` в скрипт линковки
* Ищу и пруню гпушные либы
Как проверить, что работает:
* например, успешно собирается `ya make --build=release -DTENSORFLOW_WITH_CUDA -DCUDA_VERSION=11.4 -DCUDNN_VERSION=8.0.5 -DCUDA_ARCHITECTURES=sm_70 yweb/webdaemons/ocrdaemon` (с дефолтным `-DCUDA_ARCHITECTURES` падает по relocation overflow)
* елси хочется посмотреть на изменение размеров, то можно собрать `ya make ml/zeliboba/libs/ynmt_lm/score/bin/ --build=relwithdebinfo -DCUDA_VERSION=11.4 -DCUDNN_VERSION=8.0.5` один раз с дефолтным значением, другой раз с `-DCUDA_ARCHITECTURES=sm_70,sm_80,compute_80` - размер бинаря уменьшится
Особенности:
* ~~Сейчас дефолт для каждой новой версии куды содержит в себе тупо все поддерживаемые архитектуры. Имеет смысл его порезать до чего-то более разумного~~ - порезал
* Обход аргументов в обратном порядке сделан для того, чтобы эмулировать поведение линкера (для линкера важен порядок пробрасывания между либами для линковки и директориями, в которых их нужно искать)
* ~~Сейчас артефакты прунинга кладутся рядом с оригинальными либами; возможно, стоит их складывать в отдельное место в build-директории, но я пока не разобрался как это делать; буду рад, если кто-то подскажет~~ уже неактуально - кладу в build_root
* nvprune имеет свойство мусорить варнингом в stderr, когда прунит `libcudart_static.a` (это норма - там нет кода, который можно было бы попрунить); как вариант можно закостылить и не прунить `libcudart_static.a`, но я открыт к предложениям
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
ref:e2d05ce38be56e0783b84372504682f58fbb3c5c
|
| |
|
|
| |
ref:4b4acf4c3b9e1212fd3c6ed880d7d81b5da0b227
|
| |
|
|
| |
ref:ca7a95e8c9a9d780f96497136a152091d54e61b5
|
| |
|
|
| |
ref:f1a76bb520860c96f863dde2f5dfa5e45b9ea67b
|
| | |
|
| | |
|
| |
|
|
| |
2 of 2.
|
| |
|
|
| |
1 of 2.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
<[email protected]>. Commit 2 of 2.
|
| |
|
|
| |
<[email protected]>. Commit 1 of 2.
|
|
|
ref:cde9a383711a11544ce7e107a78147fb96cc4029
|
