Xgboost: Peta Jalan XGBoost 0.90

karena kita akan mengalami perubahan besar seperti https://github.com/dmlc/xgboost/pull/4349 dan https://github.com/dmlc/xgboost/pull/4377

haruskah kita menabrak versi ke 0.9?

@CodingCat Tentu, kita bisa mencapai 0,90, jika perubahannya signifikan. Bisakah Anda membantu saya dan menulis deskripsi satu paragraf mengapa #4349 diperlukan?

Tentu,

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

Apakah ada pernyataan resmi tentang itu? Mereka merilis 2.2.3 pada bulan Januari dan 2.3.3 pada bulan Februari. Vendor kami (MapR) masih mengirimkan 2.3.1.

@alexvorobiev https://github.com/dmlc/xgboost/issues/4350 , Anda dapat memeriksa dengan @srowen dari databricks

Ini bukan pertanyaan untuk Databricks tetapi untuk proyek Spark. Kebijakan default adalah rilis pemeliharaan untuk cabang selama 18 bulan: https://spark.Apache.org/versioning-policy.html Itu akan menempatkan 2.3.x di EOL sekitar bulan Juli, jadi jangan berharap lebih banyak rilis 2.3.x setelahnya bahwa dari proyek OSS.

@srowen Terima kasih!

@srowen @CodingCat @alexvorobiev Mari kita juga membahas kemungkinan mendukung Scala 2.12 / 2.13. Saat ini, XGBoost4J dikompilasi untuk Scala 2.11:
https://github.com/dmlc/xgboost/blob/2c61f02add72cce8f6dc1ba87e016e3c5f0b7ea6/jvm-packages/pom.xml#L38 -L39

Seorang pengguna melaporkan bahwa JAR XGBoost4J yang dikompilasi untuk Scala 2.11 tidak kompatibel dengan biner Scala 2.12.

Ya, 2.11 / 2.12 masih tidak kompatibel dengan biner, dan Spark memiliki dua distribusi. Keduanya didukung di 2.4.x meskipun 2.12 adalah default mulai dari sini di 2.4.x. 3.0 akan menghentikan dukungan Scala 2.11.

Ini mungkin hanya masalah kompilasi dua versi daripada banyak atau perubahan kode apa pun. Jika Anda mengalami kesalahan lucu di 2.12, beri tahu saya karena saya melihat banyak masalah ini saat memperbarui Spark.

2.13 masih bukan GA dan berpikir itu akan menjadi perubahan yang lebih kecil dari 2.12->2.13 dari 2.11->2.12 (perbedaan besar di sini adalah representasi lambda yang sama sekali berbeda).

@hcho3 Saya berasumsi Anda ingin menandai @alexvorobiev?

@alexeygrigorev Ups, maaf soal itu.

satu-satunya masalah adalah bahwa kita perlu memperkenalkan perubahan besar pada nama artefak xgboost di maven, xgboost4j-spark => xgboost4j-spark_2.11/xgboost4j-spark_2.12, seperti spark https://mvnrepository.com/artifact/ org.Apache.spark/spark-core dan kita perlu memeriksa ulang apakah kita memiliki ketergantungan sementara pada 2.11 (saya pikir tidak)

Hai, @srowen though 2.12 is the default from here on in 2.4.x , saya memeriksa branch-2.4 pom.xml, jika Anda tidak menentukan profil scala-2.12, Anda masih mendapatkan build 2.11, bukan?

Anda dapat memilih untuk hanya mendukung 2.12 dalam 0.9x, dan kemudian Anda tidak perlu menambahkan nama artefak. Jika Anda mendukung keduanya, ya, sayangnya Anda benar-benar ingin mengubah nama artefak dan memiliki versi _2.11 dan _2.12.

Ya, build Spark 2.4.x default adalah untuk 2.11; -Pscala-2.12 mendapatkan versi 2.12.

terima kasih, saya akan tetap konservatif dalam mendukung 2.12 setidaknya untuk versi yang akan datang

Sejauh yang saya tahu, sebagian besar pengguna Spark masih menggunakan 2.11 karena mereka terbiasa mengikuti versi Spark sebelumnya

