Xgboost: XGBoost 0.90 로드맵

https://github.com/dmlc/xgboost/pull/4349 및 https://github.com/dmlc/xgboost/pull/4377 과 같은 주요 변경 사항이 있을 예정이므로

버전을 0.9로 올려 볼까요?

@CodingCat 물론, 브레이킹 체인지가 중요하다면 0.90까지

확실한,

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

이에 대한 공식 입장이 있습니까? 그들은 1월에 2.2.3을, 2월에 2.3.3을 출시했습니다. 공급업체(MapR)는 여전히 2.3.1을 제공합니다.

@alexvorobiev https://github.com/dmlc/xgboost/issues/4350 , databricks 에서 @srowen으로 확인할 수 있습니다.

이것은 Databricks에 대한 질문이 아니라 Spark 프로젝트에 대한 질문입니다. 기본 정책은 18개월 동안 분기에 대한 유지 관리 릴리스입니다. https://spark.apache.org/versioning-policy.html 그러면 2.3.x가 약 7월에 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

사용자 는 Scala 2.11용으로 컴파일된 XGBoost4J JAR이 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.11->2.12보다 2.12->2.13에서 더 작은 변경이 될 것이라고 생각합니다(여기서 큰 차이점은 람다의 표현이 완전히 다르다는 것입니다).

@hcho3 @alexvorobiev 에 태그를 지정하고 싶었습니까?

@alexeygrigorev 죄송합니다.

