更多深度文章，请关注云计算频道：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个线程作为参照。
我们可以注意到：
- 对于xgboost来说并没有提升，数值的变化基本可以看成是误差
- 对于LightGBM来说反而耗时更长，从33.6秒提高到38秒以上
所以我们可以简单的下一个结论：不要过度分配逻辑内核，这不是一个好的做法。保持使用逻辑核心创建一定量的线程，并且不要超过该数。
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，译者：爱小乖
文章为简译，更为详细的内容，请查看原文