Внести свой вклад в OpenXLA может каждый, и мы ценим вклад каждого. Существует несколько способов внести свой вклад, в том числе:
Отвечаю на вопросы на форумах OpenXLA (openxla-discuss)
Улучшение или расширение документации OpenXLA
Внесение вклада в кодовую базу OpenXLA.
Внесение вклада любым из вышеперечисленных способов в более широкую экосистему библиотек, построенных на OpenXLA.
Проект OpenXLA соответствует рекомендациям сообщества открытого исходного кода Google .
Прежде чем начать
Подпишите лицензионное соглашение для участников проекта.
Вклад в этот проект должен сопровождаться Лицензионным соглашением участника (CLA). Вы (или ваш работодатель) сохраняете авторские права на свой вклад; это просто дает нам разрешение использовать и распространять ваши материалы в рамках проекта.
Если вы или ваш нынешний работодатель уже подписали соглашение об условиях использования Google (даже если это было для другого проекта), вам, вероятно, не нужно делать это снова.
Перейдите по ссылке < https://cla.developers.google.com/ >, чтобы ознакомиться с действующими соглашениями или подписать новое.
Ознакомьтесь с Кодексом поведения.
Данный проект соответствует Кодексу этики Tensorflow .
Процесс внесения вклада
Руководство разработчика
Инструкции по настройке среды разработки для OpenXLA, включая получение кода, его сборку, запуск тестов и отправку изменений, см. в руководстве для разработчиков .
Руководство по внесению вклада
Архитектура компилятора состоит из следующих компонентов.
Проходы оптимизации
Проходы оптимизации выполняют преобразования в HLO для повышения вычислительной эффективности. Эти преобразования варьируются от архитектурно-независимых высокоуровневых улучшений до аппаратных корректировок (например, для графических процессоров NVIDIA).
То, что мы обычно принимаем:
- Проходы, которые демонстрируют обобщенные результаты для различных рабочих нагрузок и явное и значительное положительное влияние на показатели производительности.
Что мы обычно отвергаем:
- Этапы, выполняющие уникальные оптимизации, ориентированные на конкретные модели.
Пропуска Fusion
Fusion — это критически важная оптимизация, которая объединяет несколько операций HLO в одном ядре для уменьшения операций ввода-вывода в памяти и накладных расходов на запуск ядра.
Все этапы слияния следует добавлять только в конвейер слияния, а не до или после него. Это также означает, что предварительно оптимизированный модуль HLO не должен содержать инструкций слияния. Если слияние формируется на раннем этапе конвейера, оно становится препятствием для этапов оптимизации. Если слияние формируется на позднем этапе, мы теряем возможность выбора и настройки бэкэнда для сгенерированного слияния.
Интеграция в пользовательские вызовы, то есть сопоставление пользовательских вызовов с шаблонами, созданными производителями/потребителями, и их переписывание в новые пользовательские вызовы не допускается. В этом случае ее следует заменить соответствующим этапом интеграции.
Горизонтальное масштабирование
Вклад в горизонтальное масштабирование включает оптимизацию HLO, улучшение модели затрат, обновление библиотек и различные модификации инфраструктуры. Ввиду сложности воспроизведения повышения производительности и ограниченной необходимости использования многохостовых конфигураций внутри компании, мы придерживаемся строгих критериев приемки:
Мы отдаем приоритет минимально инвазивным изменениям, сопряженным с низким риском.
То, что мы обычно принимаем:
Обновления библиотек, обрабатывающих взаимодействие между графическими процессорами или между хостами.
Обновления таблицы производительности для новых платформ.
Что мы обычно отвергаем:
HLO — это переписывание кода или внесение изменений во время выполнения, адаптированное к конкретной модели.
Изменения в инфраструктуре, приводящие к появлению новых флагов, техническому долгу или регрессиям.
Бэкенды и автотюнинг
Для бэкендов, предназначенных для невложенных операций, например, пользовательских вызовов и слияний, следует реализовать интерфейс CodegenBackend .
Этот интерфейс необходим для обеспечения оптимального выбора бэкэнда, поскольку он предоставляет методы для включения параметров для заданных инструкций HLO в пространство поиска автотюнера.
// Returns all supported configs for the given HLO instruction.
virtual absl::StatusOr<std::vector<std::unique_ptr<BackendConfig>>>
GetSupportedConfigs(const HloInstruction& instr);
// Returns a default config for the given HLO instruction.
virtual absl::StatusOr<std::unique_ptr<BackendConfig>> GetDefaultConfig(
const HloInstruction& instr);
Среда выполнения
В результате работы конвейера компиляции XLA получается последовательность "thunk", которую можно сериализовать.
Все новые типы thunk должны быть сериализуемыми, то есть GpuCompiler или CpuCompiler должны уметь компилировать программу, сериализовать её, чтобы позже исполнитель XLA мог загрузить и выполнить программу. Это означает, что не должно быть указателей на HloInstruction или на другие части компилятора или StreamExecutor .
стандарты кодекса
Стиль кодирования : Мы следуем руководству по стилю кодирования Google . В частности, ознакомьтесь с руководствами по C/C++ и Python . Весь представленный код должен строго соответствовать этим руководствам по стилю.
Компактные изменения : Мы следуем инженерным практикам Google . В частности, пожалуйста, ознакомьтесь с руководством по написанию компактных изменений . Это значительно ускорит процесс слияния вашего кода, улучшит возможность проверки и снизит вероятность непреднамеренных побочных эффектов изменений. Даже если у вас большое изменение, существует множество стратегий для его разбивки на более мелкие, поэтапные изменения.
Покрытие тестами : Все изменения должны включать соответствующие модульные тесты. Модульные тесты не должны зависеть от конкретных параметров работы оборудования (процессора, видеокарты и т. д.) и должны широко использовать моки и фиктивные объекты для создания детерминированных и целенаправленных тестов. Изменения, направленные на расширение существующего кода, который в настоящее время сложно тестировать, должны вносить соответствующие улучшения в тестируемость.
Все изменения должны включать в заголовок описания соответствующие результаты контрольных показателей, чтобы обеспечить четкое понимание преимуществ.
Если вы сомневаетесь в общепринятых правилах в коде, всегда полезно изучить уже существующий код и постараться следовать шаблонам, уже принятым в OpenXLA.
Процесс проверки
Все материалы, включая материалы, предоставленные участниками проекта, подлежат проверке. Для этого мы используем запросы на слияние (pull requests) в GitHub. Для получения дополнительной информации об использовании запросов на слияние обратитесь к справке GitHub .
Перед проверкой код должен соответствовать всем перечисленным выше стандартам. Эти стандарты обязательны, и крайне важно, чтобы автор кода убедился в их соответствии до запроса на проверку, чтобы обеспечить своевременное принятие изменений.
Все тесты должны пройти успешно . Если вы обнаружите, что какой-либо тест не работает, и проблема не связана с вашей средой сборки или внесенными изменениями, пожалуйста, свяжитесь с разработчиками.
Старайтесь избегать расширения объема работ в процессе проверки. Это ответственность как отправителя, так и рецензента. Если изменение становится слишком масштабным, рассмотрите возможность разбить его на несколько отдельных изменений.
Перед слиянием изменения оно пройдет внутреннее тестирование с использованием кода, разработанного Google и другими производителями оборудования. Это может добавить дополнительные шаги в процесс проверки, если будут обнаружены ошибки во внутренних тестах, которые не обнаружит наша общедоступная система непрерывной интеграции (CI). Сотрудник Google, проверяющий ваше изменение, сообщит о любых ошибках во внутренних тестах и опишет, что необходимо исправить.
Часто задаваемые вопросы (FAQ)
«Эти изменения в инфраструктуре никак не связаны с моими связями с общественностью. Зачем мне это делать?»
В команде XLA нет отдельной команды по инфраструктуре, поэтому разработка вспомогательных библиотек и предотвращение технического долга ложится на плечи всех нас. Мы считаем это неотъемлемой частью процесса внесения изменений в XLA, и от каждого ожидается участие. Как правило, инфраструктуру мы создаём по мере необходимости при написании кода.
Рецензенты XLA могут попросить вас создать некоторую инфраструктуру (или внести существенные изменения в запрос на слияние) вместе с написанным вами запросом на слияние. Эта просьба может показаться излишней или не относящейся к изменениям, которые вы пытаетесь внести. Вероятно, это связано с несоответствием между вашими ожиданиями относительно объема необходимой инфраструктуры и ожиданиями рецензентов.
Несоответствие ожиданий — это нормально! Это ожидаемо, когда вы новичок в проекте (и иногда это случается даже с нами, опытными участниками). Вероятно, проекты, над которыми вы работали раньше, предъявляют другие требования. Это тоже нормально и ожидаемо! Это не значит, что в каком-либо из этих проектов неправильный подход; они просто разные. Мы предлагаем вам рассматривать запросы на инфраструктуру наряду со всеми другими комментариями к отзывам как возможность узнать, чего мы ожидаем от этого проекта.
"Могу ли я ответить на ваш комментарий в одном из будущих пресс-релизов?"
Часто задаваемый вопрос, касающийся запросов на инфраструктуру (или других крупных запросов) в запросах на слияние, заключается в том, нужно ли вносить изменения в исходный запрос на слияние или это можно сделать в качестве последующего шага в будущем запросе на слияние.
В целом, XLA не позволяет авторам запросов на слияние (PR) отвечать на комментарии рецензентов последующими запросами на слияние. Когда рецензент решает, что что-то нужно исправить в данном запросе на слияние, мы, как правило, ожидаем, что авторы исправят это в этом запросе, даже если запрашиваемое изменение является существенным. Этот стандарт применяется как внутри, так и вне Google.
Существует несколько причин, по которым XLA придерживается именно такого подхода.
Доверие: Завоевание доверия рецензента — ключевой компонент. В проекте с открытым исходным кодом участники могут появляться или исчезать по своему желанию. После одобрения запроса на слияние у рецензентов нет возможности гарантировать, что обещанные последующие действия действительно будут выполнены.
Влияние на других разработчиков: Если вы отправили запрос на слияние (PR), затрагивающий определённую часть XLA, велика вероятность, что другие разработчики изучают ту же часть. Если мы примем технический долг в вашем запросе на слияние, то все, кто изучает этот файл, будут затронуты этим долгом до тех пор, пока не будет отправлен последующий запрос.
Затраты времени рецензентов: Откладывание изменения на последующую проверку накладывает дополнительные издержки на наших и без того перегруженных рецензентов. Рецензенты, вероятно, забудут, о чем был первый запрос на изменение, ожидая последующей проверки, что затруднит следующую проверку. Кроме того, рецензентам придется отслеживать ожидаемые последующие проверки, чтобы убедиться, что они действительно состоятся. Если изменение можно внести таким образом, чтобы оно было действительно ортогонально исходному запросу на изменение, так что его мог бы проверить другой рецензент, проблема с затраченными ресурсами будет менее актуальной. По нашему опыту, это случается редко.