@ लॉरा 2 GBT बेंचमार्क तैयार करने के लिए धन्यवाद। यह समस्या की जगह की पहचान करने में मददगार रहा है।

@ hcho3 क्या OpenMP guided शेड्यूल लोड संतुलन में मदद करता है? यदि ऐसा है तो ellpack बहुत उपयोगी नहीं होगा।

मेरा अनुमान है कि ellpack का उपयोग करके काम का स्थैतिक आवंटन guided या dynamic OpenMP की तुलना में कम ओवरहेड के साथ संतुलित कार्यभार प्राप्त करेगा। dynamic , आपको रनिंग कतार को बनाए रखने का रनटाइम ओवरहेड मिलता है

थोड़ा सा विषय हो सकता है, क्या हमारे पास approx बेंचमार्क परिणाम हैं?

हम अपने आंतरिक वातावरण में मल्टी-थ्रेडिंग के साथ उप-इष्टतम स्पीडअप का पता लगाते हैं ... दूसरों के डेटा को देखना चाहते हैं

@CodingCat लिंक किया गया बेंचमार्क सूट केवल hist का उपयोग करता है। क्या approx शो प्रदर्शन में गिरावट hist (जैसे 3 धागे से 36 धागे धीमी) है?

@ hcho3 हमारे क्लस्टर में सीमा के कारण, हम केवल 8 थ्रेड्स के साथ परीक्षण कर सकते हैं ... लेकिन हम 8 से 4 की तुलना में बहुत सीमित स्पीडअप पाते हैं .....

@ कोडिंगकैट का मतलब है कि 8 धागे 4 की तुलना में धीमे चलते हैं?

@CodingCat approx इतनी खराब स्केलिंग है कि मैं इसे बेंचमार्किंग करने की कोशिश भी नहीं करना चाहता था। यह मेरे 4 कोर लैपटॉप (3.6 गीगाहर्ट्ज) पर भी ठीक से पैमाना नहीं करता है, इसलिए मैं 64 या 72 थ्रेड्स के साथ कल्पना भी नहीं करता हूं।

@ hcho3 मैं बाद में VTune के साथ आपकी रिपॉजिटरी का उपयोग करके इसे

जो लोग वीट्यून में विस्तृत प्रदर्शन प्राप्त करना चाहते हैं, वे हेडर में जोड़ने के लिए निम्नलिखित का उपयोग कर सकते हैं:

#include <ittnotify.h> // Intel Instrumentation and Tracing Technology

जो आप लूप के बाहर ट्रैक करना चाहते हैं उससे पहले निम्नलिखित जोड़ें (स्ट्रिंग / चर का नाम बदलें):

__itt_resume();
__itt_domain* domain = __itt_domain_create("MyDomain");
__itt_string_handle* task = __itt_string_handle_create("MyTask");
__itt_task_begin(domain, __itt_null, __itt_null, task);

आप जो लूप के बाहर ट्रैक करना चाहते हैं उसके बाद निम्नलिखित जोड़ें (स्ट्रिंग / चर का नाम बदलें):

__itt_task_end(domain);
__itt_pause();

और धागे की संख्या के लिए सही मापदंडों के साथ VTune के साथ एक परियोजना शुरू करें। प्रदर्शन विश्लेषण करने के लिए रुके हुए इंस्ट्रूमेंटेशन के साथ निष्पादन योग्य शुरू करें।

