Xgboost: خارطة طريق XGBoost 0.90

لأننا سنحصل على تغييرات عاجلة مثل https://github.com/dmlc/xgboost/pull/4349 و https://github.com/dmlc/xgboost/pull/4377

هل يمكننا رفع الإصدار إلى 0.9؟

CodingCat بالتأكيد ، يمكننا

بالتأكيد،

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

هل هناك بيان رسمي حول ذلك؟ أطلقوا سراح 2.2.3 في يناير و 2.3.3 في فبراير. لا يزال بائعنا (MapR) يشحن 2.3.1.

alexvorobiev https://github.com/dmlc/xgboost/issues/4350 ، يمكنك التحقق منsrowen من databricks

هذا ليس سؤالًا لـ Databricks ولكن لمشروع Spark. السياسة الافتراضية هي إصدارات الصيانة للفروع لمدة 18 شهرًا: https://spark.apache.org/versioning-policy.html سيؤدي ذلك إلى وضع 2.3.x في موسوعة الحياة في شهر يوليو تقريبًا ، لذلك لا نتوقع المزيد من إصدارات 2.3.x بعد هذا من مشروع OSS.

srowen شكرا!

srowenCodingCatalexvorobiev دعونا نناقش أيضا إمكانية دعم سكالا 2.12 / 2.13. في الوقت الحالي ، تم تجميع XGBoost4J من أجل Scala 2.11:
https://github.com/dmlc/xgboost/blob/2c61f02add72cce8f6dc1ba87e016e3c5f0b7ea6/jvm-packages/pom.xml#L38 -L39

أبلغ أحد المستخدمين أن XGBoost4J JARs التي تم تجميعها لـ Scala 2.11 ليست متوافقة مع Scala 2.12.

نعم ، لا يزال 2.11 / 2.12 غير متوافقين ، ولدى Spark توزيعان. كلاهما مدعوم في 2.4.x على الرغم من أن 2.12 هو الإعداد الافتراضي من الآن فصاعدًا في 2.4.x. 3.0 سيسقط دعم Scala 2.11.

قد يكون الأمر مجرد تجميع نسختين بدلاً من تغيير الكثير أو أي تغيير في الكود. إذا واجهت أي أخطاء مضحكة في 2.12 ، فأخبرني لأنني حدقت في الكثير من هذه المشكلات عند تحديث Spark.

لا يزال 2.13 ليس GA وأعتقد أنه سيكون تغييرًا أصغر من 2.12-> 2.13 من 2.11-> 2.12 (الاختلاف الكبير هنا هو تمثيل مختلف تمامًا للامبدا).

@ hcho3 أفترض أنك أردت وسمalexvorobiev؟

alexeygrigorev عذرًا ، آسف لذلك.

المشكلة الوحيدة هي أننا بحاجة إلى إدخال تغيير كسر على اسم الأداة xgboost في maven ، xgboost4j-spark => xgboost4j-spark_2.11 / xgboost4j-spark_2.12 ، مثل شرارة https://mvnrepository.com/artifact/ org.apache.spark / spark-core ونحتاج إلى التحقق جيدًا مما إذا كان لدينا أي اعتماد عابر على 2.11 (لا أعتقد ذلك)

مرحبًا ، srowen though 2.12 is the default from here on in 2.4.x ، لقد راجعت الفرع 2.4 pom.xml ، إذا لم تحدد ملف تعريف scala-2.12 ، فلا يزال بإمكانك الحصول على إصدار 2.11 ، أليس كذلك؟

يمكنك اختيار دعم 2.12 في 0.9x فقط ، وبعد ذلك لن تضطر إلى إضافة اسم الأداة. إذا كنت تدعم كليهما ، نعم ، فأنت تريد حقًا تغيير اسم الأداة لسوء الحظ ولديك إصدارات _2.11 و _2.12.

نعم ، سيكون الإصدار الافتراضي Spark 2.4.x هو 2.11 ؛ يحصل -Pscala-2.12 على الإصدار 2.12.

