Xgboost: Roteiro XGBoost 0.90

pois teremos mudanças importantes como https://github.com/dmlc/xgboost/pull/4349 e https://github.com/dmlc/xgboost/pull/4377

devemos elevar a versão para 0.9?

@CodingCat Claro, podemos

certo,

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

Existe uma declaração oficial sobre isso? Eles lançaram o 2.2.3 em janeiro e o 2.3.3 em fevereiro. Nosso fornecedor (MapR) ainda envia 2.3.1.

@alexvorobiev https://github.com/dmlc/xgboost/issues/4350 , você pode verificar com @srowen em databricks

Esta não é uma pergunta para o Databricks, mas para o projeto Spark. A política padrão é lançamentos de manutenção para branches por 18 meses: https://spark.apache.org/versioning-policy.html Isso colocaria 2.3.x no EOL por volta de julho, então não esperaria mais lançamentos 2.3.x depois do projeto OSS.

@srowen Obrigado!

@srowen @CodingCat @alexvorobiev Vamos também discutir a possibilidade de suportar Scala 2.12 / 2.13. No momento, o XGBoost4J é compilado para Scala 2.11:
https://github.com/dmlc/xgboost/blob/2c61f02add72cce8f6dc1ba87e016e3c5f0b7ea6/jvm-packages/pom.xml#L38 -L39

Um usuário relatou que os JARs XGBoost4J compilados para Scala 2.11 não são binários compatíveis com Scala 2.12.

Sim, 2.11 / 2.12 ainda são incompatíveis com o binário e o Spark tem duas distribuições. Ambos são suportados em 2.4.x embora 2.12 seja o padrão daqui em diante em 2.4.x. 3.0 eliminará o suporte Scala 2.11.

Pode ser apenas uma questão de compilar duas versões em vez de muita ou qualquer alteração no código. Se você encontrar algum erro engraçado no 2.12, me avise, porque eu observei muitos desses problemas ao atualizar o Spark.

2,13 ainda não é GA e acho que será uma mudança menor de 2,12-> 2,13 do que 2,11-> 2,12 (a grande diferença aqui é a representação totalmente diferente de lambdas).

@ hcho3 Presumo que você queira marcar @alexvorobiev?

@alexeygrigorev Oops, desculpe por isso.

o único problema é que precisamos introduzir uma alteração significativa no nome do artefato de xgboost em maven, xgboost4j-spark => xgboost4j-spark_2.11 / xgboost4j-spark_2.12, como spark https://mvnrepository.com/artifact/ org.apache.spark / spark-core e precisamos verificar se temos alguma dependência temporária no 2.11 (acho que não)

Olá, @srowen though 2.12 is the default from here on in 2.4.x , eu verifiquei branch-2.4 pom.xml, se você não especificar o perfil scala-2.12, você ainda obterá uma compilação 2.11, não?

Você pode escolher suportar apenas 2,12 em 0,9x e, então, não precisa sufocar o nome do artefato. Se você oferece suporte a ambos, sim, você realmente gostaria de alterar o nome do artefato, infelizmente, e ter as versões _2.11 e _2.12.

Sim, a compilação padrão do Spark 2.4.x será para 2.11; -Pscala-2.12 obtém a compilação 2.12.

obrigado, eu ficaria conservador no suporte ao 2.12, pelo menos para a próxima versão

até onde eu sei, a maioria dos usuários do Spark ainda está usando 2.11, pois estão acostumados a seguir versões anteriores do Spark

Posso não ter largura de banda para passar por todos os testes que tenho para a introdução do suporte 2.12

Eu escolheria suportar 2,12 + 2,11 ou 2,12 na versão 1.0 ...

@ hcho3 Para

@ hcho3 Você poderia dar uma olhada em https://github.com/dmlc/dmlc-core/pull/514 quando o tempo permitir? Pode valer a pena mesclar antes do próximo lançamento.

@trivialfis vai olhar para ele

@CodingCat Acho que devemos adiar a data de lançamento, pois o Spark 2.4.1 e 2.4.2 têm problemas. O que você acha?

@srowen Você sabe quando o Spark 2.4.3 será lançado?

Eu acho que é bom ter um pequeno atraso

Ok, vamos esperar até que Spark 2.4.3 seja lançado

Haveria a última versão 0,83 do Spark 2.3.x?

@CodingCat E se fizermos duas versões paralelas 0,83 e 0,90, onde 0,83 inclui todos os commits antes de # 4377? A versão 0.83 seria lançada apenas como pacotes JVM, e os pacotes Python e R obteriam 0.90. Não será mais trabalho para mim, já que tenho que escrever uma nota de lançamento para 0,90 de qualquer maneira.

