aboutsummaryrefslogtreecommitdiffstats
path: root/vendor/golang.org/x/sys/unix/asm_linux_ppc64x.s
diff options
context:
space:
mode:
authorkickbutt <kickbutt@yandex-team.com>2024-02-02 16:23:03 +0300
committerAlexander Smirnov <alex@ydb.tech>2024-02-09 19:17:17 +0300
commitbdaf70f8cc73f9fb1b956cb4cd3a67b7d2b92241 (patch)
treecc32e82ca818a57279144dba4dd2176137dc70b6 /vendor/golang.org/x/sys/unix/asm_linux_ppc64x.s
parenta45d15b0f1c4997c89c4f0cc3f97670d7f19e268 (diff)
downloadydb-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 'vendor/golang.org/x/sys/unix/asm_linux_ppc64x.s')
0 files changed, 0 insertions, 0 deletions