شكرًا ، سأظل متحفظًا في دعم 2.12 على الأقل للإصدار القادم

على حد علمي ، لا يزال معظم مستخدمي Spark يستخدمون 2.11 لأنهم معتادون على اتباع الإصدارات السابقة من Spark

قد لا يكون لدي عرض النطاق الترددي لإجراء كل اختبار لدي لتقديم دعم 2.12

سأختار دعم 2.12 + 2.11 أو 2.12 في الإصدار 1.0 ...

@ hcho3 لمعلوماتك ، لقد قمت للتو بإزالة دعم المصفوفة الكثيفة من خارطة الطريق نظرًا لعرض النطاق الترددي المحدود

@ hcho3 هل يمكنك إلقاء نظرة على https://github.com/dmlc/dmlc-core/pull/514 عندما يسمح الوقت بذلك؟ قد يكون من المفيد الدمج قبل ظهور الإصدار التالي.

@ trivialfis سوف ننظر في الأمر

CodingCat أعتقد أننا يجب أن

srowen هل تعرف متى

أعتقد أنه من الجيد أن يكون لديك بعض التأخير الطفيف

حسنًا ، دعنا ننتظر حتى يتم إصدار Spark 2.4.3

هل سيكون هناك آخر إصدار 0.83 لـ Spark 2.3.x؟

CodingCat ماذا لو قمنا بعمل إصدارين متوازيين 0.83 و 0.90 ، حيث يتضمن 0.83 جميع الالتزامات قبل # 4377 مباشرة؟ سيتم إصدار الإصدار 0.83 فقط كحزم JVM ، وستحصل حزم Python و R على 0.90. لن يكون هناك المزيد من العمل بالنسبة لي ، حيث يتعين علي كتابة مذكرة إصدار لـ 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 أو لا شيء

تضمين التغريدة سنقوم بعمل إصدارات متسقة لجميع الحزم. ما رأيك في الإصدار 0.83 إذن؟ هل يجب أن نفعلها؟

CodingCat في الواقع ، سيخلق هذا

الإجابة المختصرة من وجهة نظر شخصية هي نعم من الناحية النظرية ، ولكنها قد تكون أكثر من مجرد قطع قبل الالتزام (كما قلت ، ستخلق عملاً للآخرين أيضًا) (لكنني متردد في القيام بذلك بسبب محدودية الموارد في المجتمع ...)

هنا سنتان حول الكيفية التي يجب أن نفكر بها في إصدار الصيانة مثل 0.8x

1. السبب في الحصول على إصدار الصيانة هو تقديم إصلاحات الأخطاء الحرجة ، مثل https://github.com/dmlc/xgboost/commit/2d875ec0197d5a83e7d585daf472b8201aa97c51 و https://github.com/dmlc/xgboost/commit/995698b0cb1da75b531f066d

2. على الجانب الآخر ، لجعل المجتمع مستدامًا بخلاف التخلص من جميع الملتزمين ، يجب أن نتخلى عن دعم الإصدار السابق بشكل دوري

3. يجب تقديم الابتكارات والتحسينات للمستخدمين من خلال إصدار ميزة (قفز من 0.8 إلى 0.9)

إذا قررنا الانتقال إلى 0.83 ، فنحن بحاجة إلى جمع الآراء من RAMitchelltrivialfis أيضًا واستخدام حكمهم لمعرفة ما إذا كانت لدينا إصلاحات أخطاء مهمة (المزيد حول الصحة) لاحظوها

ثم قم بإنشاء فرع 0.83 استنادًا إلى 0.82 لالتزام انتقاء الكرز ...... الكثير من العمل في الواقع

إذا فهمت بشكل صحيح ، لن يدعم الإصدار 0.9 الإصدارات الأقدم من Spark ، ومن هنا جاء اقتراح دعم إصدار 0.83 بالإضافة إلى 0.9 لمواصلة دعم إصدارات شرارة الأقدم مع تضمين إصلاحات الأخطاء؟

