Тази публикация е за сравнителен анализ на LightGBM и xgboost (точен метод) върху персонализиран набор от данни на Bosch. Виждал съм xgboost да е 10 пъти по-бавен от LightGBM по време на състезанието на Bosch, но сега се върнахме с някои числа за сравнение! Следващият ни бенчмарк ще бъде относно „метода на бързата хистограма на xgboost“. Използваната настройка е идентична с първите бенчмаркове на Bosch + xgboost, които направих.

Публикувано на „Дизайн на данни“ от „Laurae“.

Глобален преглед

Да преминем направо към диаграмата, това трябва да облекчи цялото нетърпение!

Както виждаме, средно LightGBM (binning) е между 11x до 15x по-бърз от xgboost (без binning).

Също така забелязваме, че съотношението става по-малко, когато използвате много нишки: това е очевидно, тъй като ако не можете да поддържате нишките заети на 100%, тогава се появява неефективност на нишките (някои нишки може да бъдат принудени да чакат бездействащи, защото обработката за планиране за следващата задача не е достатъчно бърз).

1–12 нишки

Нека да разгледаме първите 12 теми.

Това, което можем да забележим за xgboost е, че имаме подобрения в производителността, като преминем над 6 физически ядра (използването на 12 логически ядра помага с около 28,3%, преминавайки от 577,9 секунди на 414,3 секунди).

Това същото ли е за LightGBM? да Спаднахме от 45,1 секунди на 33,6 секунди, което е огромно увеличение на производителността (25,5%).

Заключение за тази част: използвайте всички логически ядра за нишки, това помага изключително много. Ако искате вашият обучителен конвейер за машинно обучение да приключи с около 25% по-бързо (различава се според процесорите, очевидно), вече знаете какво да направите: използвайте логически ядра вместо физически ядра за броя на нишките.

13–24 нишки

Ами ако търсим конкретно 13 до 24 нишки? Добавяме до 12 теми като референция за сравнение.

Можем бързо да забележим:

  • Няма подобрения за xgboost, повече или по-малко шумна вариация
  • Обратни подобрения за LightGBM, с увеличено време за усилване (от 33,6 секунди до 38+ секунди)

Следователно едно бързо заключение е следното: не преразпределяйте логическите ядра, това не е добра практика. Продължавайте да използвате логически ядра като брой нишки и не надхвърляйте това число.

Бърз поглед към LightGBM специално

Можем да направим бърз поглед към кривата на LightGBM.

Това изглежда е линейно подобрение: от 202 секунди (използвано 1 пълно ядро, 1 нишка), спаднахме до 33,6 секунди (използвани 6 пълни ядра, 12 нишки), което е почти 100% многонишкова ефективност. Когато удряме стената с повече нишки, ефективността на многопоточността намалява драстично и имаме тези обратни подобрения.

Ефективност на RAM за данни?

Един бърз поглед върху използването на RAM изобразява следното, използвайки gc() два пъти след създаването на матриците:

  • Първоначални данни (плътни, неизползвани): приблизително 8769 MB (27,9% спрямо оригинала)
  • Оригинални данни (dgCMatrix): прибл. 2448 MB (100% спрямо оригинала)
  • xgboost (xgb.DMatrix): прибл. 1701 MB (69,5% спрямо оригинала)
  • LightGBM (lgb.Dataset): прибл. 2512 MB (102,6% спрямо оригинала)

Изглежда, че LightGBM има по-голям отпечатък на паметта от xgboost.

Обучение на ефективност на RAM

Използваме 12 нишки, за да проверим ефективността на RAM, взети в края на 50-те итерации на усилване, като използваме gc преди усилване, не използваме gc след усилване:

  • xgboost: прибл. 1684 MB
  • LightGBM: прибл. 1425 MB (84,6% от използването на паметта на xgboost)

Можем да забележим, че LightGBM използва по-малко RAM по време на обучение, за сметка на увеличено използване на RAM за данните в паметта. Възможно е да има подобрения в потенциалните модификации на пакета R LightGBM, за да има по-ефективен начин за съхраняване на данни.

Следващ показател?

Следващият бенчмарк ще дойде, когато методът на бързата хистограма на xgboost започне да работи и може да се използва в R. В момента той е активен и работи, но не може да се използва в R. Това би било най-близкото сравнение „ябълки с ябълки“ между xgboost и LightGBM.

Ще сравняваме също логаритмичната загуба между xgboost и LightGBM.