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

क्‍या इस संबंध में कोई आधिकारिक वक्‍तव्‍य है? उन्होंने जनवरी में 2.2.3 और फरवरी में 2.3.3 रिलीज़ की। हमारा विक्रेता (MapR) अभी भी 2.3.1 शिप करता है।

@alexvorobiev https://github.com/dmlc/xgboost/issues/4350 , आप डेटाब्रिक्स से @srowen से जांच कर सकते हैं

यह सवाल डेटाब्रिक्स के लिए नहीं बल्कि स्पार्क प्रोजेक्ट के लिए है। डिफ़ॉल्ट नीति 18 महीनों के लिए शाखाओं के लिए रखरखाव रिलीज है: https://spark.apache.org/versioning-policy.html जो जुलाई में ईओएल पर 2.3.x डाल देगा, इसलिए इसके बाद 2.3.x और रिलीज की उम्मीद नहीं होगी कि ओएसएस परियोजना से।

@srowen धन्यवाद!

@srowen @CodingCat @alexvorobiev आइए
https://github.com/dmlc/xgboost/blob/2c61f02add72cce8f6dc1ba87e016e3c5f0b7ea6/jvm-packages/pom.xml#L38 -L39

एक उपयोगकर्ता ने बताया कि स्कैला 2.11 के लिए संकलित XGBoost4J JARs स्कैला 2.12 के साथ बाइनरी संगत नहीं है।

हाँ, २.११ / २.१२ अभी भी द्विआधारी-असंगत हैं, और स्पार्क के दो वितरण हैं। दोनों 2.4.x में समर्थित हैं, हालांकि 2.12 यहां से 2.4.x में डिफ़ॉल्ट है। 3.0 स्काला 2.11 सपोर्ट छोड़ देगा।

यह बहुत अधिक या किसी कोड परिवर्तन के बजाय दो संस्करणों को संकलित करने का मामला हो सकता है। यदि आप 2.12 में किसी भी अजीब त्रुटि में भाग लेते हैं तो मुझे बताएं क्योंकि स्पार्क को अपडेट करते समय मैंने इनमें से बहुत से मुद्दों को देखा था।

2.13 अभी भी GA नहीं है और लगता है कि यह 2.12->2.13 से 2.11->2.12 से एक छोटा बदलाव होगा (यहां बड़ा अंतर लैम्ब्डा का पूरी तरह से अलग प्रतिनिधित्व है)।

@ hcho3 मुझे लगता है कि आप @alexvorobiev को टैग करना चाहते हैं?

@alexeygrigorev ओह, इसके लिए खेद है।

एकमात्र मुद्दा यह है कि हमें मावेन में xgboost के आर्टिफैक्ट नाम में एक ब्रेकिंग परिवर्तन पेश करने की आवश्यकता है, 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 बिल्ड मिलता है, नहीं?

आप 0.9x में केवल 2.12 का समर्थन करना चुन सकते हैं, और फिर आपको विरूपण साक्ष्य नाम को प्रत्ययित करने की आवश्यकता नहीं है। यदि आप दोनों का समर्थन करते हैं, हाँ, आप वास्तव में दुर्भाग्य से विरूपण साक्ष्य नाम बदलना चाहते हैं और आपके पास _2.11 और _2.12 संस्करण हैं।

हाँ डिफ़ॉल्ट स्पार्क २.४.x बिल्ड २.११ के लिए होगा; -Pscala-2.12 को 2.12 बिल्ड मिलता है।

धन्यवाद, मैं कम से कम आने वाले संस्करण के लिए 2.12 का समर्थन करने में रूढ़िवादी रहूंगा

जहां तक ​​​​मुझे पता है, स्पार्क के अधिकांश उपयोगकर्ता अभी भी 2.11 का उपयोग कर रहे हैं क्योंकि वे स्पार्क के पिछले संस्करणों का पालन करने के लिए उपयोग किए जाते हैं

