Xgboost: Дорожная карта XGBoost 0.90

поскольку у нас будут критические изменения, такие как https://github.com/dmlc/xgboost/pull/4349 и https://github.com/dmlc/xgboost/pull/4377

поднять версию до 0.9?

@CodingCat Конечно, мы можем критическое изменение будет значительным. Не могли бы вы сделать мне одолжение и описать в одном абзаце, зачем нужен # 4349?

Конечно,

* Spark 2.3 is reaching its end-of-life in a few months

Есть ли официальное заявление по этому поводу? Они выпустили 2.2.3 в январе и 2.3.3 в феврале. Наш поставщик (MapR) по-прежнему поставляет 2.3.1.

@alexvorobiev https://github.com/dmlc/xgboost/issues/4350 , вы можете проверить с помощью @srowen из databricks

Это вопрос не к Databricks, а к проекту Spark. Политика по умолчанию - выпуски обслуживания для веток на 18 месяцев: https://spark.apache.org/versioning-policy.html. Это поставит 2.3.x в EOL примерно в июле, поэтому не стоит ожидать больше выпусков 2.3.x после что из проекта OSS.

@srowen Спасибо!

@srowen @CodingCat @alexvorobiev Давайте также обсудим возможность поддержки Scala 2.12 / 2.13. Прямо сейчас XGBoost4J скомпилирован для Scala 2.11:
https://github.com/dmlc/xgboost/blob/2c61f02add72cce8f6dc1ba87e016e3c5f0b7ea6/jvm-packages/pom.xml#L38 -L39

Пользователь сообщил, что файлы JAR XGBoost4J, скомпилированные для Scala 2.11, несовместимы с двоичным кодом Scala 2.12.

Да, 2.11 / 2.12 по-прежнему несовместимы с двоичным кодом, а у Spark есть два дистрибутива. Оба поддерживаются в 2.4.x, хотя с этого момента в 2.4.x по умолчанию используется 2.12. 3.0 откажется от поддержки Scala 2.11.

Это может быть просто вопрос компиляции двух версий, а не большого или какого-либо изменения кода. Если вы столкнетесь с какими-либо забавными ошибками в 2.12, дайте мне знать, потому что я столкнулся с множеством этих проблем при обновлении Spark.

2.13 по-прежнему не является GA, и думаю, что это будет меньшее изменение с 2.12-> 2.13, чем с 2.11-> 2.12 (большая разница здесь в совершенно другом представлении лямбда-выражений).

@ hcho3 Полагаю, вы хотели отметить @alexvorobiev?

@alexeygrigorev Ой, извините за это.

единственная проблема заключается в том, что нам нужно внести критическое изменение в имя артефакта xgboost в maven, xgboost4j-spark => xgboost4j-spark_2.11 / xgboost4j-spark_2.12, например Spark https://mvnrepository.com/artifact/ org.apache.spark / spark-core, и нам нужно дважды проверить, есть ли у нас временная зависимость от 2.11 (я думаю, что нет)

Привет, @srowen though 2.12 is the default from here on in 2.4.x , я проверил branch-2.4 pom.xml, если вы не укажете профиль scala-2.12, вы все равно получите сборку 2.11, нет?

Вы можете выбрать поддержку только 2.12 в 0.9x, и тогда вам не нужно добавлять суффикс к имени артефакта. Если вы поддерживаете оба варианта, то, к сожалению, вы действительно захотите изменить имя артефакта и иметь версии _2.11 и _2.12.

Да, сборка Spark 2.4.x по умолчанию будет для 2.11; -Pscala-2.12 получает сборку 2.12.

спасибо, я буду консервативен в поддержке 2.12 по крайней мере для следующей версии

Насколько мне известно, большинство пользователей Spark все еще используют 2.11, поскольку они привыкли следовать предыдущим версиям Spark.

У меня может не хватить пропускной способности для прохождения всех тестов, которые у меня есть для внедрения поддержки 2.12.

Я бы выбрал поддержку 2.12 + 2.11 или 2.12 в версии 1.0 ...

@ hcho3 FYI, я просто удалил поддержку плотной матрицы из дорожной карты, учитывая ограниченную пропускную способность

@ hcho3 Не могли бы вы взглянуть на https://github.com/dmlc/dmlc-core/pull/514, когда позволит время? Возможно, стоит слить до следующего релиза.

@trivialfis Посмотрим на это

@CodingCat Я думаю, нам следует отодвинуть дату выпуска, поскольку у Spark 2.4.1 и 2.4.2 есть проблемы. Что вы думаете?

@srowen Вы знаете, когда выйдет Spark 2.4.3?

Я думаю, что небольшая задержка - это нормально

Ладно, подождем пока выйдет Spark 2.4.3

Будет ли последний выпуск 0.83 для Spark 2.3.x?

