Uh oh!
There was an error while loading. Please reload this page.
[WIP][SPARK-17134][ML] Use level 2 BLAS operations in LogisticAggregator - #17894
[WIP][SPARK-17134][ML] Use level 2 BLAS operations in LogisticAggregator#17894VinceShieh wants to merge 1 commit into
Conversation
Multinomial logistic regression uses LogisticAggregator class for gradient updates. This PR refactors MLOR to use level 2 BLAS operations for the updates. Signed-off-by: VinceShieh <vincent.xie@intel.com>
dbtsai
left a comment
There was a problem hiding this comment.
Do you have any benchmark? I wonder how much speed up with this PR? Thank you for working on this.
SparkQA
commented
May 8, 2017
Test build #76558 has finished for PR 17894 at commit
|
| import breeze.linalg.{DenseVector => BDV} | ||
| import breeze.optimize.{CachedDiffFunction, DiffFunction, LBFGS => BreezeLBFGS, LBFGSB => BreezeLBFGSB, OWLQN => BreezeOWLQN} | ||
| import com.github.fommil.netlib.BLAS.{getInstance => blas} |
There was a problem hiding this comment.
Is it better to use MLlib BLAS interface?
There was a problem hiding this comment.
There was a problem hiding this comment.
MLLib BLAS doesnt have ger support, we might, of course, add an API support in MLLib Blas for this issue
| var maxMargin = Double.NegativeInfinity | ||
| val margins = new Array[Double](numClasses) | ||
| val featureStdArray = new Array[Double](features.size) |
There was a problem hiding this comment.
This will densify the sparse features. We should handle them differently. For sparse, we don't need to do level 2 BLAS which will not help.
There was a problem hiding this comment.
Agree. Still, we will try benchmark on the sparse dataset, if such change hurt the performance for sparse data, we will bypass this change for it.
There was a problem hiding this comment.
In my company, we have use-case of handing very sparse input with around 20 non-zero features with millions of total feature space. This implementation will break in this scenario.
There was a problem hiding this comment.
I suggest change the featureStdArray as Aggregator class member, so that avoid each update allocate a new temporary array.
| import breeze.linalg.{DenseVector => BDV} | ||
| import breeze.optimize.{CachedDiffFunction, DiffFunction, LBFGS => BreezeLBFGS, LBFGSB => BreezeLBFGSB, OWLQN => BreezeOWLQN} | ||
| import com.github.fommil.netlib.BLAS.{getInstance => blas} |
There was a problem hiding this comment.
hhbyyh
commented
May 8, 2017
I'm not sure how much acceleration we can get from Level 2 BLAS. For benchmark, we also would need to evaluate the performance for sparse data. |
VinceShieh
commented
May 9, 2017
@hhbyyh performance testing is ongoing, thanks! |
sethah
commented
May 11, 2017
Would you mind adding |
VinceShieh
commented
May 17, 2017
@sethah Sorry for the late response. Setting as WIP. We have performance data for dense features, data for the sparse feature will be ready soon. thanks. |
VinceShieh
commented
Jun 1, 2017
VinceShieh
commented
Jun 1, 2017
sethah
commented
Jun 1, 2017
@VinceShieh Thanks for posting your results. You tested these on datasets with only 100 samples correct? That's probably not a representative use case of a normal workload... Also, how many classes (i.e. I've actually been looking at using level 3 BLAS operations in the logistic aggregator, and initial results showed close to 10x speedups in some cases. I am holding off submitting any code because it would require a fairly significant refactoring of the code, which will be made much easier after #17094 is merged. Using level 2 BLAS is a less invasive change, but the test results you show provide rather small speedups. My preference is to wait a bit and submit a change that incorporates level 3 BLAS in logistic regression. We should get @dbtsai's opinion too. |
VinceShieh
commented
Jun 2, 2017
@sethah yes, we only take 100 samples and trained with 3 iterations, numClasss is 20 of our test dataset for single node testing. |
| var maxMargin = Double.NegativeInfinity | ||
| val margins = new Array[Double](numClasses) | ||
| val featureStdArray = new Array[Double](features.size) |
There was a problem hiding this comment.
I suggest change the featureStdArray as Aggregator class member, so that avoid each update allocate a new temporary array.
| margins(j) += localCoefficients(index * numClasses + j) * stdValue | ||
| j += 1 | ||
| } | ||
| featureStdArray(index) = value / localFeaturesStd(index) |
There was a problem hiding this comment.
Here why don't deal with the case localFeaturesStd(index) == 0.0 ?
I remember other place it deal with such case, such as:
featureStdArray(index) = if (localFeaturesStd(index) != 0.0) value / localFeaturesStd(index) else 0.0
There was a problem hiding this comment.
it seems to be a bug, I send a PR to fix this #18896
WeichenXu123
commented
Aug 9, 2017
I am also interested in implementation by level-3 BLAS. Can you post a design doc first? |
HyukjinKwon
commented
Jul 16, 2018
gentle ping @VinceShieh for @WeichenXu123's comment. |
Closesapache#17422Closesapache#17619Closesapache#18034Closesapache#18229Closesapache#18268Closesapache#17973Closesapache#18125Closesapache#18918Closesapache#19274Closesapache#19456Closesapache#19510Closesapache#19420Closesapache#20090Closesapache#20177Closesapache#20304Closesapache#20319Closesapache#20543Closesapache#20437Closesapache#21261Closesapache#21726Closesapache#14653Closesapache#13143Closesapache#17894Closesapache#19758Closesapache#12951Closesapache#17092Closesapache#21240Closesapache#16910Closesapache#12904Closesapache#21731Closesapache#21095 Added: Closesapache#19233Closesapache#20100Closesapache#21453Closesapache#21455Closesapache#18477 Added: Closesapache#21812Closesapache#21787 Author: hyukjinkwon <gurwls223@apache.org> Closesapache#21781 from HyukjinKwon/closing-prs.




What changes were proposed in this pull request?
Multinomial logistic regression uses LogisticAggregator class for gradient updates.
This PR refactors MLOR to use level 2 BLAS operations for the updates
How was this patch tested?
Existing test would do
Signed-off-by: VinceShieh vincent.xie@intel.com