Saya mungkin tidak memiliki bandwidth untuk menjalani setiap tes yang saya miliki untuk memperkenalkan dukungan 2.12

Saya akan memilih untuk mendukung rilis 2.12 + 2.11 atau 2.12 dalam 1.0...

@hcho3 FYI, saya baru saja menghapus dukungan matriks padat dari peta jalan mengingat bandwidth terbatas

@hcho3 Bisakah Anda melihat https://github.com/dmlc/dmlc-core/pull/514 ketika waktu memungkinkan? Mungkin layak untuk digabungkan sebelum rilis berikutnya dirilis.

@trivialfis Akan melihatnya

@CodingCat Saya pikir kita harus mendorong kembali tanggal rilis, karena Spark 2.4.1 dan 2.4.2 memiliki masalah. Bagaimana menurutmu?

@srowen Apakah Anda tahu kapan Spark 2.4.3 akan keluar?

Saya pikir tidak apa-apa untuk memiliki sedikit penundaan

Oke, kita tunggu sampai Spark 2.4.3 keluar

Apakah akan ada rilis 0.83 terakhir untuk Spark 2.3.x?

@CodingCat Bagaimana jika kita membuat dua rilis paralel 0,83 dan 0,90, di mana 0,83 menyertakan semua komit sebelum #4377? Versi 0,83 hanya akan dirilis sebagai paket JVM, dan paket Python dan R akan mendapatkan 0,90. Itu tidak akan bekerja lagi untuk saya, karena saya harus menulis catatan rilis untuk 0,90.