Um problema, porém, é a experiência do usuário com o tratamento de valores ausentes. Talvez forçar todos a usar o Spark 2.4.x irá impedi-los de bagunçar com valores ausentes (o problema que motivou # 4349)

@ hcho3 Estou um pouco preocupado com a inconsistência de diferentes versões na disponibilidade de pacotes.

Posso imaginar perguntas 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?

Eu sugiro que tenhamos uma versão de manutenção completa no branch 0.8x ou nada

@CodingCat Entendi. Faremos lançamentos consistentes para todos os pacotes. Qual é a sua opinião sobre a versão 0.83, então? Devemos fazer isso?

@CodingCat Na verdade, isso criará trabalho para outros mantenedores, precisamos perguntar a eles primeiro

uma resposta curta do ponto de vista pessoal é sim em teoria , mas pode ser mais do que cortar logo antes de um commit (como você disse, criará trabalho para outros também) (mas estou meio que hesitado em fazer isso por causa da limitação recursos na comunidade ...)

aqui estão meus 2 centavos sobre como devemos pensar sobre a versão de manutenção como 0,8x

1. a razão de ter uma versão de manutenção é trazer correções de erros críticos, como https://github.com/dmlc/xgboost/commit/2d875ec0197d5a83e7d585daf472b8201aa97c51 e https://github.com/dmlc/xgboost/commit/995698b0cb1da75f066d7e0531302a3bfa5a49a4

2. por outro lado, para tornar a comunidade sustentável além de eliminar todos os committers, devemos retirar o suporte da versão anterior periodicamente

3. as inovações e melhorias devem ser levadas aos usuários por meio de uma versão de recurso (pule de 0,8 para 0,9)

se decidirmos ir para 0,83, precisamos coletar opiniões de @RAMitchell @trivialfis também e usar seu juiz para ver se temos correções de bug importantes (mais sobre correção) que são notadas por eles

e, em seguida, criar um branch de 0,83 com base em 0,82 para selecionar os commits ...... muito trabalho, na verdade

Se bem entendi, 0.9 não suportará versões mais antigas do Spark, daí a proposta de suportar uma versão 0.83, bem como 0.9 para continuar com o suporte para versões mais antigas do Spark enquanto inclui correções de bugs.

Geralmente sou contra qualquer coisa que use o tempo do desenvolvedor. Já não estamos ocupados o suficiente? No entanto, vejo algum valor em ter uma versão estável.

@CodingCat Existe alguma maneira de incorporar correções de bugs (2d875ec e 995698b) sem atualizar para o Spark 2.4.x?

Se fazer lançamentos de manutenção é mais do que apenas cortar galhos (por exemplo, a necessidade de escolher a dedo), prefiro não me comprometer.

Geralmente sou contra qualquer coisa que use o tempo do desenvolvedor. Já não estamos ocupados o suficiente?

Eu concordo.

@CodingCat Existe alguma maneira de incorporar correções de bugs (2d875ec e 995698b) sem atualizar para o Spark 2.4.x?

@ hcho3 infelizmente não, devido às alterações importantes na biblioteca dependente do Spark, só podemos compilar e executar o xgboost com a versão consistente do Spark

se no futuro, estivermos interessados ​​na liberação de manutenção, o fluxo de trabalho (após a liberação de 0.9)

1. correção necessária backport para 0.9-branch

2. versão 0.9x a cada, digamos, 2 meses, ou acionada por uma correção de bug importante

3. os principais recursos e todas as correções com backport para 0.9x devem estar disponíveis no master

4. na versão 1.0, corte um branch do master ......

mas, novamente, uma vez que temos um grande refatorador no mestre e queremos corrigir o backport para 0.9 depois disso ... toneladas de trabalho

@CodingCat Dado o tamanho atual da comunidade dev, vamos dar uma olhada nas versões de manutenção.

@tovbinm Desculpe, não acho que conseguiremos fazer a versão 0.83, devido à falta de largura de banda. A atualização para o Spark 2.4.3 é viável para você?

Isso é lamentável. Não, não a curto prazo. Ainda estamos em 2.3.x.

Qual é o commit que atualizou o Spark de 2.3 para 2.4? Talvez possamos cortar aí (se estiver acima de 0,82, é claro).

@tovbinm Você pode construir o XGBoost com o commit 711397d6452d596d7acbb68f1052ffebdee3e3af para usar o Spark 2.3.x.

Excelente. Então, por que não fazer uma liberação pública desse commit?

Como disse @CodingCat , as versões de manutenção não são simplesmente uma questão de cortar antes de um commit. Além disso, fazer lançamentos públicos são promessas implícitas de suporte. Eu não acho que os mantenedores estão dispostos a suportar dois novos lançamentos neste momento.

Vou adiar para @CodingCat para saber se devemos fazer um lançamento de 711397d6452d596d7acbb68f1052ffebdee3e3af

Memória externa com preditor de GPU - isso significaria que o código não travaria mais com what (): std :: bad_alloc: sem memória? (ou seja, trocar temporariamente para RAM?)

problema relacionado, eu acho que https://github.com/dmlc/xgboost/issues/4184 - isso foi principalmente em rajadas temporais de memória, o processo de adaptação em si nunca requer tanta memória

@hlbkin Você precisará habilitar explicitamente a memória externa, de acordo com https://xgboost.readthedocs.io/en/latest/tutorials/external_memory.html

Presumo que não seja possível alternar de outra forma sem um aumento de versão principal (ou seja, 1.0), mas quando você fizer isso, você poderia considerar o suporte a números de versão PEP 440 em conformidade (iexyz) e, de preferência, controle de versão semântica? A interpretação padrão de 0.90 (em vez de 0.9.0) seria que é a 90ª versão secundária da série principal da versão 0.x (isto é, versão pré-estável) e não é mais significativa do que 0.83. Além disso, isso restringe você a um máximo de 9 versões pontuais por versão secundária e cria dificuldades para algumas ferramentas (e pessoas) interpretarem. Obrigado!

+1

@ CAM-Gerlach Vamos considerar isso quando lançarmos 1.0. Por outro lado, não queremos nos apressar para 1.0. Queremos que 1.0 seja um marco de algum tipo, em termos de recursos, estabilidade e desempenho.

Obrigado pela explicação, @ hcho3 .

Você provavelmente quer ter certeza de definir o argumento python_requires como '>=3.5' em setup() para garantir que os usuários com Python 2 não sejam atualizados para uma versão incompatível acidentalmente.

@ hcho3 A memória externa não está disponível com algoritmos de GPU

@hlbkin Você está certo. A memória externa estará disponível apenas para o preditor de GPU, não para treinamento.

@rongou @sriramch Estou correto que o treinamento da GPU não está disponível com memória externa?

@ hcho3 sim, você está correto. Estamos trabalhando nisso. as mudanças estão aqui se você estiver interessado. terei que sincronizar essa alteração com o mestre e escrever alguns testes.

@sriramch Awesome! Devemos ter como objetivo incluir o treinamento de memória externa na versão de 0,90 ou devemos voltar a ele depois de 0,90?

apenas meus dois centavos, vamos reservar um pouco sobre a compactação de muitos novos recursos no 0.x (de uma maneira rápida) e considerar o que deve ser colocado no 1.0 como uma versão de marco

@CodingCat eu concordo. Para sua informação, excluí o objetivo personalizado distribuído do roteiro de 0,90, uma vez que havia divergência substancial em # 4280. Vamos considerá-lo novamente após 0,90.

@sriramch Vamos considerar o treinamento da memória externa após o lançamento de 0,90. Muito obrigado pelo seu trabalho árduo.

Este pode ser um bom momento para lançar os binários cuda 9.0 em vez do 8.0. Acho que o 9.0 agora será suficientemente suportado pela versão do driver dos usuários. Além disso, os binários 9.0 não precisarão ser compilados JIT para as arquiteturas Volta mais recentes.

@ hcho3 estamos prontos para ir?

Quase. Acho que # 4438 deve ser mesclado.

Tudo bem agora. Vou prosseguir e começar a trabalhar no próximo lançamento. ETA: 16 de maio de 2019

• [x] Requer Python 3 em setup.py
• [x] Alterar CI para construir rodas CUDA 9.0 (# 4459)
• [x] Correção da compilação do Windows (# 4463)
• [x] Configure um CI mínimo viável para Windows com GPU (# 4463)

@RAMitchell Devemos usar CUDA 9.0 ou 9.2 para lançamentos de rodas?

Vamos usar o 9.2, pois ele já está configurado no CI. O perigo é que exigimos drivers da Nvidia que são muito novos. Para referência, aqui está a tabela que mostra a correspondência entre a versão cuda e os drivers: https://docs.nvidia.com/deploy/cuda-compatibility/index.html#binary -compatibility__table-toolkit-driver

Pelo que eu sei, isso não deve afetar os algoritmos da CPU de forma alguma. Se os usuários começarem a relatar problemas, podemos resolver isso no futuro com melhores mensagens de erro sobre compatibilidade de driver.

Hmm, nesse caso, posso tentar rebaixar um dos trabalhadores de CI para CUDA 9.0. Como usamos amplamente os contêineres do Docker, isso não deve ser muito difícil.

Vou preparar a versão 0.90 agora. Meu objetivo é ter a nota de lançamento completa até o final desta semana.

Fechado por # 4475