2.12 समर्थन शुरू करने के लिए मेरे पास हर परीक्षण से गुजरने के लिए मेरे पास बैंडविड्थ नहीं हो सकता है

मैं 1.0 रिलीज में 2.12 + 2.11 या 2.12 का समर्थन करना चुनूंगा ...

@ hcho3 FYI करें, मैंने सीमित बैंडविड्थ को देखते हुए रोडमैप से घने मैट्रिक्स समर्थन को हटा दिया है

@ hcho3 क्या आप समय मिलने पर https://github.com/dmlc/dmlc-core/pull/514 पर एक नज़र डाल सकते हैं? अगली रिलीज़ हिट होने से पहले यह विलय के लायक हो सकता है।

@ट्रिविअलफिस इसे

@CodingCat मुझे लगता है कि हमें रिलीज़ की तारीख को पीछे धकेलना चाहिए, क्योंकि स्पार्क 2.4.1 और 2.4.2 में समस्याएँ हैं। तुम क्या सोचते हो?

@srowen क्या आप जानते हैं कि स्पार्क 2.4.3 कब होगा?

मुझे लगता है कि थोड़ी देरी करना ठीक है

ठीक है, स्पार्क 2.4.3 के समाप्त होने तक प्रतीक्षा करें

क्या स्पार्क 2.3.x के लिए अंतिम 0.83 रिलीज़ होगी?

@CodingCat क्या होगा यदि हम दो समानांतर रिलीज़ 0.83 और 0.90 बनाते हैं, जहाँ 0.83 में #4377 से ठीक पहले सभी कमिट शामिल हैं? 0.83 संस्करण केवल जेवीएम पैकेज के रूप में जारी किया जाएगा, और पायथन और आर पैकेजों को 0.90 मिलेगा। यह मेरे लिए और काम नहीं होगा, क्योंकि मुझे वैसे भी 0.90 के लिए एक रिलीज नोट लिखना है।

हालांकि एक मुद्दा गुम मूल्य प्रबंधन के साथ उपयोगकर्ता अनुभव है। हो सकता है कि सभी को स्पार्क 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 वास्तव में, यह अन्य अनुरक्षकों के लिए काम बनाएगा, हमें पहले उनसे पूछना होगा

एक व्यक्तिगत दृष्टिकोण से संक्षिप्त उत्तर सिद्धांत में हाँ है , लेकिन यह एक प्रतिबद्धता से ठीक पहले काटने से अधिक हो सकता है (जैसा कि आपने कहा, यह दूसरों के लिए भी काम करेगा) (लेकिन सीमित होने के कारण मुझे ऐसा करने में संकोच है समुदाय में संसाधन ...)

0.8x . जैसे रखरखाव रिलीज के बारे में हमें कैसे सोचना चाहिए, इसके बारे में मेरे 2 सेंट यहां दिए गए हैं

1. रखरखाव जारी करने का कारण महत्वपूर्ण बग फिक्स लाना है, जैसे https://github.com/dmlc/xgboost/commit/2d875ec0197d5a83e7d585daf472b8201aa97c51 और https://github.com/dmlc/xgboost/commit/995698b0cb1da75f066d7e05a05a05a0498b0cb1da75f066d7e05

2. दूसरी ओर, सभी प्रतिबद्धताओं को जलाने के अलावा समुदाय को टिकाऊ बनाने के लिए, हमें समय-समय पर पिछले संस्करण का समर्थन छोड़ देना चाहिए

3. नवाचारों और सुधारों को एक फीचर रिलीज के माध्यम से उपयोगकर्ताओं के लिए लाया जाना चाहिए (0.8 से 0.9 तक कूदें)

यदि हम ०.८३ पर जाने का निर्णय लेते हैं, तो हमें @RAMitchell @trivialfis से भी राय एकत्र करने की आवश्यकता है और यह देखने के लिए कि क्या हमारे पास महत्वपूर्ण (सटीकता के बारे में अधिक) बग फिक्स हैं, जो उनके द्वारा देखे गए हैं, उनके न्यायाधीश का उपयोग करें।