بشكل عام أنا ضد أي شيء يستخدم وقت المطور. ألسنا مشغولين بما فيه الكفاية بالفعل؟ لكني أرى بعض القيمة في الحصول على نسخة مستقرة.

CodingCat هل هناك أي طريقة لدمج إصلاحات الأخطاء (2d875ec و 995698b) دون الترقية إلى Spark 2.4.x؟

إذا كان إصدار إصدارات الصيانة أكثر من مجرد قطع الفروع (على سبيل المثال ، الحاجة إلى انتقاء الكرز) ، فإنني أفضل عدم تقديم مثل هذا الالتزام.

بشكل عام أنا ضد أي شيء يستخدم وقت المطور. ألسنا مشغولين بما فيه الكفاية بالفعل؟

أنا موافق.

CodingCat هل هناك أي طريقة لدمج إصلاحات الأخطاء (2d875ec و 995698b) دون الترقية إلى Spark 2.4.x؟

@ hcho3 للأسف لا ، نظرًا

إذا كنا في المستقبل مهتمين بإصدار الصيانة ، سير العمل (بعد الإصدار 0.9)

1. backport الإصلاح الضروري إلى 0.9 فرع

2. الإصدار 0.9x لكل شهرين ، على سبيل المثال ، أو يتم تشغيله بواسطة إصلاح خطأ مهم

3. يجب أن تتوفر الميزات الرئيسية وجميع الإصلاحات المنقولة إلى 0.9x في الإصدار الرئيسي

4. عند الإصدار 1.0 ، قم بقطع فرع من السيد ......

ولكن مرة أخرى ، بمجرد أن يكون لدينا معمل إعادة بناء كبير في الماجستير ونريد إصلاح backport إلى 0.9 بعد ذلك ... طن من العمل

CodingCat نظرًا للحجم الحالي لمجتمع dev ، فلنبحث عن إصدارات الصيانة.

tovbinm آسف ، لا أعتقد أننا سنكون قادرين على إصدار 0.83 ، بسبب نقص النطاق الترددي. هل الترقية إلى Spark 2.4.3 ممكنة بالنسبة لك؟

هذا مؤسف. لا ، ليس على المدى القصير. ما زلنا على 2.3.x.

ما هو الالتزام الذي تمت ترقيته من Spark من 2.3 إلى 2.4؟ ربما يمكننا القطع هناك (إذا كان أعلى من 0.82 بالطبع).

tovbinm يمكنك إنشاء XGBoost من خلال الالتزام 711397d6452d596d7acbb68f1052ffebdee3e3af لاستخدام Spark 2.3.x.

رائعة. فلماذا لا يتم إصدار بيان علني من هذا الالتزام؟

كما قال CodingCat ، إصدارات الصيانة ليست مجرد مسألة قطع قبل الالتزام. أيضًا ، يعد إصدار النشرات العامة وعودًا ضمنية بالدعم. لا أعتقد أن المشرفين مستعدون لدعم إصدارين جديدين في هذه المرحلة الزمنية.

سأذعن لـ

ذاكرة خارجية مع متنبئ GPU - هذا يعني أن الكود لن يتعطل مع ما (): std :: bad_alloc: نفاد الذاكرة بعد الآن؟ (على سبيل المثال ، التبديل مؤقتًا إلى ذاكرة الوصول العشوائي؟)

مشكلة ذات صلة أعتقد 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) هو أنه الإصدار الصغير 90 من سلسلة الإصدار الرئيسي 0.x (أي ما قبل الإصدار الثابت) ، وليس أكثر من 0.83. علاوة على ذلك ، هذا يقيدك بحد أقصى 9 إصدارات لكل إصدار ثانوي ، ويخلق صعوبات لبعض الأدوات (والأشخاص) لتفسيرها. شكرا!

+1

@ CAM-Gerlach سننظر في الأمر عندما نصدر 1.0. من ناحية أخرى ، لا نريد التسرع إلى 1.0. نريد أن يكون الإصدار 1.0 علامة فارقة من نوع ما ، من حيث الميزات والاستقرار والأداء.

