Xgboost: Feuille de route XGBoost 0.90

car nous allons avoir des changements de rupture comme https://github.com/dmlc/xgboost/pull/4349 et https://github.com/dmlc/xgboost/pull/4377

allons-nous passer la version à 0.9?

@CodingCat Bien sûr, nous pouvons

Bien sur,

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

Y a-t-il une déclaration officielle à ce sujet? Ils ont sorti 2.2.3 en janvier et 2.3.3 en février. Notre fournisseur (MapR) livre toujours 2.3.1.

@alexvorobiev https://github.com/dmlc/xgboost/issues/4350 , vous pouvez vérifier avec @srowen à partir de databricks

Ce n'est pas une question pour Databricks mais pour le projet Spark. La politique par défaut est des versions de maintenance pour les branches pendant 18 mois : https://spark.apache.org/versioning-policy.html Cela mettrait 2.3.x en fin de vie vers juillet, donc ne vous attendez pas à plus de versions 2.3.x après celui du projet OSS.

@srowen Merci !

@srowen @CodingCat @alexvorobiev Discutons également la possibilité de soutenir Scala 2,12 / 2,13. À l'heure actuelle, XGBoost4J est compilé pour Scala 2.11 :
https://github.com/dmlc/xgboost/blob/2c61f02add72cce8f6dc1ba87e016e3c5f0b7ea6/jvm-packages/pom.xml#L38 -L39

Un utilisateur a signalé que les fichiers JAR XGBoost4J compilés pour Scala 2.11 ne sont pas compatibles binairement avec Scala 2.12.

Oui, 2.11 / 2.12 sont toujours binairement incompatibles, et Spark a deux distributions. Les deux sont pris en charge dans 2.4.x bien que 2.12 soit la valeur par défaut à partir de maintenant dans 2.4.x. 3.0 supprimera la prise en charge de Scala 2.11.

Il peut s'agir simplement de compiler deux versions plutôt que de modifier beaucoup ou de modifier le code. Si vous rencontrez des erreurs amusantes dans la version 2.12, faites-le moi savoir car j'ai examiné beaucoup de ces problèmes lors de la mise à jour de Spark.

2.13 n'est toujours pas GA et je pense que ce sera un changement plus petit de 2.12->2.13 que 2.11->2.12 (la grande différence ici est une représentation totalement différente des lambdas).

@hcho3 Je suppose que vous vouliez taguer @alexvorobiev ?

@alexeygrigorev Oups, désolé pour ça.

le seul problème est que nous devons introduire un changement radical dans le nom de l'artefact de xgboost dans maven, xgboost4j-spark => xgboost4j-spark_2.11/xgboost4j-spark_2.12, comme spark https://mvnrepository.com/artifact/ org.apache.spark/spark-core et nous devons vérifier si nous avons une dépendance transitoire sur 2.11 (je pense que non)

Salut, @srowen though 2.12 is the default from here on in 2.4.x , j'ai vérifié branch-2.4 pom.xml, si vous ne spécifiez pas le profil scala-2.12, vous obtenez toujours une version 2.11, non?

Vous pouvez choisir de ne prendre en charge que 2.12 en 0.9x, sans avoir à suffixer le nom de l'artefact. Si vous prenez en charge les deux, oui, vous voudriez vraiment changer le nom de l'artefact malheureusement et avoir les versions _2.11 et _2.12.

Oui, la version par défaut de Spark 2.4.x sera pour 2.11 ; -Pscala-2.12 obtient la version 2.12.

merci, je resterais conservateur en soutenant la 2.12 au moins pour la version à venir

pour autant que je sache, la plupart des utilisateurs de Spark utilisent toujours 2.11 car ils sont habitués à suivre les versions précédentes de Spark

Je n'ai peut-être pas de bande passante pour passer tous les tests que j'ai pour introduire le support 2.12

Je choisirais de prendre en charge 2.12 + 2.11 ou 2.12 dans la version 1.0...

@hcho3 Pour info , je viens de supprimer le support de la matrice dense de la feuille de route étant donné la bande passante limitée

@hcho3 Pourriez-vous jeter un œil à https://github.com/dmlc/dmlc-core/pull/514 quand le temps le permet ? Cela pourrait valoir la peine de fusionner avant la prochaine version.

@trivialfis va le regarder

@CodingCat Je pense que nous devrions repousser la date de sortie, car Spark 2.4.1 et 2.4.2 ont des problèmes. Qu'est-ce que tu penses?

@srowen Savez-vous quand Spark 2.4.3 sortira ?

Je pense que c'est bien d'avoir un léger retard

Bon, attendons que Spark 2.4.3 soit sorti

Y aurait-il la dernière version 0.83 pour Spark 2.3.x ?

@CodingCat Et si nous faisions deux versions parallèles 0.83 et 0.90, où 0.83 inclut tous les commits juste avant #4377 ? La version 0.83 ne serait publiée que sous forme de packages JVM, et les packages Python et R obtiendraient 0.90. Ce ne sera plus du travail pour moi, puisque je dois de toute façon rédiger une note de version pour la 0.90.

