diff options
author | kickbutt <kickbutt@yandex-team.com> | 2024-02-02 16:23:03 +0300 |
---|---|---|
committer | Alexander Smirnov <alex@ydb.tech> | 2024-02-09 19:17:17 +0300 |
commit | bdaf70f8cc73f9fb1b956cb4cd3a67b7d2b92241 (patch) | |
tree | cc32e82ca818a57279144dba4dd2176137dc70b6 /contrib/tools/python3/src/Modules/clinic/_hashopenssl.c.h | |
parent | a45d15b0f1c4997c89c4f0cc3f97670d7f19e268 (diff) | |
download | ydb-bdaf70f8cc73f9fb1b956cb4cd3a67b7d2b92241.tar.gz |
Bump CUDA -> 11.4 and cuDNN -> 8.0.5
~~большой~~ 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
Diffstat (limited to 'contrib/tools/python3/src/Modules/clinic/_hashopenssl.c.h')
0 files changed, 0 insertions, 0 deletions