شكرا على الشرح @ hcho3 .

ربما تريد التأكد من تعيين الوسيطة python_requires على '>=3.5' في setup() لضمان عدم ترقية المستخدمين الذين يستخدمون Python 2 إلى إصدار غير متوافق عن طريق الخطأ.

@ hcho3 الذاكرة الخارجية غير متوفرة مع خوارزميات GPU

@ hlbkin أنت على حق. ستكون الذاكرة الخارجية متاحة فقط لمتنبئ وحدة معالجة الرسومات ، وليس للتدريب.

rongousriramch هل أنا تصحيح هذا التدريب GPU غير متوفر مع ذاكرة خارجية؟

@ hcho3 نعم أنت على صواب. نحن نعمل عليه. التغييرات هنا إذا كنت مهتمًا. سأضطر إلى مزامنة هذا التغيير مع السيد وكتابة بعض الاختبارات.

تضمين التغريدة هل يجب أن نهدف إلى تضمين تدريب الذاكرة الخارجية في الإصدار 0.90 ، أم يجب أن نعود إليه بعد 0.90؟

فقط سنتان ، دعنا نحتفظ قليلاً بضغط العديد من الميزات الجديدة في 0.x (بطريقة سريعة) ونفكر في ما يجب وضعه في 1.0 كإصدار هام

CodingCat أوافق. لمعلوماتك ، قمت بحذف الهدف المخصص الموزع من خريطة طريق 0.90 ، نظرًا لوجود خلاف كبير في # 4280. سننظر فيه مرة أخرى بعد 0.90.

sriramch دعونا

قد يكون هذا هو الوقت المناسب لإصدار ثنائيات cuda 9.0 بدلاً من 8.0. أعتقد أن الإصدار 9.0 سيتم دعمه الآن بشكل كافٍ بواسطة إصدار برنامج تشغيل المستخدمين. بالإضافة إلى ذلك ، لن تحتاج الثنائيات 9.0 إلى تجميع JIT لهياكل فولتا الأحدث.

@ hcho3 هل نحن مستعدون للذهاب؟

تقريبيا. أعتقد أنه يجب دمج # 4438.

كل خير الآن. سوف أمضي قدما وأبدأ العمل على الإصدار التالي. إيتا: 16 مايو 2019

• [x] طلب Python 3 في setup.py
• [x] تغيير CI لبناء عجلات CUDA 9.0 (# 4459)
• [x] إصلاح تجميع Windows (# 4463)
• [x] قم بإعداد الحد الأدنى من CI القابل للتطبيق لنظام التشغيل Windows باستخدام GPU (# 4463)

RAMitchell هل يجب استخدام CUDA 9.0 أو 9.2 لإصدارات العجلات؟

لنستخدم 9.2 حيث تم إعداده بالفعل على CI. الخطر هو أننا نطلب برامج تشغيل Nvidia جديدة جدًا. كمرجع هنا يوجد الجدول الذي يوضح المراسلات بين إصدار cuda وبرامج التشغيل: https://docs.nvidia.com/deploy/cuda-compatibility/index.html#binary -compatibility__table-toolkit-driver

بقدر ما أعرف ، لا ينبغي أن يؤثر هذا على خوارزميات وحدة المعالجة المركزية بأي حال من الأحوال. إذا بدأ المستخدمون في الإبلاغ عن المشكلات ، فيمكننا معالجة ذلك في المستقبل برسائل خطأ أفضل حول توافق برنامج التشغيل.

حسنًا ، في هذه الحالة ، يمكنني تجربة تخفيض درجة عامل CI إلى CUDA 9.0. نظرًا لأننا نستخدم حاويات Docker على نطاق واسع ، فلا ينبغي أن يكون الأمر صعبًا للغاية.

سأقوم بإعداد إصدار 0.90 الآن. هدفي هو استكمال مذكرة الإصدار بنهاية هذا الأسبوع.

مغلق برقم 4475