Xgboost: Hoja de ruta de XGBoost 0.90

ya que vamos a tener cambios rotundos como https://github.com/dmlc/xgboost/pull/4377

¿Debemos subir la versión a 0.9?

@CodingCat Seguro, podemos

seguro,

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

¿Hay una declaración oficial al respecto? Lanzaron 2.2.3 en enero y 2.3.3 en febrero. Nuestro proveedor (MapR) todavía envía 2.3.1.

@alexvorobiev https://github.com/dmlc/xgboost/issues/4350 , puede consultar con @srowen desde databricks

Esta no es una pregunta para Databricks sino para el proyecto Spark. La política predeterminada son las versiones de mantenimiento para las sucursales durante 18 meses: https://spark.apache.org/versioning-policy.html Eso pondría 2.3.x en EOL aproximadamente en julio, por lo que no esperaría más versiones 2.3.x después el del proyecto OSS.

@srowen ¡Gracias!

@srowen @CodingCat @alexvorobiev Analicemos también la posibilidad de admitir Scala 2.12 / 2.13. En este momento, XGBoost4J está compilado para Scala 2.11:
https://github.com/dmlc/xgboost/blob/2c61f02add72cce8f6dc1ba87e016e3c5f0b7ea6/jvm-packages/pom.xml#L38 -L39

Un usuario informó que los archivos JAR XGBoost4J compilados para Scala 2.11 no son binarios compatibles con Scala 2.12.

Sí, 2.11 / 2.12 siguen siendo incompatibles con los binarios y Spark tiene dos distribuciones. Ambos son compatibles con 2.4.x, aunque 2.12 es el valor predeterminado de aquí en adelante en 2.4.x. 3.0 eliminará el soporte de Scala 2.11.

Puede ser simplemente una cuestión de compilar dos versiones en lugar de mucho o cualquier cambio de código. Si encuentra algún error gracioso en 2.12, avíseme porque miré muchos de estos problemas al actualizar Spark.

2.13 todavía no es GA y creo que será un cambio menor de 2.12-> 2.13 que 2.11-> 2.12 (la gran diferencia aquí es una representación totalmente diferente de lambdas).

@ hcho3 ¿Supongo que querías etiquetar a @alexvorobiev?

@alexeygrigorev Vaya, lo siento.

el único problema es que necesitamos introducir un cambio radical en el nombre del artefacto de xgboost en maven, xgboost4j-spark => xgboost4j-spark_2.11 / xgboost4j-spark_2.12, como spark https://mvnrepository.com/artifact/ org.apache.spark / spark-core y debemos verificar si tenemos alguna dependencia transitoria en 2.11 (creo que no)

Hola, @srowen though 2.12 is the default from here on in 2.4.x , revisé branch-2.4 pom.xml, si no especificas el perfil scala-2.12, aún obtienes una compilación 2.11, ¿no?

Puede elegir admitir solo 2.12 en 0.9x, y luego no tiene que agregar el sufijo al nombre del artefacto. Si admite ambos, sí, realmente querrá cambiar el nombre del artefacto y tener las versiones _2.11 y _2.12.

Sí, la compilación predeterminada de Spark 2.4.x será para 2.11; -Pscala-2.12 obtiene la compilación 2.12.

gracias, me mantendría conservador al admitir 2.12 al menos para la próxima versión

que yo sepa, la mayoría de los usuarios de Spark todavía usan 2.11, ya que están acostumbrados a seguir versiones anteriores de Spark

Es posible que no tenga ancho de banda para pasar por todas las pruebas que tengo para introducir el soporte 2.12

Elegiría admitir 2.12 + 2.11 o 2.12 en la versión 1.0 ...

@ hcho3 FYI, acabo de eliminar el soporte de matriz densa de la hoja de ruta dado el ancho de banda limitado

@ hcho3 ¿Podrías echar un vistazo a https://github.com/dmlc/dmlc-core/pull/514 cuando el tiempo lo permita? Podría valer la pena fusionarse antes de que llegue el próximo lanzamiento.

@trivialfis Lo mirará

@CodingCat Creo que deberíamos retrasar la fecha de lanzamiento, ya que Spark 2.4.1 y 2.4.2 tienen problemas. ¿Qué piensas?

@srowen ¿Sabes cuándo

Creo que está bien tener un ligero retraso

Bien, esperemos hasta que Spark 2.4.3 esté disponible

¿Habría la última versión 0.83 para Spark 2.3.x?

@CodingCat ¿

