Linalg benchmark

[OXPHOS]

• compare CPU.dot and GPU.dot of current linalg and refactored linalg
• ref Linalg Refactor - CPU dot #3230
• cannot use global variable: sg_linalg (segmentation fault 11)

[OXPHOS]

I can only do:
clang++ -O3 -std=c++11 ../benchmarks/linalg_refactor_benchmark.cpp -I/usr/include/eigen3 -lshogun -lhayai_main -framework OpenCL -o benchmark

g++ and -lOpenCL didn't work for me.

For -lOpenCL, the error was: cannot find OpenCL.
For g++ and -framework OpenCL, I got error: https://gist.github.com/OXPHOS/dc59556267bc24614ebceb0af9ba8218

[lambday]

Hi @OXPHOS

The point of the benchmark is to compare the performance between direct library function call and shogun linalg method call, NOT between CPU and GPU backend. The two benchmarks should be something like

• create SGVector and CPUVector from it. Now compare between (a) creating Eigen3 map directly and calling eigen3 dot (b) calling shogun linalg dot on CPUVector that uses Eigen3 backend.
• create SGVector and GPUVector from it. Now compare between (a) calling viennacl inner_prod on the viennacl vector (b) calling shogun linalg dot on GPUVector.

Run this experiment with vectors of size 1000, 10000, 100000 and so on. We want to check whether using our version of dot has any overhead, and if yes, how much. See the point?

There might be an issue with your OpenCL installation. Should not be too hard to fix it.

[lambday]

Why create std::vector first?

[OXPHOS]

(not sure where to put this)
graph:
https://drive.google.com/file/d/0B6YkOSoC_E5raktfWFRweXgwa1U/view
x-axis: vector size ranges from 10 - 10^7,
left panel compares Eigen3 dot product with explicit method(blue) and CPUVector wrapper method(black).
right panel compares ViennaCL dot product with explicit method(blue) and GPU_Vector wrapper method(black).
GPU_Vector - GPUBackend is extremely slow..

[lambday]

Hi @OXPHOS!

Great job with the benchmarks :) This is exactly what we were looking for. Interesting issues will be visible from these benchmarks.

Let me comment on the code first and then we'll discuss

[lambday]

indentation :)

[lambday]

Hey there! Please check the comments. We need to make sure that no extra copying is happening under the hood. The dot interface we designed is supposed to work with base vector pointers. So that's exactly what the test-cases should deal with. Maybe changing those to pointers have an effect on the result?

Good job by the way! Also, please check the coding style for shogun. It is better to follow a uniform style everywhere.

Let me know when you fix the issues. Would be interesting to see how it performs in other machines.

[lambday]

Just have a BaseVector<value_type>* Ac here. Same for others. Should be allocated in the heap.

[lambday]

benchmark code, travis check not needed. merging.