|Depends upon it=Estimating Unobserved Complementarities between Entrepreneurs and Venture Capitalists Matlab Code
}}
Main Project here: [[Estimating Unobserved Complementarities between Entrepreneurs and Venture Capitalists Matlab Code]]
==SynposisSynopsis==On July 2nd of 2018, Chenyu Yang, the original code author of the above main project, requested me to have "an implementation of LP (linear programming) on GPU", and Ed seconded this idea. I henceforth started exploring the possibility of such an endeavor. What is more important, such "an implementation of LP on GPU" should beat our current solver (Gurobi or Matlab's linprog). <br>After some research, my conclusion is that we cannot beat performance of Gurobi on solving a single LP, and we should continued continue to use Gurobi instead of linprog. However, we might be still able to speed up our code by task-parallelising on CPU cores.
==Getting Started with our GPU==
* For the above reason, Gurobi '''does not''' support GPU computing.
* Matlab '''does not''' have GPU-based linprog or ga.
* Maltba '''does''' have an option to [https://www.mathworks.com/help/gads/how-to-use-parallel-processing.html run ga in parallel]. * Gurobi '''does''' support [https://www.gurobi.com/documentation/8.0/refman/continuous_models.html CPU parallelism]. In fact, it will use the concurrent solver for LP by default.
* In general, individual threads of GPU only perform well with simple arithmetic tasks. Task-parallelizing toolboxes/libraries/packages onto threads of GPU is '''NO GO'''.
==Serial vs Parallel: solving many LPs on CPU==
===Using a function wrapper for Gurobi===
I manage to call Gurobi solvers on many LP problems in a parallel manner. To accomplish this, one needs to wrap the LP solving part into a function, and call this function inside the parfor. See [[File:parallel gurobi.pdf]] for a (lazy) example.
Run serial and parallel(using the above method) versions of msmf_corr_coeff.m. With profiling, the parallel version takes much longer time than the serial one. On a closer inspection, a single call to gurobi takes a very small amount of time. Using parfor will probably not give us any benefit. However, I suspect that for large R (~1000) we will see improvements from parallelism. <br>
The parallel version now is ~3.5 time faster than the serial version. I believe it might be even faster with more cores. However I do not completely understand how the computation time scales with R (and other parameters). Will run another test with R = 200.<br>
Serial: 3231 s [[File:serial_gurobi_R=200.png]] <br>
Parallel: 1605 s [[File:parallel_gurobi_R=200.png]] <br>
==Further parallelize msmf_corr_coeff==
At this point I decided to make a new project page to document all the changes I made to the code for parallelism. Please refer to this page: [[Parallelize msmf corr coeff.m]]
==Deliverable==
===Week July 2 - 6===
<s>In Matlab, use parfor for both CPU and GPU to solve a set of LPs. Profile and compare.</s> <br> Just try to do CPU instead. Figure out how to do CPU-based parallel computing with Gurobi. I cannot find a way to run Gurobi solvers inside a parfor. I believe Matlab's linprog can, but linprog is much slower than Gurobi. There will be some trade off. I need to test this. <br>
It is too hard to test this using the code written by Chenyu. Instead I will write my small piece of code to test this.
===Week July 9 - 13===
*Continue experimenting with calling gurobi inside parfor.
*<s>Look at ways to speed up moments.m.</s> I was wrong about the computational complexity of moments.m. However it might still benefit us to speed up moments.m, but it is on a lower priority now.