और फिर चेरी-पिक करने के लिए 0.82 के आधार पर 0.83 शाखा बनाएं ... वास्तव में बहुत सारे काम

अगर मैं सही ढंग से समझूं, तो 0.9 स्पार्क के पुराने संस्करणों का समर्थन नहीं करेगा, इसलिए बग फिक्स सहित पुराने स्पार्क संस्करणों के लिए समर्थन जारी रखने के लिए 0.83 संस्करण के साथ-साथ 0.9 का समर्थन करने का प्रस्ताव?

आम तौर पर मैं डेवलपर समय का उपयोग करने वाली किसी भी चीज़ के खिलाफ हूं। क्या हम पहले से ही काफी व्यस्त नहीं हैं? हालांकि मुझे स्थिर संस्करण रखने में कुछ मूल्य दिखाई देता है।

@CodingCat क्या स्पार्क 2.4.x में अपग्रेड किए बिना बग फिक्स (2d875ec और 995698b) को शामिल करने का कोई तरीका है?

यदि रखरखाव जारी करना केवल शाखाओं को काटने से अधिक है (उदाहरण के लिए चेरी-पिक की आवश्यकता है), तो मैं ऐसी प्रतिबद्धता नहीं बनाऊंगा।

आम तौर पर मैं डेवलपर समय का उपयोग करने वाली किसी भी चीज़ के खिलाफ हूं। क्या हम पहले से ही काफी व्यस्त नहीं हैं?

मैं सहमत हूं।

@CodingCat क्या स्पार्क 2.4.x में अपग्रेड किए बिना बग फिक्स (2d875ec और 995698b) को शामिल करने का कोई तरीका है?

@ hcho3 दुर्भाग्य से नहीं, स्पार्क द्वारा निर्भर पुस्तकालय में ब्रेकिंग परिवर्तनों के कारण, हम केवल स्पार्क के संगत संस्करण के साथ xgboost को संकलित और चला सकते हैं

यदि भविष्य में, हम रखरखाव जारी करने में रुचि रखते हैं, तो वर्कफ़्लो (०.९ जारी करने के बाद)

1. बैकपोर्ट 0.9-शाखा के लिए आवश्यक फिक्स

2. प्रत्येक के लिए 0.9x रिलीज़ करें, मान लें, 2 महीने, या एक महत्वपूर्ण बग फिक्स द्वारा ट्रिगर किया गया

3. प्रमुख विशेषताएं और 0.9x पर बैकपोर्ट किए गए सभी सुधार मास्टर में उपलब्ध होने चाहिए

4. 1.0 जारी करते समय, मास्टर से एक शाखा काट लें ......

लेकिन फिर, एक बार जब हमारे पास मास्टर में एक बड़ा रिफैक्टर होता है और उसके बाद 0.9 पर फिक्स बैकपोर्ट करना चाहते हैं ... टन काम

@CodingCat देव समुदाय के वर्तमान आकार को देखते हुए, आइए रखरखाव रिलीज पर ध्यान दें।

@tovbinm क्षमा करें, मुझे नहीं लगता कि हम बैंडविड्थ की कमी के कारण 0.83 रिलीज़ कर पाएंगे। क्या स्पार्क 2.4.3 में अपग्रेड करना आपके लिए संभव है?

बदकिस्मती से। नहीं, अल्पावधि में नहीं। हम अभी भी 2.3.x पर हैं।

स्पार्क को 2.3 से 2.4 में अपग्रेड करने वाली प्रतिबद्धता क्या है? शायद हम वहां कटौती कर सकते हैं (यदि यह निश्चित रूप से 0.82 से ऊपर है)।

@tovbinm आप स्पार्क 2.3.x का उपयोग करने के लिए प्रतिबद्ध 711397d6452d596d7acbb68f1052ffebdee3e3af के साथ XGBoost बना सकते हैं।