Un problème est cependant l'expérience de l'utilisateur avec la gestion des valeurs manquantes. Peut-être que forcer tout le monde à utiliser Spark 2.4.x les empêchera de se tromper avec des valeurs manquantes (le problème qui a motivé le #4349)

@hcho3 Je suis un peu préoccupé par l'incohérence des différentes versions dans la disponibilité des pkgs.

Je peux imaginer des questions comme 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?

Je suggérerais que nous ayons une version de maintenance complète sur la branche 0.8x ou rien

@CodingCat Compris . Nous ferons des versions cohérentes pour tous les packages. Que pensez-vous de la version 0.83 alors ? Doit-on le faire ?

@CodingCat En fait, cela créera du travail pour d'autres responsables, nous devrons d'abord leur demander

la réponse courte d'un point de vue personnel est oui en théorie , mais cela pourrait être plus que couper juste avant un commit (comme vous l'avez dit, cela créera également du travail pour les autres) (mais j'ai un peu hésité à le faire à cause du nombre limité ressources dans la communauté...)

voici mes 2 cents sur la façon dont nous devrions penser à une version de maintenance comme 0.8x

1. la raison d'avoir une version de maintenance est d'apporter des corrections de bogues critiques, comme https://github.com/dmlc/xgboost/commit/2d875ec0197d5a83e7d585daf472b8201aa97c51 et https://github.com/dmlc/xgboost/commit/995698b0cb1daab05f06302d

2. d'un autre côté, pour rendre la communauté durable autre que de brûler tous les commiters, nous devrions abandonner périodiquement le support de la version précédente

3. les innovations et améliorations devraient être apportées aux utilisateurs via une version de fonctionnalité (passer de 0.8 à 0.9)

si nous décidons d'aller à 0,83, nous devons également recueillir les opinions de @RAMitchell @trivialfis et utiliser leur juge pour voir si nous avons des corrections de bogues importantes (plus sur l'exactitude) qui sont remarquées par eux

puis créez une branche 0.83 basée sur 0.82 pour choisir les commits ...... beaucoup de travail en fait

Si je comprends bien, la 0.9 ne prendra pas en charge les anciennes versions de Spark, d'où la proposition de prendre en charge une version 0.83 ainsi que la 0.9 pour continuer à prendre en charge les anciennes versions de Spark tout en incluant des corrections de bugs ?

En général, je suis contre tout ce qui utilise du temps de développeur. Ne sommes-nous pas déjà assez occupés ? Je vois cependant une certaine valeur à avoir une version stable.

@CodingCat Existe-t-il un moyen d'incorporer des corrections de bogues (2d875ec et 995698b) sans passer à Spark 2.4.x ?

Si faire des versions de maintenance ne se limite pas à couper des branches (par exemple, besoin de faire une sélection), je préférerais ne pas prendre un tel engagement.

En général, je suis contre tout ce qui utilise du temps de développeur. Ne sommes-nous pas déjà assez occupés ?

Je suis d'accord.

@CodingCat Existe-t-il un moyen d'incorporer des corrections de bogues (2d875ec et 995698b) sans passer à Spark 2.4.x ?

@hcho3 malheureusement non, en raison des modifications importantes apportées à la bibliothèque par Spark, nous ne pouvons compiler et exécuter xgboost qu'avec la version cohérente de spark

si à l'avenir, nous sommes intéressés par la version de maintenance, le workflow (après la version 0.9)

1. backport correctif nécessaire à la branche 0.9

2. version 0.9x tous les, disons, 2 mois, ou déclenchée par une correction de bogue important

3. les principales fonctionnalités et tous les correctifs rétroportés vers la 0.9x devraient être disponibles dans le master

4. lors de la version 1.0, couper une branche du master......

mais encore une fois, une fois que nous avons un gros refactor dans le master et que nous voulons rétroporter le correctif à 0.9 après cela ... des tonnes de travail

@CodingCat Compte tenu de la taille actuelle de la communauté des développeurs, passons aux versions de maintenance.

@tovbinm Désolé, je ne pense pas que nous pourrons faire la version 0.83, en raison du manque de bande passante. La mise à niveau vers Spark 2.4.3 est-elle faisable pour vous ?

C'est malheureux. Non, pas à court terme. Nous sommes toujours sur 2.3.x.

