Wei Wu(Work log) - Revision history

WeiWu: /* Summer 2018 */

2018-08-03T21:08:10Z

Summer 2018

2018-08-03T21:07:11Z

Summer 2018

2018-08-03T20:52:20Z

Summer 2018

2018-07-18T21:59:28Z

Summer 2018

2018-07-16T20:53:30Z

Summer 2018

2018-07-16T20:53:09Z

Summer 2018

2018-07-16T20:49:54Z

Summer 2018

2018-07-16T19:51:59Z

Summer 2018

2018-07-16T19:24:17Z

Summer 2018

2018-07-16T19:22:13Z

Summer 2018

← Older revision		Revision as of 21:08, 3 August 2018
Line 113:		Line 113:

	2018-08		2018-08
−	Help Marcus ~~with getting~~ familiar with the Matlab code for matching VCs to startups.	+	Help Marcus get familiar with the Matlab code for matching VCs to startups.

@@ Line 108: / Line 108: @@
 *Worked on documentations for NOTS and parallelization
 *Worked on running matlab code on NOTS
 -08
 Help Marcus with getting familiar with the Matlab code for matching VCs to startups.

← Older revision		Revision as of 20:52, 3 August 2018
Line 108:		Line 108:
	*Worked on documentations for NOTS and parallelization		*Worked on documentations for NOTS and parallelization
	*Worked on running matlab code on NOTS		*Worked on running matlab code on NOTS
		+
		+	2018-08
		+
		+	Help Marcus with getting familiar with the Matlab code for matching VCs to startups.

@@ Line 96: / Line 96: @@
 *Reverted back to using Matlab's linprog rather than Gurobi. In a parfor, gurobi takes much longer than the native linprog to solve our LPs. I do not fully understand why this is happening. It might be the way that Gurobi was called inside a function that increases the overhead, or it might be that Gurobi couldn't utilize the full power of our CPU since all 12 cores have been scheduled to work on 12 different LPs (some LP algorithm of Gurobi has parallelism). Note that creating a model for Gurobi takes time.
 [[FILE:msmf35seconds.png]]
+<br>
 -07-16
 *Run monte_data mode with R=200, monte_M = 70, mktsize = 30. The msmf was computed fairly fast.
@@ Line 102: / Line 102: @@
 *Run data mode with R=200, monte_M=70, mktsize = 30.
 [[FILE:msmf_data.png]]

@@ Line 101: / Line 101: @@
 [[FILE:msmf_monte_data.png]]
 *Run data mode with R=200, monte_M=70, mktsize = 30.
-[[msmf_data.png]]
+[[FILE:msmf_data.png]]

← Older revision		Revision as of 20:53, 16 July 2018
Line 100:		Line 100:
	*Run monte_data mode with R=200, monte_M = 70, mktsize = 30. The msmf was computed fairly fast.		*Run monte_data mode with R=200, monte_M = 70, mktsize = 30. The msmf was computed fairly fast.
	[[FILE:msmf_monte_data.png]]		[[FILE:msmf_monte_data.png]]
		+	*Run data mode with R=200, monte_M=70, mktsize = 30.
		+	[[msmf_data.png]]

← Older revision		Revision as of 20:49, 16 July 2018
Line 96:		Line 96:
	*Reverted back to using Matlab's linprog rather than Gurobi. In a parfor, gurobi takes much longer than the native linprog to solve our LPs. I do not fully understand why this is happening. It might be the way that Gurobi was called inside a function that increases the overhead, or it might be that Gurobi couldn't utilize the full power of our CPU since all 12 cores have been scheduled to work on 12 different LPs (some LP algorithm of Gurobi has parallelism). Note that creating a model for Gurobi takes time.		*Reverted back to using Matlab's linprog rather than Gurobi. In a parfor, gurobi takes much longer than the native linprog to solve our LPs. I do not fully understand why this is happening. It might be the way that Gurobi was called inside a function that increases the overhead, or it might be that Gurobi couldn't utilize the full power of our CPU since all 12 cores have been scheduled to work on 12 different LPs (some LP algorithm of Gurobi has parallelism). Note that creating a model for Gurobi takes time.
	[[FILE:msmf35seconds.png]]		[[FILE:msmf35seconds.png]]
		+
		+	2018-07-16
		+	*Run monte_data mode with R=200, monte_M = 70, mktsize = 30. The msmf was computed fairly fast.
		+	[[FILE:msmf_monte_data.png]]

@@ Line 94: / Line 94: @@
 *Further parallelize Matlab code (msmf_corr_coeff.m). Now on our 12 cores server, one call to msmf_corr_coeff takes about 35 seconds for R=200, monte_M = 70, mktsize = 30.
 *Will try to parallelize moments.m. Currently it takes 10 seconds per call. This in included in the 35 seconds runtime of msmf_corr_coeff.m.
 [[FILE:msmf35seconds.png]]

@@ Line 9: / Line 9: @@
 <onlyinclude>
 [[Wei Wu]] [[Work Logs]] [[Wei Wu(Work log)|(log page)]] <br>
 -06-11 <br>
@@ Line 95: / Line 94: @@
 *Further parallelize Matlab code (msmf_corr_coeff.m). Now on our 12 cores server, one call to msmf_corr_coeff takes about 35 seconds for R=200, monte_M = 70, mktsize = 30.
 *Will try to parallelize moments.m.