[SYSTEMDS-???] Parameterserver aggregation optimization

[Baunsgaard]

This PR contains two small commits.

1. Remove incorrect warning of native error in MKL call. that print in case of
2. AggregateFinalResults avoid Generic access by forcing dense if the format of both parts are different.

the second part make the execution of CNN ParameterServer with batch size 32 on MNIST go from 260 sec to 200 on my laptop, with minimal changes (10 lines), i don't think this have any bad side effects but would like confirmation.

[mboehm7]

thanks for following up on this, instead of converting the vector back to dense (after it has been copied from dense to sparse), couldn't we directly do ret.copy(rtasks.get(0).get(), false); //for init before the call to aggregateFinalResults to keep the accumulator dense?

[Baunsgaard]

thanks for following up on this, instead of converting the vector back to dense (after it has been copied from dense to sparse), couldn't we directly do ret.copy(rtasks.get(0).get(), false); //for init before the call to aggregateFinalResults to keep the accumulator dense?

I Just tried it, we still encounter the case where the new values incoming are sparse, while our aggregate is dense.
the situation we want to avoid is this mix, because then we end up using our generic LibMatrixAgg.aggregateBinaryMatrixLastRowDenseGeneric () in this code path when we have correction enabled:

But i do get that it makes more sense to force the initial accumulator to be dense, since it most likely will be in the end so i added the copy to dense part you suggest, but overall this gives us a second better execution time on 32 batch size 1 epoch.