महान। तो क्यों न उस कमिटमेंट को सार्वजनिक किया जाए?

जैसा कि @CodingCat ने कहा, रखरखाव रिलीज केवल एक प्रतिबद्धता से पहले काटने की बात नहीं है। साथ ही, सार्वजनिक रिलीज करना समर्थन के निहित वादे हैं। मुझे नहीं लगता कि अनुरक्षक इस समय दो नई रिलीज का समर्थन करने के लिए तैयार हैं।

मैं @CodingCat को टाल

GPU प्रेडिक्टर के साथ बाहरी मेमोरी - इसका मतलब यह होगा कि कोड किसके साथ क्रैश नहीं होगा (): std :: bad_alloc: अब मेमोरी से बाहर? (यानी अस्थायी रूप से RAM में स्वैप करें?)

संबंधित समस्या मुझे लगता है कि https://github.com/dmlc/xgboost/issues/4184 - यह मुख्य रूप से स्मृति के अस्थायी फटने पर था, खुद को फिट करने की प्रक्रिया को इतनी मेमोरी की आवश्यकता नहीं होती है

https://xgboost.readthedocs.io/en/latest/tutorials/external_memory.html के अनुसार @hlbkin आपको बाहरी मेमोरी को स्पष्ट रूप से सक्षम करने की आवश्यकता होगी

मुझे लगता है कि एक प्रमुख संस्करण टक्कर (यानी 1.0) के बिना अन्यथा स्विच करना संभव नहीं है, लेकिन जब आप ऐसा करते हैं, तो क्या आप अनुरूप पीईपी 440 संस्करण संख्या (ixyz), और अधिमानतः अर्थपूर्ण संस्करण का समर्थन करने पर विचार कर सकते हैं? 0.90 (0.9.0 के बजाय) की मानक व्याख्या यह होगी कि यह प्रमुख संस्करण 0.x (यानी पूर्व-स्थिर-रिलीज़) श्रृंखला की 90वीं छोटी रिलीज़ है, और 0.83 से अधिक महत्वपूर्ण नहीं है। इसके अलावा, यह आपको प्रति लघु संस्करण में अधिकतम 9 पॉइंट रिलीज़ तक सीमित करता है, और कुछ टूल (और लोगों) के लिए व्याख्या करने में कठिनाइयाँ पैदा करता है। धन्यवाद!

+1

@ CAM-Gerlach जब हम 1.0 जारी करेंगे तो हम इस पर विचार करेंगे। दूसरी ओर, हम 1.0 पर जल्दबाजी नहीं करना चाहते। हम चाहते हैं कि 1.0 सुविधाओं, स्थिरता और प्रदर्शन के मामले में किसी तरह का मील का पत्थर बने।

स्पष्टीकरण के लिए धन्यवाद, @ hcho3 ।

आप शायद यह सुनिश्चित करना चाहते हैं कि आपने python_requires तर्क को '>=3.5' में setup() किया है ताकि यह सुनिश्चित किया जा सके कि Python 2 वाले उपयोगकर्ता गलती से असंगत संस्करण में अपग्रेड न हो जाएं।

@ hcho3 GPU एल्गोरिदम के साथ बाहरी मेमोरी उपलब्ध नहीं है

@hlbkin तुम सही हो। बाहरी मेमोरी केवल GPU प्रेडिक्टर के लिए उपलब्ध होगी, प्रशिक्षण के लिए नहीं।

@rongou @sriramch क्या मैं सही हूं कि बाहरी मेमोरी के साथ GPU प्रशिक्षण उपलब्ध नहीं है?

@ hcho3 हाँ तुम सही हो। हम उस पर कार्य कर रहे हैं। यदि आप रुचि रखते हैं तो परिवर्तन यहाँ हैं। मुझे इस परिवर्तन को मास्टर के साथ सिंक करना होगा और कुछ परीक्षण लिखना होगा।