@CodingCat Что, если мы сделаем два параллельных выпуска 0.83 и 0.90, где 0.83 включает все коммиты непосредственно перед # 4377? Версия 0.83 будет выпущена только как пакеты JVM, а пакеты Python и R получат 0.90. Для меня это больше не будет работать, так как мне все равно нужно написать примечание к выпуску 0.90.

Одна из проблем - это удобство работы пользователя с обработкой пропущенных значений. Возможно, принуждение всех к использованию Spark 2.4.x предотвратит их ошибку с пропущенными значениями (проблема, которая послужила причиной # 4349)

@ hcho3 Меня немного беспокоит несоответствие разных версий доступности пакетов pkgs.

Я могу представить себе такие вопросы, как hey, I find 0.83 in maven so I upgrade our Spark pkg, but I cannot use 0.83 in notebook when attempting to explore my new model setup with a small amount of data with python pkg?

Я бы посоветовал нам либо выпустить полный отладочный выпуск в ветке 0.8x, либо ничего

@CodingCat Понял. Мы сделаем последовательные выпуски для всех пакетов. Что вы думаете о выпуске 0.83? Стоит ли нам это делать?

@CodingCat На самом деле, это создаст работу для других сопровождающих, нам нужно сначала спросить их

короткий ответ с личной точки зрения - да в теории , но это может быть больше, чем сокращение прямо перед фиксацией (как вы сказали, это создаст работу и для других) (но я не решаюсь сделать это из-за ограниченного ресурсы в сообществе ...)

вот мои 2 цента о том, как мы должны думать о выпуске обслуживания, таком как 0.8x

1. Причина, по которой выпуск обслуживания состоит в том, чтобы внести критические исправления ошибок, такие как https://github.com/dmlc/xgboost/commit/2d875ec0197d5a83e7d585daf472b8201aa97c51 и https://github.com/dmlc/xgboost/commit/99569a08b

2. с другой стороны, чтобы сообщество было устойчивым, кроме выгорания всех коммиттеров, мы должны периодически отказываться от поддержки предыдущей версии.

3. нововведения и улучшения должны быть доведены до пользователей через выпуск функции (переход с 0.8 на 0.9)

если мы решим перейти на 0.83, нам нужно будет собрать мнения @RAMitchell @trivialfis и использовать их судью, чтобы узнать, есть ли у нас важные (больше о правильности) исправления ошибок, которые они заметили

а затем создайте ветку 0.83 на основе 0.82, чтобы выбрать коммиты ... на самом деле много работы

Если я правильно понимаю, 0.9 не будет поддерживать старые версии Spark, отсюда и предложение о поддержке версии 0.83, а также 0.9, чтобы продолжить поддержку более старых версий Spark, включая исправления ошибок?

Обычно я против всего, что требует времени разработчика. Разве мы уже не достаточно заняты? Однако я вижу некоторую ценность в стабильной версии.

@CodingCat Есть ли способ включить исправления ошибок (2d875ec и 995698b) без обновления до Spark 2.4.x?

Если создание обновленных версий - это больше, чем просто обрезка ветвей (например, нужно выбирать вишню), я бы предпочел не брать на себя такие обязательства.

Обычно я против всего, что требует времени разработчика. Разве мы уже не достаточно заняты?

Я согласен.

@CodingCat Есть ли способ включить исправления ошибок (2d875ec и 995698b) без обновления до Spark 2.4.x?

@ hcho3, к сожалению, нет, из-за

если в будущем нас интересует отладочный выпуск, рабочий процесс (после выпуска 0.9)

1. бэкпорт необходимое исправление в 0.9-ветку

2. выпуск 0.9x каждые, скажем, 2 месяца, или запускается исправлением важной ошибки

3. основные функции и все исправления, перенесенные на версию 0.9x, должны быть доступны в мастере

4. в выпуске 1.0 вырезать ветку от мастера ......

но опять же, как только у нас будет большой рефакторинг в master и после этого мы хотим вернуться к исправлению 0.9 ... тонны работы

@CodingCat Учитывая текущий размер сообщества разработчиков, давайте начнем с техобслуживания.

@tovbinm Извините, я не думаю, что мы сможем выпустить выпуск 0.83 из-за недостаточной пропускной способности. Возможно ли вам перейти на Spark 2.4.3?

Это прискорбно. Нет, не в краткосрочной перспективе. Мы все еще на 2.3.x.

Что за коммит обновил Spark с 2.3 до 2.4? Возможно, мы сможем сократить его (если, конечно, выше 0,82).

@tovbinm Вы можете собрать XGBoost с помощью commit 711397d6452d596d7acbb68f1052ffebdee3e3af, чтобы использовать Spark 2.3.x.

Большой. Так почему бы не сделать публичный релиз этого коммита?

Как сказал @CodingCat ,

Я отвечу на @CodingCat, чтобы узнать, следует ли нам выпускать релиз от 711397d6452d596d7acbb68f1052ffebdee3e3af.

Внешняя память с предсказателем графического процессора - это означало бы, что код больше не будет сбой с what (): std :: bad_alloc: out of memory? (то есть временно подкачать в RAM?)

связанная проблема, я думаю, https://github.com/dmlc/xgboost/issues/4184 - это было в основном из-за временных всплесков памяти, сам процесс настройки никогда не требовал столько памяти

@hlbkin Вам необходимо явно включить внешнюю память, согласно https://xgboost.readthedocs.io/en/latest/tutorials/external_memory.html.

Я предполагаю, что невозможно переключиться иначе без увеличения основной версии (например, 1.0), но когда вы это сделаете, не могли бы вы рассмотреть возможность поддержки соответствующих номеров версий PEP 440 (iexyz) и, предпочтительно, семантического управления версиями? Стандартная интерпретация 0.90 (а не 0.9.0) будет заключаться в том, что это 90-й второстепенный выпуск из серии основной версии 0.x (т.е. предварительная стабильная версия), и он не более значим, чем 0.83. Более того, это ограничивает вас максимум 9-ю выпусками на вспомогательную версию и создает трудности для интерпретации некоторыми инструментами (и людьми). Спасибо!

+1

@ CAM-Gerlach Мы учтем это при выпуске 1.0. С другой стороны, мы не хотим спешить с версией 1.0. Мы хотим, чтобы версия 1.0 стала своего рода вехой с точки зрения возможностей, стабильности и производительности.

Спасибо за объяснение, @ hcho3 .

Вероятно, вы захотите убедиться, что вы установили аргумент python_requires равным '>=3.5' в setup() чтобы гарантировать, что пользователи с Python 2 не будут случайно обновлены до несовместимой версии.

@ hcho3 Внешняя память недоступна с алгоритмами графического процессора

@hlbkin Вы правы. Внешняя память будет доступна только для предсказателя графического процессора, но не для обучения.

@rongou @sriramch Я правильно понимаю, что обучение графическому процессору недоступно с внешней памятью?

@ hcho3 да ты прав. мы работаем над этим. изменения здесь, если вам интересно. мне придется синхронизировать это изменение с мастером и написать несколько тестов.

@sriramch Замечательно ! Стоит ли нам стремиться включить тренировку внешней памяти в версию 0.90 или мы должны вернуться к ней после 0.90?

только мои два цента, давайте оставим немного на сжатие многих новых функций в 0.x (в спешке) и рассмотрим, что должно быть добавлено в 1.0 в качестве промежуточной версии

@CodingCat Я согласен. К вашему сведению, я удалил распределенную настраиваемую цель из дорожной карты 0.90, поскольку в # 4280 были существенные разногласия. Мы рассмотрим его снова после 0.90.

@sriramch Рассмотрим тренировку внешней памяти после релиза 0.90. Большое спасибо за вашу тяжелую работу.

Возможно, сейчас самое время выпустить двоичные файлы cuda 9.0 вместо 8.0. Я думаю, что 9.0 теперь будет в достаточной мере поддерживаться версией драйверов пользователей. Кроме того, двоичные файлы 9.0 не нужно будет компилировать JIT для новых архитектур Volta.

@ hcho3 мы готовы к работе?

Почти. Думаю # 4438 нужно объединить.

Теперь все хорошо. Я продолжу и начну работу над следующим выпуском. Расчетное время прибытия: 16 мая 2019 г.

• [x] Требовать Python 3 в setup.py
• [x] Измените CI для сборки колес CUDA 9.0 (# 4459)
• [x] Исправить компиляцию Windows (# 4463)
• [x] Настройка минимально жизнеспособного CI для Windows с графическим процессором (# 4463)

@RAMitchell Должны ли мы использовать CUDA 9.0 или 9.2 для релизов колес?

Давайте использовать 9.2, поскольку он уже настроен на CI. Опасность в том, что нам требуются слишком новые драйверы Nvidia. Для справки, вот таблица, показывающая соответствие между версией cuda и драйверами: https://docs.nvidia.com/deploy/cuda-compatibility/index.html#binary -compatibility__table-toolkit-driver

Насколько я знаю, это никоим образом не должно влиять на алгоритмы процессора. Если пользователи начнут сообщать о проблемах, мы сможем решить эту проблему в будущем с помощью улучшенных сообщений об ошибках совместимости драйверов.

Хм, в этом случае я могу попробовать понизить оценку одного из CI worker до CUDA 9.0. Поскольку мы широко используем контейнеры Docker, это не должно быть слишком сложно.

Сейчас я собираюсь подготовить релиз 0.90. Моя цель - завершить работу над выпуском к концу этой недели.

Закрыл # 4475