@ hcho3 यह धीमी नहीं है, लेकिन शायद 4 और थ्रेड्स के साथ केवल 15-% स्पीडअप ... (यदि मैं अधिक प्रयोग करता हूं, तो मुझे संदेह होगा कि परिणाम भी अभिसरण हो जाएंगे .....

@ लॉरा 2 ऐसा लगता है कि मैं अकेला नहीं हूं

@ hcho3 मैं इस सप्ताह के अंत से पहले आपको कुछ स्केलिंग परिणाम प्राप्त करने की कोशिश करूँगा यदि कोई exact , approx और hist , depth=6 साथ सभी न करे।

मैंने हाल ही में अपने कम्प्यूट सर्वर को माइग्रेट किया है, और मैं इस सप्ताह बॉश पर एक नई मशीन पर 3.7 गीगाहर्ट्ज़ सभी टर्बो / 36 कोर / 72 थ्रेड / 80 जीबीपीएस रैम बैंडविड्थ के साथ नए बेंचमार्क पर फिर से काम कर रहा हूं।

वितरित xgboost के लिए fast_hist updater अधिक तेज़ होना चाहिए। @CodingCat मुझे आश्चर्य है कि किसी ने AllReduce कॉल्स को जोड़ने की कोशिश नहीं की है इसलिए यह वितरित मोड में काम करता है।

@RAMitchell मैं बहुत नया था जब मैंने fast_hist updater लिखा था, इसलिए इसमें वितरित मोड समर्थन का अभाव है। मैं 0.81 रिलीज के बाद इसे प्राप्त करना चाहता हूं।

@ लॉरा 2 FYI करें, मैंने आपके बेंचमार्क सूट को C5.9xlarge मशीन पर चलाया और XGBoost hist परिणाम आपके पिछले परिणामों के अनुरूप प्रतीत हो रहे हैं। यदि आप चाहें तो मैं नंबर डाल सकता हूं।

@ Laurae2 इसके अलावा, मेरे पास EC2 मशीनों की पहुंच है। यदि आपके पास एक स्क्रिप्ट है जिसे आप EC2 उदाहरण पर चलाना चाहते हैं, तो मुझे बताएं।

@RAMitchell मैं बहुत नया था जब मैंने fast_hist updater लिखा था, इसलिए इसमें वितरित मोड समर्थन का अभाव है। मैं 0.81 रिलीज के बाद इसे प्राप्त करना चाहता हूं।

@ hcho3 यदि आपको कोई आपत्ति नहीं है, तो मैं वितरित किए गए तेज़ हिस्टोग्राम एल्गोरिथ्म को प्राप्त करने के लिए चुनौती ले सकता हूं, मैं वर्तमान में अपने उबेर नौकरी में आधे समय पर हूं और अगले वर्ष में xgboost पर अधिक समय हो सकता है

@CodingCat यह बहुत अच्छा होगा, धन्यवाद! मुझे बताएं कि क्या आपके पास 'हिस्ट' कोड के बारे में कोई प्रश्न है।

@CodingCat FYI करें, मैं 0.81 रिलीज के तुरंत बाद 'हिस्ट' अपडेटर के लिए यूनिट टेस्ट जोड़ने की योजना बना रहा हूं। वितरित सहायता जोड़ने की बात आने पर उसे मदद करनी चाहिए।

@ hcho3 @CodingCat approx पिछले महीने में हटा दिया गया लगता है, क्या यह एक अपेक्षित व्यवहार है?

https://github.com/dmlc/xgboost/commit/70d208d68c3a32aaa4fcd6aa456f286a4da5912f#diff -53a3a623be5ce5a351a89012c7b03a31 (पीआर https://github.com/dmlc/xgboost/pull/3395 हटा दिया गया है tree_method = approx ?) => समान हो रही लगभग और गैर अनुमानित के बीच परिणाम ...

@ लौरा 2 ऐसा लगता है कि approx चुने जाने के बारे में एक INFO संदेश निकाल दिया है। अन्यथा, approx अभी भी उपलब्ध होना चाहिए।

@ लौरा 2 वास्तव में, आप सही हैं। भले ही approx अभी भी कोडबेस में है, किसी कारण से इसे तब भी लागू नहीं किया जा रहा है जब tree_method=approx सेट किया गया हो। मैं इस बग ASAP की जांच करूंगा।

अंक # 3840 दर्ज किया गया था। जब तक यह तय नहीं किया जाता है, तब तक 0.81 रिलीज़ नहीं होगी।

@ hcho3 मुझे तेजी से हिस्टोग्राम के साथ अपने सर्वर पर कुछ बहुत अजीब लग रहा है, मैं आपको परिणाम

लगभग, खराब दक्षता उम्मीद से बेहतर है, लेकिन मैं किसी भी कंप्यूटर के लिए सही होने की उम्मीद नहीं करता हूं (शायद यह नए इंटेल सीपीयू पीढ़ी = उच्च रैम आवृत्ति के साथ बेहतर हो जाता है?)। मैं एक बार तेजी से हिस्टोग्राम खत्म होने के बाद अपने सर्वर पर डेटा पोस्ट करूंगा।

जानकारी के लिए, मैं 477 सुविधाओं के साथ बॉश डेटासेट का उपयोग कर रहा हूं (5% से कम लापता मान वाली विशेषताएं)।

3000 घंटे से अधिक CPU समय पर पहुंच गया ... (कम से कम मेरे सर्वर को थोड़ी देर के लिए अच्छे उपयोग के लिए रखा गया है) मेरे लिए अगले https://github.com/hcho3/xgboost-fast-hist-perf- पर देखना होगा

@ hcho3 यदि आप चाहते हैं, तो मेरा सर्वर कंप्यूटिंग पूरा करने के बाद मैं आपको मेरी बेंचमार्क R स्क्रिप्ट प्रदान कर सकता हूं। मैं depth=8 और nrounds=50 , सभी tree_method=exact , tree_method=approx ( updater=grow_histmaker,prune वर्कअराउंड से पहले, # 3849), और tree_method=hist , 1 से 72 धागे तक। यह काम करने के लिए और अधिक दिलचस्प सामग्री को उजागर कर सकता है (और आप इसे एडब्ल्यूएस पर भी परीक्षण करने में सक्षम होंगे)।

कृपया नीचे प्रारंभिक परिणाम देखें, औसत परिणामों के लिए 7 बार भाग गया। बेहतर देखने के लिए क्लिक करना सुनिश्चित करें। सिंथेटिक टेबल प्रदान की गई। प्लॉट शो के विपरीत, सीपीयू को पिन नहीं किया गया था।

चार्ट स्पष्ट रूप से उन लोगों की तुलना में अलग-अलग हैं, जिनके लिए मैं तैयार था ... (कितने अजीब व्यवहार के कारण मैं इसे फिर से UMA पर (NUMA बंद) के साथ चला रहा हूं)। बाद में मैं Intel VTune से जांच करूंगा।

हार्डवेयर और सॉफ्टवेयर:

• सीपीयू: डुअल एक्सॉन गोल्ड 6154, 3.7 गीगाहर्ट्ज सभी टर्बो, 2x 18 कोर / 36 धागे
• रैम: 4x 64 जीबी रैम डीडीआर 4 2666 मेगाहर्ट्ज (डुअल-चैनल, लगभग 80 जीबीपीएस बैंडविड्थ)
• BIOS: NUMA ऑन, उप NUMA क्लस्टरिंग
• ऑपरेटिंग सिस्टम: Pop_OS! 18.10
• राज्यपाल: प्रदर्शन
• कर्नेल: 4.18.0-10
• कर्नेल झंडे: pti=off spectre_v2=off spec_store_bypass_disable=off l1tf=off noibrs noibpb nopti no_stf_barrier
• कंपाइलर: जीसीसी 8.2.0
• R: 3.5.1 gcc के साथ संकलित 8.2.0 और Intel MKL के साथ
• R में अतिरिक्त संकलन झंडे: -O3 -mtune=native

मेल्टडाउन / स्पेक्टर सुरक्षा:

laurae@laurae-compute:~$ head /sys/devices/system/cpu/vulnerabilities/*
==> /sys/devices/system/cpu/vulnerabilities/l1tf <==
Mitigation: PTE Inversion; VMX: vulnerable

==> /sys/devices/system/cpu/vulnerabilities/meltdown <==
Vulnerable

==> /sys/devices/system/cpu/vulnerabilities/spec_store_bypass <==
Vulnerable

==> /sys/devices/system/cpu/vulnerabilities/spectre_v1 <==
Mitigation: __user pointer sanitization

==> /sys/devices/system/cpu/vulnerabilities/spectre_v2 <==
Vulnerable

| धागे | सटीक (दक्षता) | लगभग (दक्षता) | हिस्ट (दक्षता) |
| ---: | ---: | ---: | ---: |
| 1 | 1367 (100%) | 1702s (100%) | 69.9 (100%) |
| 2 | 758.7 (180%) | 881.0s (193%) | 52.5s (133%) |
| 4 | 368.6s (371%) | 445.6s (382%) | 31.7 (221%) |
| 6 | 241.5s (566%) | 219.6s (582%) | 24.1s (290%) |
| 9 | 160.4s (852%) | 194.4s (875%) | 23.1s (303%) |
| 18 | 86.3s (1583%) | 106.3s (1601%) | 24.2s (289%) |
| 27 | 66.4s (2059%) | 80.2s (2122%) | 63.6s (110%) |
| 36 | 52.9 (2586%) | 60.0 (2837%) | 55.2s (127%) |
| 54 | 215.4s (635%) | 289.5s (588%) | 343.0 (20%) |
| 72 | 218.9s (624%) | 295.6s (576%) | 1237.2s (6%) |

xgboost सटीक गति:

xgboost सटीक दक्षता:

xgboost लगभग गति:

xgboost लगभग दक्षता:

xgboost हिस्टोग्राम गति:

xgboost हिस्टोग्राम दक्षता:

कई सॉकेट के साथ एक समस्या की तरह लग रहा है।

@RAMitchell NUMA नोड्स की उपलब्धता के साथ एक मुद्दा लगता है, मैं इस मुद्दे को दोहरा सकता हूं (एक तरह से प्रशिक्षण के दौरान कम धागे के साथ खराब परिणाम) उप NUMA क्लस्टरिंग (1 सॉकेट = 2 NUMA नोड्स के बजाय 2 सॉकेट = 4 NAMA नोड्स) का उपयोग कर )।

अधिकांश मशीन सीखने की तरह xgboost NUMA नोड्स को संभालने के लिए कोई अनुकूलन नहीं है। लेकिन यह एक 2 मुद्दा होगा। इसलिए, वे मल्टी-सॉकेट वातावरण के लिए उपयुक्त नहीं हैं और न ही जब NUMA नोड्स COD (क्लस्टर ऑन डाई) या एसएनसी (सब NUMA क्लस्टरिंग) के माध्यम से उपलब्ध हैं, और हाइपरथ्रेडिंग उनके लिए एक भारी जुर्माना करता है।

अंक 1 xgboost hist मोड (इस अंक) में मल्टीथ्रेड प्रदर्शन के भारी गिरावट के बारे में होगा।

अंक 2 NUMA अनुकूलन (खोलने के लिए एक और मुद्दा) के बारे में होगा।

यहाँ NUMA के साथ परिणाम अक्षम हैं। मैंने तुलना के लिए NUMA के साथ परिणाम जोड़े। 72 थ्रेड्स में कर्नेल शेड्यूलर से अभिभूत होने से पहले 71 थ्रेड्स को प्रदर्शन को दिखाने के लिए जोड़ा गया (उपलब्ध अधिक आवश्यक संसाधन)।

UMA का किराया मल्टीथ्रेडिंग के लिए NUMA से बेहतर है, यह एक गैर-NUMA जागरूक प्रक्रिया पर मेमोरी इंटरलाकिंग का अपेक्षित परिणाम है।

समय समय:

| धागे | सटीक
NUMA | सटीक
उमा | लगभग
NUMA | लगभग
UMA | ऐतिहासिक
NUMA | ऐतिहासिक
उमा |
| ---: | ---: | ---: | ---: | ---: | ---: | ---: |
| 1 | 1367 | 1667 | 1702s | 1792 | 69.9 एस | 85.6 |
| 2 | 758.7 | 810.3s | 881.0s | 909.0s | 52.5s | 54.1 एस |
| 4 | 368.6s | 413.0s | 445.6s | 452.9s | 31.7 | 36.2s |
| 6 | 241.5s | 273.8s | 219.6s | 302.4s | 24.1 | 30.5s |
| 9 | 160.4s | 182.8s | 194.4s | 202.5 एस | 23.1 एस | 28.3s |
| 18 | 86.3s | 94.4s | 106.3s | 105.8s | 24.2s | 31.2s |
| 27 | 66.4s | 66.4s | 80.2s | 73.6s | 63.6s | 37.5s |
| 36 | 52.9s | 52.7 | 60.0s | 59.4s | 55.2s | 43.5s |
| 54 | 215.4 एस | 49.2s | 289.5s | 58.5s | 343.0s | 57.4s |
| 71 | 218.3s | 47.01s | 295.9 | 56.5 एस | 1238.2 s | 71.5s |
| 72 | 218.9s | 49.0s | 295.6 | 58.6s | 1237.2 s | 79.1 एस |

दक्षता तालिका:

| धागे | सटीक
NUMA | सटीक
उमा | लगभग
NUMA | लगभग
उमा | ऐतिहासिक
NUMA | ऐतिहासिक
उमा |
| ---: | ---: | ---: | ---: | ---: | ---: | ---: |
| 1 | 100% | 100% | 100% | 100% | 100% | 100% |
| 2 | 180% | 206% | 193% | 197% | 133% | 158% |
| 4 | 371% | 404% | 382% | 396% | 221% | 236% |
| 6 | 566% | 609% | 582% | 593% | 290% | 280% |
| 9 | 852% | 912% | 875% | 885% | 303% | 302% |
| 18 | 1583% | 1766% | 1601% | 1694% | 289% | 274% |
| 27 | 2059% | 2510% | 2122% | 2436% | 110% | 229% |
| 36 | 2586% | 3162% | 2837% | 3017% | 127% | 197% |
| 54 | 635% | 3384% | 588% | 3065% | 20% | 149% |
| 71 | 626% | 3545% | 575% | 3172% | 6% | 120% |
| 72 | 624% | 3401% | 576% | 3059% | 6% | 108% |

यूएमए मोड।

xgboost सटीक गति:

xgboost सटीक दक्षता:

xgboost लगभग गति:

xgboost लगभग दक्षता:

xgboost हिस्टोग्राम गति:

xgboost हिस्टोग्राम दक्षता:

जैसा कि https://github.com/dmlc/xgboost/pull/3957#issuecomment -453815876 में टिप्पणी की गई है, मैंने a2dc929 (पूर्व CPU सुधार) और 5f15cc5 (पोस्ट CPU सुधार) का परीक्षण किया।

मैंने अपने दोहरे Xeon 6154 सर्वर (gcc संकलक, इंटेल नहीं) का उपयोग करके परीक्षण किया, 500 पुनरावृत्तियों, eta 0.10 और गहराई 8 के लिए बॉश का उपयोग करते हुए, 1 से 72 थ्रेड के लिए 3 रन बनाए। हम चोटी के प्रदर्शन पर मल्टीथ्रेडेड वर्कलोड के लिए लगभग 50% (1/3 तेज) तक के प्रदर्शन में वृद्धि को नोटिस करते हैं।

यहाँ से पहले # 3957 के लिए परिणाम हैं (a2dc929):

यहाँ परिणाम # 3957 के लिए हैं (5f151c5 पर):

दक्षता घटता का उपयोग करते हुए, हम देखते हैं कि 50% स्केलेबिलिटी में वृद्धि (इसका मतलब यह नहीं है कि समस्या हल हो गई है: हमें अभी भी इसे सुधारना होगा, अगर हम कर सकते हैं - आदर्श रूप में, अगर हम 1000-2000% सीमा तक पहुंच सकते हैं जो कि पागलपन होगी महान)।

दक्षता वक्र a2dc929:

5f151c5 की क्षमता वक्र:

धन्यवाद @ लॉरा 2 , मैं आगे जाऊंगा और इस मुद्दे को पिन करूंगा, ताकि यह हमेशा इश्यू ट्रैकर के शीर्ष पर रहे। वास्तव में और काम करना है।

@ hcho3 @SmirnovEgorRu मैं कम 5% 151c5 के साथ 100% घने डेटा पर सिंगलथ्रेडेड वर्कलोड पर एक छोटे से सीपीयू प्रदर्शन प्रतिगमन को देख रहा हूं, जो एक्स कोर x 1 xgboost थ्रेड पर हाइपरपरिमेट ट्यूनिंग करते हुए कुल मिलाकर 10% -15% जुर्माना लगाता है।

यहां 50M पंक्तियों x 100 कॉलम यादृच्छिक घने डेटा (gcc 8) का एक उदाहरण है, इसे पायथन / आर से ठीक से प्रशिक्षित करने के लिए कम से कम 256GB RAM की आवश्यकता होती है, 3 बार (6 दिन) चलाएं।

प्रतिबद्ध a2dc929:

5f151c5 प्रतिबद्ध करें:

हालांकि वे बहुत समान बहु-स्तरीय प्रदर्शन का नेतृत्व करते हैं, एकल प्रदर्शन एक धीमी प्रशिक्षण ( @SmirnovEgorRu के सुधार अभी भी बड़े पैमाने पर होता है, इस 50M x 100 मामले में 11% बनाम 13 थ्रेड्स से पहले 500% दक्षता) तक पहुंच जाता है।

गम निर्माण समय को छोड़कर, हमारे पास 50 एम x 100 पर एकलथ्रेड के लिए:

| कमिट | कुल | गम समय | ट्रेन का समय |
| : --- | ---: | ---: | ---: |
| a2dc929 | 2926 | 816s | 2109s |
| 5f151c5 | (+ 13%) 3316s | (~%) 817s | (+ 18%) 2499s |

@ hcho3 @ Laurae2 आम तौर पर हाइपर-थ्रेडिंग केवल कोर-बाउंड एल्गोरिदम के मामले में मदद करता है, कोई मेमोरी-बाउंड एल्गोरिदम नहीं।
एचटी निष्पादन के लिए अधिक निर्देशों द्वारा सीपीयू की पाइपलाइन को लोड करने में मदद करता है। यदि अधिकांश निर्देश पिछले निर्देशों के निष्पादन के लिए प्रतीक्षा करते हैं (विलंब सीमा) - एचटी वास्तव में मदद कर सकता है, कुछ विशिष्ट कार्यभार में मैंने 1.5 गुना तक स्पीडअप मनाया।
हालांकि, यदि आपका एप्लिकेशन मेमोरी (मेमोरी-बाउंड) के साथ काम करने में सबसे अधिक समय बिताता है - एचटी और भी बदतर बनाता है। 2 हाइपर-थ्रेड्स एक सीपीयू-कैश साझा करते हैं और एक दूसरे से उपयोगी जानकारी को विस्थापित करते हैं। परिणामस्वरूप, हम प्रदर्शन में गिरावट देखते हैं।
ग्रेडिएंट बूस्टिंग - मेमोरी बाउंड एल्गोरिदम। HT के उपयोग से किसी भी मामले में प्रदर्शन में सुधार नहीं होना चाहिए और 1thread वर्जन के थ्रेडिंग के कारण आपका अधिकतम स्पीडअप हार्डवेयर कोर की संख्या द्वारा सीमित है। इसलिए, बिना HT के CPU पर प्रदर्शन को मापने के लिए मेरी राय बेहतर है।

NUMA के बारे में क्या है - मैंने DAAL कार्यान्वयन में समान समस्याएं देखीं। इसके लिए प्रत्येक कोर द्वारा मेमोरी उपयोग पर नियंत्रण की आवश्यकता होती है। मैं भविष्य में इसे देखूंगा।

1 थ्रेड पर छोटे मंदी के बारे में क्या है - मैं इसकी जांच करूंगा। मुझे लगता है - फिक्स आसान है।

@ hcho3 फिलहाल मैं अनुकूलन के अगले भाग पर काम कर रहा हूं। मुझे उम्मीद है कि मैं निकट भविष्य में नए पुल-अनुरोध के लिए तैयार रहूंगा।

@SmirnovEgorRu आपके प्रयास के लिए फिर से धन्यवाद। FYI करें, स्तर-वार नोड विस्तार करके समानता की बढ़ती मात्रा के बारे में हाल ही में चर्चा हुई थी: # 4077।

@ लॉरा 2 अब जब हम # 3957, # 4310, और # 4529 में विलीन हो गए, क्या हम मान सकते हैं कि स्केलिंग समस्या हल हो गई है? NUMA के प्रभाव अभी भी समस्याग्रस्त हो सकते हैं।

@ hcho3 मैं बाद में जांच करने के लिए रिबॉन्च करूंगा, लेकिन जो मैं नोटिस कर सकता था, उसमें प्रोडक्शन एन्वायरमेंट्स पर परफॉर्मेंस रिजेक्शन थे (खासकर # 3957 30x से ज्यादा स्लोडाउन के कारण)।

मैं @szilard के साथ भी प्रदर्शन परिणामों की जाँच करूँगा।

खुला उदाहरण: https://github.com/szilard/GBM-perf/issues/9

मल्टीकोर स्केलिंग और वास्तव में NUMA मुद्दे को वास्तव में काफी हद तक सुधार दिया गया है:

मल्टीकोर:

छोटे डेटा (0.1M पंक्तियों) पर बहुत उल्लेखनीय सुधार

अधिक जानकारी यहाँ:

https://github.com/szilard/GBM-perf#multi -core-scaling-cpu
https://github.com/szilard/GBM-perf/issues/29#issuecomment -68989131324

इसके अलावा NUMA मुद्दे को बड़े पैमाने पर कम किया गया है:

@szilard बेंचमार्क करने के लिए समय निकालने के लिए बहुत बहुत धन्यवाद! और यह बहुत अच्छी खबर है कि CPU प्रदर्शन स्केलिंग में XGBoost में सुधार हुआ है।

हाँ, इस काम को पूरा करने के लिए इस धागे पर हर कोई काम करता है।

FYI करें, यहाँ ECM r4.16xlarge (16c + 16HT के साथ 2 सॉकेट) पर 1M पंक्तियों पर प्रशिक्षण का समय 1, 16 (1so & no HT) और 64 (सभी) xgboost के विभिन्न संस्करणों के लिए कोर:

https://github.com/szilard/GBM-perf/issues/40

@szilard , विश्लेषण के लिए बहुत बहुत धन्यवाद! यह सुनकर अच्छा लगा कि अनुकूलन काम करते हैं।

PS ऊपर मैंने देखा कि XGB 1.2 में 1.1 संस्करण के खिलाफ कुछ प्रतिगमन है। यह बहुत दिलचस्प जानकारी है, मुझे यह स्पष्ट करने दें। यह मेरे लिए अपेक्षित नहीं है।

@ szilard , यदि यह विषय आपके लिए दिलचस्प है - इस ब्लॉग में CPU अनुकूलन के कुछ पृष्ठभूमि और परिणाम उपलब्ध हैं:
https://medium.com/intel-analytics-software/new-optimizations-for-cpu-in-xgboost-1-1-81144ea21115

धन्यवाद @SmirnovEgorRu आपके अनुकूलन कार्य के लिए और ब्लॉग पोस्ट के लिंक के लिए (मैंने पहले इस पोस्ट को नहीं देखा था)।

अपने नंबरों को पुन: पेश करना और भविष्य और अन्य हार्डवेयर में नए प्राप्त करना आसान बनाने के लिए, मैंने इसके लिए एक अलग डॉकफ़र बनाया:

https://github.com/szilard/GBM-perf/tree/master/analysis/xgboost_cpu_by_version

आपको पहले सॉकेट के लिए सीपीयू कोर आईडी सेट करने की आवश्यकता होगी, कोई हाइपर थ्रेडेड कोर (जैसे कि r4.16xlarge पर 0-15, जिसमें 2 सॉकेट, 16c + 16HT प्रत्येक) और xgboost संस्करण है:

VER=v1.2.0
CORES_1SO_NOHT=0-15    ## set physical core ids on first socket, no hyperthreading
sudo docker build --build-arg CACHE_DATE=$(date +%Y-%m-%d) --build-arg VER=$VER -t gbmperf_xgboost_cpu_ver .
sudo docker run --rm -e CORES_1SO_NOHT=$CORES_1SO_NOHT gbmperf_xgboost_cpu_ver

यह कई बार स्क्रिप्ट चलाने के लायक हो सकता है, सभी कोर पर प्रशिक्षण समय आमतौर पर कुछ उच्च परिवर्तनशीलता दिखाते हैं, यह सुनिश्चित नहीं होता है कि क्या वर्चुअलाइजेशन वातावरण (ईसी 2) या एनयूएमए के कारण है।

C5.metal पर परिणाम जिसकी आवृत्ति और r4.16xlarge की तुलना में अधिक कोर हैं, मैं बेंचमार्क में उपयोग कर रहा हूं:

https://github.com/szilard/GBM-perf/issues/41

TLDR: xgboost अन्य लिबास बनाम तेज और अधिक कोर का सबसे अधिक फायदा उठाता है। 👍

मुझे आश्चर्य है कि हालांकि इस बारे में:

xgboost के लिए 1 से 24 कोर तक की गति बड़े डेटा (10M पंक्तियों, दाईं ओर के पैनल) के लिए छोटे डेटा (1M पंक्तियों, मध्य स्तंभ में पैनलों) के लिए छोटी है। क्या यह कुछ प्रकार की बढ़ी हुई कैश हिट्स या कुछ और है जो अन्य देयताओं में नहीं है?

एएमडी पर कुछ परिणाम यहां दिए गए हैं:

https://github.com/szilard/GBM-perf/issues/42

लगता है कि एक्सगबॉस्ट ऑप्टिमाइज़ेशन एएमडी पर भी बढ़िया काम कर रहे हैं।