[SPARK-19759][ML] not using blas in ALSModel.predict for optimization

[mgaido91]

What changes were proposed in this pull request?

In ALS.predict currently we are using blas.sdot function to perform a dot product on two Seqs. It turns out that this is not the most efficient way.

I used the following code to compare the implementations:

def time[R](block: => R): Unit = {
    val t0 = System.nanoTime()
    block
    val t1 = System.nanoTime()
    println("Elapsed time: " + (t1 - t0) + "ns")
}
val r = new scala.util.Random(100)
val input = (1 to 500000).map(_ => (1 to 100).map(_ => r.nextFloat).toSeq)
def f(a:Seq[Float], b:Seq[Float]): Float = {
    var r = 0.0f
    for(i <- 0 until a.length) {
        r+=a(i)*b(i)
    }
    r
}
import com.github.fommil.netlib.BLAS.{getInstance => blas}
val b = (1 to 100).map(_ => r.nextFloat).toSeq
time { input.foreach(a=>blas.sdot(100, a.toArray, 1, b.toArray, 1)) }
// on average it takes 2968718815 ns
time { input.foreach(a=>f(a,b)) }
// on average it takes 515510185 ns

Thus this PR proposes the old-style for loop implementation for performance reasons.

How was this patch tested?

existing UTs

[SparkQA]

Test build #83551 has finished for PR 19685 at commit 8b0add6.

• This patch passes all tests.
• This patch merges cleanly.
• This patch adds no public classes.

[srowen]

Yes, seems that people have found often in the past that level 1 BLAS ops were not actually faster. Here using it requires overhead of converting to an array. I can believe this is faster. Usually a while loop is a little faster.

Interestingly there is another PR suggesting that Level 1 BLAS is faster when native libs are available.

[WeichenXu123]

You should use while instead of for

[WeichenXu123]

Have you made some test to check the performance difference for this ?

[mgaido91]

@srowen I tried enabling native BLAS, but native BLAS implementation is still much slower: average on 10 runs is 2529,922753 ms against 515,510185 ms of the for loop. As a reference, I am using a OSX 2.5 GHz Intel Core i7.
What is worth to notice, though, is that I tried to run the same code but performing the toArray before, thus excluding its time from the computation. In this case, native BLAS implementation is much faster: 100,969697 ms. Thus here the "performance killer" is the conversion to array, as you pointed out.

@WeichenXu123 In the description od the PR and here you can see the tests I made. Do you think something else is needed?

[SparkQA]

Test build #83598 has finished for PR 19685 at commit 4867345.

• This patch passes all tests.
• This patch merges cleanly.
• This patch adds no public classes.

[srowen]

Merged to master