Satu masalah adalah pengalaman pengguna dengan penanganan nilai yang hilang. Mungkin memaksa semua orang untuk menggunakan Spark 2.4.x akan mencegah mereka mengacaukan nilai-nilai yang hilang (masalah yang memotivasi #4349)

@ hcho3 Saya agak khawatir dengan ketidakkonsistenan versi yang berbeda dalam ketersediaan pkgs.

Saya bisa membayangkan pertanyaan seperti 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?

Saya menyarankan agar kami memiliki rilis pemeliharaan penuh pada cabang 0.8x atau tidak sama sekali

@CodingCat Mengerti. Kami akan melakukan rilis yang konsisten untuk semua paket. Apa pendapat Anda tentang rilis 0,83? Haruskah kita melakukannya?

@CodingCat Sebenarnya, ini akan membuat pekerjaan untuk pengelola lain, kita harus bertanya dulu kepada mereka

jawaban singkat dari pandangan pribadi adalah ya dalam teori , tetapi mungkin lebih dari memotong tepat sebelum komit (seperti yang Anda katakan, itu akan menciptakan pekerjaan untuk orang lain juga) (tapi saya agak ragu untuk melakukan ini karena keterbatasan sumber daya di masyarakat ...)

inilah 2 sen saya tentang bagaimana kita harus memikirkan rilis pemeliharaan seperti 0.8x

1. alasan untuk memiliki rilis pemeliharaan adalah untuk membawa perbaikan bug penting, seperti https://github.com/dmlc/xgboost/commit/2d875ec0197d5a83e7d585daf472b8201aa97c51 dan https://github.com/dmlc/xgboost/commit/995698b0cb1da75f066d

2. di sisi lain, untuk membuat komunitas berkelanjutan selain membakar semua commiter, kita harus menghentikan dukungan dari versi sebelumnya secara berkala

3. inovasi dan peningkatan harus dibawa ke pengguna melalui rilis fitur (melompat dari 0,8 ke 0,9)

jika kita memutuskan untuk pergi 0,83, kita perlu mengumpulkan pendapat dari @RAMitchell @trivialfis juga dan menggunakan penilaian mereka untuk melihat apakah kita memiliki perbaikan bug penting (lebih lanjut tentang kebenaran) yang diperhatikan oleh mereka

dan kemudian buat cabang 0,83 berdasarkan 0,82 ke komit cherry-pick ...... banyak pekerjaan sebenarnya

Jika saya mengerti dengan benar, 0.9 tidak akan mendukung versi percikan yang lebih lama, maka proposal untuk mendukung versi 0.83 serta 0.9 untuk melanjutkan dukungan untuk versi percikan yang lebih lama sambil menyertakan perbaikan bug?

Secara umum saya menentang apa pun yang menggunakan waktu pengembang. Bukankah kita sudah cukup sibuk? Saya melihat beberapa nilai dalam memiliki versi stabil.

@CodingCat Apakah ada cara untuk memasukkan perbaikan bug (2d875ec dan 995698b) tanpa memutakhirkan ke Spark 2.4.x?

Jika membuat rilis pemeliharaan lebih dari sekedar memotong cabang (misalnya perlu memilih ceri), saya lebih suka tidak membuat komitmen seperti itu.

Secara umum saya menentang apa pun yang menggunakan waktu pengembang. Bukankah kita sudah cukup sibuk?

Saya setuju.

@CodingCat Apakah ada cara untuk memasukkan perbaikan bug (2d875ec dan 995698b) tanpa memutakhirkan ke Spark 2.4.x?

@hcho3 sayangnya tidak, karena perubahan yang merusak di perpustakaan bergantung pada Spark, kami hanya dapat mengkompilasi dan menjalankan xgboost dengan versi percikan yang konsisten

jika di masa depan, kami tertarik dengan rilis pemeliharaan, alur kerja (setelah merilis 0,9)

1. backport perbaikan yang diperlukan ke 0,9-cabang

2. rilis 0,9x untuk setiap, katakanlah, 2 bulan, atau dipicu oleh perbaikan bug penting

3. fitur utama dan semua perbaikan yang di-backport ke 0.9x harus tersedia di master

4. saat rilis 1.0, potong cabang dari master ......

tetapi sekali lagi, setelah kami memiliki refactor besar di master dan ingin memperbaiki backport ke 0,9 setelah itu ... banyak pekerjaan

@CodingCat Mengingat ukuran komunitas dev saat ini, mari kita beralih ke rilis pemeliharaan.

@tovbinm Maaf, saya rasa kami tidak dapat melakukan rilis 0,83, karena kekurangan bandwidth. Apakah memutakhirkan ke Spark 2.4.3 layak untuk Anda?

Itu sangat disayangkan. Tidak, tidak dalam jangka pendek. Kami masih di 2.3.x.

Apa komit yang meningkatkan Spark dari 2,3 menjadi 2,4? Mungkin kita bisa memotong di sana (jika di atas 0,82 tentu saja).

@tovbinm Anda dapat membangun XGBoost dengan komit 711397d6452d596d7acbb68f1052ffebdee3e3af untuk menggunakan Spark 2.3.x.

Besar. Jadi mengapa tidak membuat rilis publik dari komit itu?

Seperti yang dikatakan @CodingCat , rilis pemeliharaan bukan hanya masalah pemotongan sebelum komit. Juga, membuat rilis publik adalah janji implisit dukungan. Saya tidak berpikir pengelola siap untuk mendukung dua rilis baru pada saat ini.

Saya akan tunduk pada @CodingCat apakah kita harus membuat rilis dari 711397d6452d596d7acbb68f1052ffebdee3e3af

Memori eksternal dengan prediktor GPU - ini berarti kode tidak akan macet dengan what(): std::bad_alloc: kehabisan memori lagi? (yaitu untuk sementara bertukar ke RAM?)

masalah terkait saya kira https://github.com/dmlc/xgboost/issues/4184 - ini terutama pada semburan memori temporal, proses pemasangannya sendiri tidak pernah membutuhkan begitu banyak memori

@hlbkin Anda harus mengaktifkan memori eksternal secara eksplisit, menurut https://xgboost.readthedocs.io/en/latest/tutorials/external_memory.html

Saya berasumsi tidak mungkin untuk beralih sebaliknya tanpa benjolan versi utama (yaitu 1.0), tetapi ketika Anda melakukannya, dapatkah Anda mempertimbangkan untuk mendukung nomor versi PEP 440 yang sesuai (iexyz), dan lebih disukai versi semantik? Interpretasi standar dari 0,90 (bukan 0,9.0) adalah bahwa ini adalah rilis minor ke-90 dari seri versi utama 0.x (yaitu pra-rilis-stabil), dan tidak lebih signifikan dari 0,83. Selain itu, ini membatasi Anda hingga maksimum 9 poin rilis per versi minor, dan menciptakan kesulitan bagi beberapa alat (dan orang) untuk menafsirkannya. Terima kasih!

+1

@CAM-Gerlach Kami akan mempertimbangkannya ketika kami merilis 1.0. Di sisi lain, kami tidak ingin terburu-buru ke 1.0. Kami ingin 1.0 menjadi semacam tonggak sejarah, dalam hal fitur, stabilitas, dan kinerja.

Terima kasih atas penjelasannya, @hcho3 .

Anda mungkin ingin memastikan bahwa Anda menyetel argumen python_requires ke '>=3.5' di setup() untuk memastikan pengguna dengan Python 2 tidak diupgrade ke versi yang tidak kompatibel secara tidak sengaja.

@hcho3 Memori eksternal tidak tersedia dengan algoritma GPU

@hlbkin Anda benar. Memori eksternal hanya akan tersedia untuk prediktor GPU, bukan untuk pelatihan.

@rongou @sriramch Apakah saya benar bahwa pelatihan GPU tidak tersedia dengan memori eksternal?

@hcho3 ya Anda benar. kami sedang mengerjakannya. perubahan di sini jika Anda tertarik. saya harus menyinkronkan perubahan ini dengan master dan menulis beberapa tes.

@sriramch Luar

hanya dua sen saya, mari kita simpan sedikit untuk memadatkan banyak fitur baru di 0.x (secara terburu-buru) dan pertimbangkan apa yang akan dimasukkan ke 1.0 sebagai versi tonggak sejarah

@CodingCat saya setuju. FYI, saya menghapus tujuan khusus terdistribusi dari peta jalan 0,90, karena ada ketidaksepakatan substansial di #4280. Kami akan mempertimbangkannya lagi setelah 0,90.

@sriramch Mari kita pertimbangkan pelatihan memori eksternal setelah rilis 0,90. Terima kasih banyak atas kerja keras Anda.

Ini mungkin saat yang tepat untuk merilis binari cuda 9.0 alih-alih 8.0. Saya pikir 9.0 sekarang akan cukup didukung oleh versi driver pengguna. Selain itu, binari 9.0 tidak perlu dikompilasi JIT untuk arsitektur Volta yang lebih baru.

@hcho3 apakah kita siap untuk pergi?

Hampir. Saya pikir #4438 harus digabungkan.

Semua baik sekarang. Saya akan melanjutkan dan mulai mengerjakan rilis berikutnya. ETA: 16 Mei 2019

• [x] Memerlukan Python 3 di setup.py
• [x] Ubah CI untuk membuat roda CUDA 9.0 (#4459)
• [x] Perbaiki kompilasi Windows (#4463)
• [x] Siapkan CI minimal yang layak untuk Windows dengan GPU (#4463)

@RAMitchell Haruskah kita menggunakan CUDA 9.0 atau 9.2 untuk rilis roda?

Mari kita gunakan 9.2 karena itu sudah diatur di CI. Bahayanya adalah kami membutuhkan driver Nvidia yang terlalu baru. Untuk referensi di sini adalah tabel yang menunjukkan korespondensi antara versi cuda dan driver: https://docs.nvidia.com/deploy/cuda-compatibility/index.html#binary -compatibility__table-toolkit-driver

Sejauh yang saya tahu ini seharusnya tidak memengaruhi algoritma CPU. Jika pengguna mulai melaporkan masalah, kami dapat mengatasinya di masa mendatang dengan pesan kesalahan yang lebih baik seputar kompatibilitas driver.

Hmm kalau begitu saya bisa mencoba menurunkan salah satu pekerja CI ke CUDA 9.0. Karena kami menggunakan container Docker secara ekstensif, seharusnya tidak terlalu sulit.

Saya akan menyiapkan rilis 0,90 sekarang. Tujuan saya adalah menyelesaikan catatan rilis pada akhir minggu ini.

Ditutup oleh #4475