유일한 문제는 maven에서 xgboost의 아티팩트 이름, xgboost4j-spark => xgboost4j-spark_2.11/xgboost4j-spark_2.12(예: spark https://mvnrepository.com/artifact/)에 획기적인 변경을 도입해야 한다는 것입니다

안녕하세요, @srowen though 2.12 is the default from here on in 2.4.x , 나는 branch-2.4 pom.xml을 확인했습니다. 프로필 scala-2.12를 지정하지 않으면 여전히 2.11 빌드를 얻습니다.

0.9x에서 2.12만 지원하도록 선택할 수 있으며, 그러면 아티팩트 이름에 접미사를 붙일 필요가 없습니다. 둘 다 지원한다면 불행히도 아티팩트 이름을 변경하고 _2.11 및 _2.12 버전을 사용하고 싶을 것입니다.

예, 기본 Spark 2.4.x 빌드는 2.11용입니다. -Pscala-2.12 는 2.12 빌드를 가져옵니다.

감사합니다. 최소한 다음 버전에서는 2.12를 지원하는 데 보수적일 것입니다.

내가 아는 한 대부분의 Spark 사용자는 이전 버전의 Spark를 따르는 데 익숙하기 때문에 여전히 2.11을 사용하고 있습니다.

2.12 지원을 도입하기 위한 모든 테스트를 통과할 대역폭이 없을 수 있습니다.

1.0 릴리스에서 2.12 + 2.11 또는 2.12를 지원하도록 선택하겠습니다...

@hcho3 참고로 제한된 대역폭을 감안할 때 로드맵에서 밀집 매트릭스 지원을 제거했습니다.

@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이 나올 때까지 기다리자

Spark 2.3.x의 마지막 0.83 릴리스가 있습니까?

@CodingCat 0.83에는 #4377 직전의 모든 커밋이 포함된 두 개의 병렬 릴리스 0.83과 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 사실, 이것은 다른 메인테이너를 위한 작업을 생성할 것입니다, 우리는 그들에게 먼저 물어야 할 것입니다

개인적인 견해의 짧은 대답은 이론상 yes 이지만 커밋 직전에 자르는 것 이상일 수 있습니다(당신이 말했듯이 다른 사람들을 위한 작업도 생성할 것입니다) (그러나 제한된 지역사회의 자원...)

다음은 0.8x와 같은 유지 관리 릴리스에 대해 어떻게 생각해야 하는지에 대한 2센트입니다.

1. 유지 관리 릴리스가 있는 이유는 https://github.com/dmlc/xgboost/commit/2d875ec0197d5a83e7d585daf472b8201aa97c5667 및 https://github.com/dmlc/xgboost/9877f453bboost/99c05 와 같은 중요한 버그 수정을 가져오기 위함입니다.

2. 다른 한편으로, 모든 커미터를 소진시키는 것 외에 커뮤니티를 지속 가능하게 만들기 위해 주기적으로 이전 버전의 지원을 중단해야 합니다.

3. 기능 릴리스(0.8에서 0.9로 이동)를 통해 혁신과 개선을 사용자에게 제공해야 합니다.

0.83으로 가기로 결정한 경우 @RAMitchell @trivialfis의 의견도 수집하고 판단을 통해 중요한(정확성에 대한 추가) 버그 수정 사항이 있는지 확인해야 합니다.

그런 다음 0.82를 기반으로 0.83 분기를 만들어 커밋을 선택합니다. 실제로 많은 작업이 필요합니다.

내가 올바르게 이해한다면 0.9는 이전 버전의 스파크를 지원하지 않으므로 버그 수정을 포함하면서 이전 스파크 버전에 대한 지원을 계속하기 위해 0.83 버전과 0.9를 지원하라는 제안은 무엇입니까?

일반적으로 저는 개발자 시간을 사용하는 모든 것에 반대합니다. 우리는 이미 충분히 바쁘지 않습니까? 그러나 안정적인 버전을 갖는 데 약간의 가치가 있습니다.

@CodingCat Spark 2.4.x로 업그레이드하지 않고 버그 수정(2d875ec 및 995698b)을 통합할 수 있는 방법이 있습니까?

유지 관리 릴리스를 만드는 것이 단순히 가지를 자르는 것 이상이면(예: 체리를 따야 함), 저는 그러한 약속을 하지 않을 것입니다.

일반적으로 저는 개발자 시간을 사용하는 모든 것에 반대합니다. 우리는 이미 충분히 바쁘지 않습니까?

나는 동의한다.

@CodingCat Spark 2.4.x로 업그레이드하지 않고 버그 수정(2d875ec 및 995698b)을 통합할 수 있는 방법이 있습니까?

@hcho3 불행히도 아니요. Spark에 의존하는 라이브러리의 주요 변경 사항으로 인해 일관된 버전의 spark로만 xgboost를 컴파일하고 실행할 수 있습니다.

향후 유지 관리 릴리스, 워크플로(0.9 릴리스 이후)에 관심이 있다면

1. 0.9 분기에 필요한 백포트 수정

2. 2개월마다 0.9x 릴리스 또는 중요한 버그 수정으로 인해 발생

3. 주요 기능 및 0.9x로 백포트된 모든 수정 사항은 마스터에서 사용할 수 있어야 합니다.

4. 릴리스 1.0 때 마스터에서 분기를 잘라 ......

하지만 다시, 마스터에 큰 리팩터가 있고 그 후에 수정 사항을 0.9로 백포트하려는 경우... 많은 작업이 필요합니다.

@CodingCat 현재 개발 커뮤니티의 규모를 감안할 때 유지 관리 릴리스에 대해 알아보겠습니다.

@tovbinm 죄송합니다. 대역폭 부족으로 인해 0.83 릴리스를 할 수 없을 것 같습니다. Spark 2.4.3으로 업그레이드할 수 있습니까?

운이 없었어. 아니요, 단기적으로는 아닙니다. 우리는 여전히 2.3.x에 있습니다.

Spark를 2.3에서 2.4로 업그레이드한 커밋은 무엇입니까? 아마도 우리는 거기에서 잘라낼 수 있습니다(물론 0.82 이상이면).

@tovbinm Spark 2.3.x를 사용하려면 커밋 711397d6452d596d7acbb68f1052ffebdee3e3af로 XGBoost를 빌드할 수 있습니다.

엄청난. 그렇다면 그 커밋에서 공개 릴리스를 하지 않는 이유는 무엇입니까?

@CodingCat이 말했듯이 유지 관리 릴리스는 단순히 커밋 전에 잘라내는 문제가 아닙니다. 또한 공개 발표는 지원에 대한 암묵적인 약속입니다. 현재로서는 유지 관리자가 두 가지 새로운 릴리스를 지원할 준비가 되어 있지 않다고 생각합니다.

711397d6452d596d7acbb68f1052ffebdee3e3af 에서 출시해야 하는지 여부는 @CodingCat에 맡기겠습니다.

GPU 예측기가 있는 외부 메모리 - 이는 코드가 더 이상 what(): std::bad_alloc: 메모리 부족으로 충돌하지 않음을 의미합니다. (즉, 일시적으로 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이 아닌)에 대한 표준 해석은 이것이 주 버전 0.x(즉, 안정화 릴리스 이전) 시리즈의 90번째 부 릴리스이며 0.83보다 더 중요하지 않다는 것입니다. 또한, 이는 부 버전당 최대 9포인트 릴리스로 제한하고 일부 도구(및 사람)가 해석하기 어렵게 만듭니다. 감사 해요!

+1

@CAM-Gerlach 1.0을 출시할 때 고려할 것입니다. 반면에 우리는 1.0으로 서두르고 싶지 않습니다. 우리는 1.0이 기능, 안정성 및 성능 면에서 일종의 이정표가 되기를 바랍니다.

@hcho3 설명 감사합니다.

Python 2 사용자가 실수로 호환되지 않는 버전으로 업그레이드되지 않도록 setup() 에서 python_requires 인수를 '>=3.5' 로 설정했는지 확인하고 싶을 것입니다.

@hcho3 외부 메모리는 GPU 알고리즘과 함께 사용할 수 없습니다.

@hlbkin 당신이 맞습니다. 외부 메모리는 훈련이 아닌 GPU 예측에만 사용할 수 있습니다.

@rongou @sriramch 외부 메모리에서 GPU 교육을 사용할 수 없다는 것이 맞습니까?

@hcho3 네 맞습니다. 우리는 그것에 노력하고 있습니다. 관심이 있는 경우 변경 사항이 여기에 있습니다. 이 변경 사항을 마스터와 동기화하고 몇 가지 테스트를 작성해야 합니다.

@sriramch 굉장합니다! 0.90 릴리스에 외부 메모리 교육을 포함하는 것을 목표로 해야 합니까, 아니면 0.90 이후에 다시 해야 합니까?

내 2센트, 0.x의 많은 새로운 기능을 압축하는 데 약간의 시간을 들이고(급하게) 1.0에 무엇을 마일스톤 버전으로 넣을지 고려합시다.

@CodingCat 동의합니다. 참고로 저는 #4280에서 상당한 이견이 있었기 때문에 0.90 로드맵에서 분산 사용자 정의 목표를 삭제했습니다. 0.90 이후에 다시 고려하겠습니다.

@sriramch 0.90 릴리스 이후의 외부 메모리 훈련을 생각해보자. 노고에 감사드립니다.

이것은 8.0 대신 cuda 9.0 바이너리를 출시하기에 좋은 시기일 수 있습니다. 9.0은 이제 사용자 드라이버 버전에서 충분히 지원될 것이라고 생각합니다. 또한 9.0 바이너리는 최신 Volta 아키텍처용으로 JIT 컴파일할 필요가 없습니다.

@hcho3 갈 준비 되셨나요?

거의. #4438을 병합해야 한다고 생각합니다.

이제 모든 것이 좋습니다. 다음 릴리스 작업을 시작하겠습니다. 예상 도착일: 2019년 5월 16일

• [x] setup.py Python 3 필요
• [x] CUDA 9.0 휠을 빌드하도록 CI 변경(#4459)
• [x] Windows 컴파일 수정(#4463)
• [x] GPU가 있는 Windows용 최소 실행 가능한 CI 설정(#4463)

@RAMitchell 휠 릴리스에 CUDA 9.0 또는 9.2를 사용해야 합니까?

CI에 이미 설정되어 있는 9.2를 사용하겠습니다. 위험은 너무 새로운 Nvidia 드라이버가 필요하다는 것입니다. 참고로 다음은 cuda 버전과 드라이버 간의 대응 관계를 보여주는 표입니다. https://docs.nvidia.com/deploy/cuda-compatibility/index.html#binary -compatibility__table-toolkit-driver

내가 아는 한 이것은 어쨌든 CPU 알고리즘에 영향을 미치지 않아야 합니다. 사용자가 문제를 보고하기 시작하면 향후 드라이버 호환성에 대한 더 나은 오류 메시지로 이 문제를 해결할 수 있습니다.

흠 그렇다면 CI 작업자 중 하나를 CUDA 9.0으로 다운그레이드할 수 있습니다. 우리는 Docker 컨테이너를 광범위하게 사용하고 있기 때문에 그렇게 어렵지 않을 것입니다.

이제 0.90 릴리스를 준비하겠습니다. 내 목표는 이번 주 말에 릴리스 노트를 완성하는 것입니다.

폐쇄 #4475