researcherben / compute-platform-cost-benefit-comparison Goto Github PK

given the simple model, the brute force search scales poorly: (number of platform choices)^(number of jobs). The smallest job count I'm working with is 60, so that's 2^60 = 10^18 permutations to search. I think some heuristics could reduce the workload, but I don't understand the math well enough yet

the model is overly simplistic, so additional factors need to be included. I'm not sure what the addition complexities are yet, so I'm seeking feedback from my customers.

“time to market in days” appears to be off by one in the tailored and commodity calculations (affecting the solutions_count). This may be an “indexing” problem.

The “cost per solution” for the “cloud” calculation is different between the two version. For the MATLAB it is basically the cost per minute times “minutes per solution.” Should the cost start on day zero or on day “time to market”? The above question on when does the “initial time to solution” apply also has implications here.

“solutions count” is done differently for the “cloud” in the two version. This is the problem with the “cumulative sum” calculation

In my write-up, I apply the “availability” to the system cost per hour of use, which is not how it is implemented in Ben’s code. If the availability is 99%, the final answer likely won’t change much, but if the availability decreases it could become significant. For the non-cloud system, I could also see this being used to separate out costs like labor (which likely don’t change when the system is down) from the cost of electricity to run the system (which should decrease during down times).

Once the “cumulative sum” fix is implemented in MATLAB, there appears to be some other small difference, between them which is a little more subtle. I think it can be summarized by “When does the “initial time to solution” apply? Is it on day 0 or is it on day “time to market”? For this case, the time to market is only 1 day, but it means a difference of 67 solutions by the last day.

cost_benefit_with_outages_with_moores_law.m: The calculation for the solution count is done incorrectly for the case that involves "Moore's Law". It should be a cumulative sum, but he is computing it as " solutions_count_without_time_to_market = solutions_per_day .* time_in_days", where "time_in_days" is a vector (0 to number of days). This would be OK if solutions per day was a constant value, but because he is including Moore's Law it is not. The cumulative number of solutions on day 2 is not 2 * the number of solutions computed on day 2, rather it should be solutions on day 1 plus solutions on day 2. Or, in MATLAB terms "solutions_count_without_time_to_market = cumsum(solutions_per_day);" As Moore's Law implies that the number of solutions per day will increase over time, his calculation overestimates the total number of solutions.

homo_vs_hetero.m: The output in the presentation did not match the output in the code for the heterogeneous case. If I am reading my notes correctly, the presentation was wrong and not the Matlab code. (The C++ and presentation version minimized the sum of the time spent on the two systems rather than the makespan.)

implementation does not take availability into account.