Sin embargo, un problema es la experiencia del usuario con el manejo de valores perdidos. Tal vez obligar a todos a usar Spark 2.4.x evitará que se equivoquen con los valores faltantes (el problema que motivó # 4349)

@ hcho3 Estoy un poco preocupado por la inconsistencia de diferentes versiones en la disponibilidad de pkgs.

Puedo imaginar preguntas como 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?

Sugeriría que tengamos una versión de mantenimiento completa en la rama 0.8x o nada

@CodingCat Entendido . Haremos lanzamientos consistentes para todos los paquetes. Entonces, ¿cuál es tu opinión sobre la versión 0.83? ¿Deberíamos hacerlo?

@CodingCat En realidad, esto creará trabajo para otros mantenedores, tendremos que preguntarles primero

La respuesta corta desde un punto de vista personal es sí en teoría , pero podría ser más que cortar justo antes de un compromiso (como dijiste, también creará trabajo para otros) (pero estoy un poco indeciso en hacer esto debido a las limitaciones recursos en la comunidad ...)

aquí están mis dos centavos sobre cómo deberíamos pensar en la versión de mantenimiento como 0.8x

1. la razón para tener una versión de mantenimiento es para traer correcciones de errores críticos, como https://github.com/dmlc/xgboost/commit/2d875ec0197d5a83e7d585daf472b8201aa97c51 y https://github.com/dmlc/xgboost/commit/995698b0cb2ae75f03166

2. Por otro lado, para hacer que la comunidad sea sostenible, además de agotar a todos los comprometidos, debemos dejar de apoyar la versión anterior periódicamente.

3. las innovaciones y mejoras deben llevarse a los usuarios a través de un lanzamiento de funciones (saltar de 0.8 a 0.9)

Si decidimos pasar a 0.83, también debemos recopilar opiniones de @RAMitchell @trivialfis y usar su juez para ver si tenemos correcciones de errores importantes (más sobre la corrección) que notan.

y luego crea una rama 0.83 basada en 0.82 para seleccionar confirmaciones ... mucho trabajo en realidad

Si lo entiendo correctamente, 0.9 no admitirá versiones anteriores de Spark, de ahí la propuesta de admitir una versión 0.83 y 0.9 para continuar con la compatibilidad con versiones anteriores de Spark al tiempo que se incluyen correcciones de errores.

Generalmente estoy en contra de todo lo que utilice el tiempo del desarrollador. ¿No estamos ya lo suficientemente ocupados? Sin embargo, veo algo de valor en tener una versión estable.

@CodingCat ¿Hay alguna forma de incorporar correcciones de errores (2d875ec y 995698b) sin actualizar a Spark 2.4.x?

Si hacer lanzamientos de mantenimiento es algo más que cortar ramas (por ejemplo, es necesario seleccionar con precisión), preferiría no comprometerme de ese modo.

Generalmente estoy en contra de todo lo que utilice el tiempo del desarrollador. ¿No estamos ya lo suficientemente ocupados?

Estoy de acuerdo.

@CodingCat ¿Hay alguna forma de incorporar correcciones de errores (2d875ec y 995698b) sin actualizar a Spark 2.4.x?

@ hcho3 desafortunadamente no, debido a los cambios importantes en la biblioteca dependiente de Spark, solo podemos compilar y ejecutar xgboost con la versión consistente de Spark

si en el futuro, estamos interesados ​​en la versión de mantenimiento, el flujo de trabajo (después de la versión 0.9)

1. Backport necesario arreglo a 0.9-branch

2. Lanzamiento 0.9x cada, digamos, 2 meses, o desencadenado por una corrección de error importante

3. las características principales y todas las correcciones retroportadas a 0.9x deberían estar disponibles en master

4. cuando se lanza 1.0, corta una rama del maestro ...

pero de nuevo, una vez que tengamos una gran refactorización en master y queramos volver a corregir a 0.9 después de eso ... toneladas de trabajo

@CodingCat Dado el tamaño actual de la comunidad de desarrolladores, apuntemos a las versiones de mantenimiento.

@tovbinm Lo siento, no creo que podamos hacer la versión 0.83, debido a la falta de ancho de banda. ¿Le resulta factible actualizar a Spark 2.4.3?

Eso es lamentable. No, no a corto plazo. Todavía estamos en 2.3.x.

¿Cuál es el compromiso que actualizó Spark de 2.3 a 2.4? Quizás podamos cortar allí (si está por encima de 0,82, por supuesto).

@tovbinm Puede compilar XGBoost con la confirmación 711397d6452d596d7acbb68f1052ffebdee3e3af para usar Spark 2.3.x.

Excelente. Entonces, ¿por qué no hacer un comunicado público de ese compromiso?

Como dijo @CodingCat , las versiones de mantenimiento no son simplemente una cuestión de recortar antes de un compromiso. Además, hacer comunicados públicos son promesas implícitas de apoyo. No creo que los mantenedores estén dispuestos a respaldar dos nuevos lanzamientos en este momento.

Me referiré a

Memoria externa con predictor de GPU: esto significaría que el código no fallaría con what (): std :: bad_alloc: out of memory? (es decir, ¿cambiar temporalmente a RAM?)

Problema relacionado, supongo que https://github.com/dmlc/xgboost/issues/4184 : esto fue principalmente en ráfagas temporales de memoria, el proceso de adaptación nunca requiere tanta memoria

@hlbkin Deberá habilitar explícitamente la memoria externa, de acuerdo con https://xgboost.readthedocs.io/en/latest/tutorials/external_memory.html

Supongo que no es posible cambiar de otra manera sin un aumento de la versión principal (es decir, 1.0), pero cuando lo haga, ¿podría considerar la posibilidad de admitir números de versión PEP 440 conformes (iexyz), y preferiblemente versiones semánticas? La interpretación estándar de 0.90 (en lugar de 0.9.0) sería que es el lanzamiento menor número 90 de la serie de la versión principal 0.x (es decir, lanzamiento preestable), y no es más significativa que 0.83. Además, esto lo restringe a un máximo de versiones de 9 puntos por versión menor y crea dificultades para que algunas herramientas (y personas) interpreten. ¡Gracias!

+1

@ CAM-Gerlach Lo consideraremos cuando lancemos 1.0. Por otro lado, no queremos apresurarnos a la versión 1.0. Queremos que 1.0 sea un hito de algún tipo, en términos de características, estabilidad y rendimiento.

Gracias por la explicación, @ hcho3 .

Probablemente desee asegurarse de establecer el argumento python_requires en '>=3.5' en setup() para asegurarse de que los usuarios con Python 2 no se actualicen accidentalmente a una versión incompatible.

@ hcho3 La memoria externa no está disponible con algoritmos de GPU

@hlbkin Tienes razón. La memoria externa estará disponible solo para el predictor de GPU, no para el entrenamiento.

@rongou @sriramch ¿Tengo razón en que el entrenamiento de GPU no está disponible con memoria externa?

@ hcho3 sí, tienes razón. Estamos trabajando en ello. los cambios están aquí si está interesado. Tendré que sincronizar este cambio con el maestro y escribir algunas pruebas.

@sriramch ¡Impresionante! ¿Deberíamos intentar incluir el entrenamiento de la memoria externa en la versión 0.90, o deberíamos volver a él después de la 0.90?

solo mis dos centavos, reservemos un poco para compactar muchas características nuevas en 0.x (de manera apresurada) y consideremos lo que se pondrá en 1.0 como una versión de hito

@CodingCat Estoy de acuerdo. Para su información, eliminé el objetivo personalizado distribuido de la hoja de ruta 0.90, ya que hubo un desacuerdo sustancial en el n. ° 4280. Lo consideraremos nuevamente después de 0.90.

@sriramch Consideremos el entrenamiento de la memoria externa después de la versión 0.90. Muchas gracias por tu arduo trabajo.

Este podría ser un buen momento para lanzar los binarios de cuda 9.0 en lugar de 8.0. Creo que 9.0 ahora será lo suficientemente compatible con la versión del controlador de los usuarios. Además, los binarios 9.0 no necesitarán ser compilados JIT para las arquitecturas más nuevas de Volta.

@ hcho3 ¿estamos listos para

Casi. Creo que el # 4438 debería fusionarse.

Todo bien ahora. Seguiré adelante y comenzaré a trabajar en la próxima versión. ETA: 16 de mayo de 2019

• [x] Requiere Python 3 en setup.py
• [x] Cambiar CI para construir ruedas CUDA 9.0 (# 4459)
• [x] Corregir la compilación de Windows (# 4463)
• [x] Configure un CI mínimo viable para Windows con GPU (# 4463)

@RAMitchell ¿Deberíamos usar CUDA 9.0 o 9.2 para los lanzamientos de ruedas?

Usemos 9.2 ya que ya está configurado en CI. El peligro es que necesitamos controladores de Nvidia que sean demasiado nuevos. Como referencia, aquí está la tabla que muestra la correspondencia entre la versión cuda y los controladores: https://docs.nvidia.com/deploy/cuda-compatibility/index.html#binary -compatibility__table-toolkit-driver

Hasta donde yo sé, esto no debería afectar a los algoritmos de la CPU de ninguna manera. Si los usuarios comienzan a informar problemas, podemos abordar esto en el futuro con mejores mensajes de error sobre la compatibilidad del controlador.

Hmm, en ese caso, puedo intentar rebajar la calificación de uno de los trabajadores de CI a CUDA 9.0. Dado que usamos contenedores Docker de manera extensiva, no debería ser demasiado difícil.

Voy a preparar la versión 0.90 ahora. Mi objetivo es tener la nota de lanzamiento completa para fines de esta semana.

Cerrado por # 4475