Quel est le commit qui a mis à niveau Spark de 2.3 à 2.4 ? Peut-être pouvons-nous couper là-bas (si c'est au-dessus de 0,82 bien sûr).

@tovbinm Vous pouvez construire XGBoost avec commit 711397d6452d596d7acbb68f1052ffebdee3e3af pour utiliser Spark 2.3.x.

Super. Alors pourquoi ne pas publier ce commit ?

Comme l'a dit @CodingCat , les versions de maintenance ne consistent pas simplement à couper avant un commit. De plus, faire des sorties publiques est une promesse implicite de soutien. Je ne pense pas que les responsables soient prêts à prendre en charge deux nouvelles versions pour le moment.

Je m'en remettrai à @CodingCat pour savoir si nous devrions publier une version de 711397d6452d596d7acbb68f1052ffebdee3e3af

Mémoire externe avec prédicteur GPU - cela signifierait que le code ne planterait pas avec quoi () : std :: bad_alloc : plus de mémoire ? (c'est-à-dire échanger temporairement dans la RAM ?)

problème connexe, je suppose que https://github.com/dmlc/xgboost/issues/4184 - c'était principalement sur les rafales temporelles de mémoire, le processus d'ajustement lui-même ne nécessite jamais autant de mémoire

@hlbkin Vous devrez activer explicitement la mémoire externe, selon https://xgboost.readthedocs.io/en/latest/tutorials/external_memory.html

Je suppose qu'il n'est pas possible de changer autrement sans une modification majeure de la version (c'est-à-dire 1.0), mais lorsque vous le faites, pourriez-vous envisager de prendre en charge les numéros de version PEP 440 conformes (iexyz), et de préférence le contrôle de version sémantique ? L'interprétation standard de 0.90 (plutôt que 0.9.0) serait qu'il s'agit de la 90ème version mineure de la série majeure version 0.x (c'est-à-dire version pré-stable) et n'est pas plus significative que 0,83. De plus, cela vous limite à un maximum de 9 versions ponctuelles par version mineure et crée des difficultés pour certains outils (et personnes) à interpréter. Merci!

+1

@CAM-Gerlach Nous en tiendrons compte lors de la sortie de la version 1.0. D'un autre côté, nous ne voulons pas nous précipiter vers 1.0. Nous voulons que la 1.0 soit une étape importante en termes de fonctionnalités, de stabilité et de performances.

Merci pour l'explication, @hcho3 .

Vous voulez probablement vous assurer de définir l'argument python_requires sur '>=3.5' dans setup() pour vous assurer que les utilisateurs de Python 2 ne sont pas accidentellement mis à niveau vers une version incompatible.

@hcho3 La mémoire externe n'est pas disponible avec les algorithmes GPU

@hlbkin Vous avez raison. La mémoire externe sera disponible uniquement pour le prédicteur GPU, pas pour l'entraînement.

@rongou @sriramch Ai-je raison de dire que la formation GPU n'est pas disponible avec la mémoire externe ?

@hcho3 oui vous avez raison. Nous y travaillons. les changements sont ici si vous êtes intéressé. Je vais devoir synchroniser ce changement avec le maître et écrire quelques tests.

@sriramch Génial ! Devrions-nous viser à inclure l'entraînement de la mémoire externe dans la version 0.90, ou devrions-nous y revenir après la 0.90 ?

juste mes deux cents, réservons un peu sur le compactage de nombreuses nouvelles fonctionnalités dans 0.x (de manière précipitée) et considérons ce qui doit être mis en 1.0 comme une version marquante

@CodingCat Je suis d'accord. Pour info, j'ai supprimé l'objectif personnalisé distribué de la feuille de route 0.90, car il y avait un désaccord substantiel dans #4280. Nous y reviendrons après 0.90.

@sriramch Considérons l'entraînement de la mémoire externe après la version 0.90. Merci beaucoup pour votre travail acharné.

C'est peut-être le bon moment pour publier les binaires cuda 9.0 au lieu de 8.0. Je pense que la version 9.0 sera désormais suffisamment prise en charge par la version du pilote des utilisateurs. De plus, les binaires 9.0 n'auront pas besoin d'être compilés JIT pour les nouvelles architectures Volta.

@hcho3 sommes-nous prêts à partir ?

Presque. Je pense que #4438 devrait être fusionné.

Tout va bien maintenant. Je vais aller de l'avant et commencer à travailler sur la prochaine version. ETA : 16 mai 2019

• [x] Nécessite Python 3 dans setup.py
• [x] Changer CI pour construire des roues CUDA 9.0 (#4459)
• [x] Correction de la compilation Windows (#4463)
• [x] Configurer un CI viable minimal pour Windows avec GPU (#4463)

@RAMitchell Devrions-nous utiliser CUDA 9.0 ou 9.2 pour les

Utilisons la 9.2 car elle est déjà configurée sur CI. Le danger est que nous ayons besoin de pilotes Nvidia trop récents. Pour référence voici le tableau montrant la correspondance entre la version cuda et les pilotes : https://docs.nvidia.com/deploy/cuda-compatibility/index.html#binary -compatibility__table-toolkit-driver

Pour autant que je sache, cela ne devrait en aucun cas avoir un impact sur les algorithmes du processeur. Si les utilisateurs commencent à signaler des problèmes, nous pourrons résoudre ce problème à l'avenir avec de meilleurs messages d'erreur concernant la compatibilité des pilotes.

Hmm dans ce cas, je peux essayer de rétrograder l'un des travailleurs de CI à CUDA 9.0. Étant donné que nous utilisons beaucoup de conteneurs Docker, cela ne devrait pas être trop difficile.

Je vais préparer la version 0.90 maintenant. Mon objectif est d'avoir la note de version complète d'ici la fin de cette semaine.

Fermé par #4475