倚天遇到屠龙：LightGBM VS xgboost谁才是最强的梯度提升库？
更多深度文章，請關注云計算頻道：https://yq.aliyun.com/cloud
作者介紹：Laurae?，數據科學愛好者
Blog:https://medium.com/@Laurae2
背景知識：
XGBoost是一款經過優化的分布式梯度提升（Gradient Boosting）庫，具有高效，靈活和高可移植性的特點。基于梯度提升框架，XGBoost實現了并行方式的決策樹提升(Tree Boosting)，從而能夠快速準確地解決各種數據科學問題。
LightGBM（Light Gradient Boosting Machine）同樣是一款基于決策樹算法的分布式梯度提升框架。
這篇博客是關于LightGBM 和xgboost 的對比。實驗使用了定制的博世數據集，結果顯示，在速度上xgboost?比LightGBM在慢了10倍，而我們還需要做一些其它方面的比較。
總體介紹
首先讓我們來看一下這個圖表，所有人都應該打起精神!!!
?
從圖上我們可以看到，平均來說，LightGBM?比xgboost 快11到15倍。
我們也注意到，隨著線程數的增加，比率變小了。這也很容易解釋，因為你不可能讓線程的利用率是100%，線程的切入切出以及線程有時要等待，這都需要耗費很多時間。
1–12 個線程
我們來看一下前12個線程。
?
?
從表中，我們可以看到，當線程數超過6的時候xgboost的性能得到了很大的提升（當線程數是12的時候，消耗時長從577.9降低到414.3秒，大約提高了28.3%）。
對于LightGBM來說是否也是這樣呢？時間從45.1降低到了33.6秒，性能提高大約25.5%。
小結：使用所有邏輯核心進行線程化，這能極大地提高性能。 如果你希望你的機器學習訓練速度提高25％（顯然，根據CPU的不同，情況也不完全一樣），你現在知道該做什么：使用邏輯核心，而不是物理核心來創建線程。
13–24 個線程
那么13-24個線程又會怎么樣呢？我們增加12個線程作為參照。
?
?
我們可以注意到：
所以我們可以簡單的下一個結論：不要過度分配邏輯內核，這不是一個好的做法。保持使用邏輯核心創建一定量的線程，并且不要超過該數。
LightGBM?一瞥
我們再來關注一下LightGBM的曲線。
?
從圖上來看，這似乎是一個線性的改進：從202秒（使用1個核，1個線程），我們下降到33.6秒（6個全部使用的，12個線程），這是幾乎100％的多線程的效率。 當我們用更多的線程時，多線程的效率急劇下降，使用的時間反而比一千場了。
數據存儲器的效率
在創建矩陣后使用gc方法兩次來快速查看RAM使用情況，具體情況如下：
?
?
- 初始數據（密集，未使用）：約8,769 MB（27.9％vs原始版本）
- 原始數據（dgCMatrix）：大約 2,448 MB（100％vs原始版本）
- xgboost（xgb.DMatrix）：大約?1,701 MB（69.5％vs原始版本）
- LightGBM（lgb.Dataset）：大約2,512 MB（102.6％vs原始版本）
看來LightGBM具有比xgboost更高的內存占用。
訓練存儲器的效率
我們使用12個線程來檢查RAM效率，在50次boosting迭代結束時，在boosting之前使用gc，boosting之后不使用gc，效果如下：
xgboost：約 1684 MB
LightGBM： 1425 MB（xgboost內存使用量的84.6％）
我們可以注意到，LightGBM在訓練期間的RAM使用率較低，但是內存中數據的RAM使用量增加。 所以R語言的LightGBM包有改進的潛能，以具有更有效的方式來存儲數據。
下一個指標
當xgboost的快速直方圖方法啟動并在R語言中可用時，我們會使用新的指標。雖然它目前正在運行，但在R語言中不可用。這樣一來xgboost和LightGBM孰優孰劣到時就會揭曉。
當然，未來我們也會比較xgboost和lightgbm之間的對數損失。
數十款阿里云產品限時折扣中，趕緊點擊領劵開始云上實踐吧！
以上為譯文
本文由北郵@愛可可-愛生活?老師推薦，阿里云云棲社區組織翻譯。
文章原標題《Benchmarking LightGBM: how fast is LightGBM vs xgboost?》，作者：Laurae，譯者：愛小乖
文章為簡譯，更為詳細的內容，請查看原文
總結
以上是生活随笔為你收集整理的倚天遇到屠龙：LightGBM VS xgboost谁才是最强的梯度提升库？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： C++11 POD类型
- 下一篇： UVA11825： Hackers' C