@श्रीराम बहुत बढ़िया! क्या हमें ०.९० रिलीज में बाह्य स्मृति प्रशिक्षण को शामिल करने का लक्ष्य रखना चाहिए, या क्या हमें ०.९० के बाद इस पर वापस आना चाहिए?

बस मेरे दो सेंट, आइए 0.x (जल्दी में) में कई नई सुविधाओं को संकलित करने पर थोड़ा सा आरक्षित करें और विचार करें कि 1.0 में एक मील का पत्थर संस्करण के रूप में क्या रखा जाना है

@ कोडिंग कैट मैं सहमत हूं। FYI करें, मैंने 0.90 रोडमैप से वितरित अनुकूलित उद्देश्य को हटा दिया, क्योंकि #4280 में पर्याप्त असहमति थी। हम 0.90 के बाद फिर से इस पर विचार करेंगे।

@sriramch आइए 0.90 रिलीज के बाद बाहरी मेमोरी ट्रेनिंग पर विचार करें। आपकी कड़ी मेहनत के लिए बहुत-बहुत धन्यवाद।

यह 8.0 के बजाय cuda 9.0 बायनेरिज़ को रिलीज़ करने का एक अच्छा समय हो सकता है। मुझे लगता है कि 9.0 अब उपयोगकर्ता ड्राइवर संस्करण द्वारा पर्याप्त रूप से समर्थित होगा। इसके अतिरिक्त 9.0 बायनेरिज़ को नए वोल्टा आर्किटेक्चर के लिए जेआईटी संकलित करने की आवश्यकता नहीं होगी।

@ hcho3 क्या हम जाने के लिए तैयार हैं?

लगभग। मुझे लगता है कि #4438 का विलय होना चाहिए।

अब सब अच्छा है। मैं आगे बढ़ूंगा और अगली रिलीज पर काम करना शुरू करूंगा। ईटीए: 16 मई 2019

• [x] setup.py में Python ३ की आवश्यकता है
• [x] CUDA ९.० पहियों के निर्माण के लिए CI बदलें (#४४५९)
• [x] विंडोज़ संकलन को ठीक करें (#४४६३)
• [x] GPU के साथ विंडोज़ के लिए न्यूनतम व्यवहार्य CI सेट करें (#4463)

@RAMitchell क्या हमें व्हील रिलीज के लिए CUDA 9.0 या 9.2 का उपयोग करना चाहिए?

आइए 9.2 का उपयोग करें क्योंकि यह पहले से ही CI पर स्थापित है। खतरा यह है कि हमें एनवीडिया ड्राइवरों की आवश्यकता है जो बहुत नए हैं। संदर्भ के लिए यहां कूडा संस्करण और ड्राइवरों के बीच पत्राचार दिखाने वाली तालिका है: https://docs.nvidia.com/deploy/cuda-compatibility/index.html#binary -compatibility__table-toolkit-driver

जहां तक ​​​​मुझे पता है कि यह किसी भी तरह से सीपीयू एल्गोरिदम को प्रभावित नहीं करना चाहिए। यदि उपयोगकर्ता समस्याओं की रिपोर्ट करना शुरू करते हैं तो हम भविष्य में ड्राइवर संगतता के आसपास बेहतर त्रुटि संदेशों के साथ इसका समाधान कर सकते हैं।

हम्म उस स्थिति में मैं CI कार्यकर्ता में से एक को CUDA 9.0 में डाउन-ग्रेड करने का प्रयास कर सकता हूं। चूंकि हम डॉकर कंटेनरों का बड़े पैमाने पर उपयोग कर रहे हैं, इसलिए यह बहुत कठिन नहीं होना चाहिए।

मैं अब 0.90 रिलीज तैयार करने जा रहा हूं। मेरा लक्ष्य इस सप्ताह के अंत तक रिलीज नोट को पूरा करना है।

#4475 . द्वारा बंद