Risk analysis

From Superoptimization
Revision as of 15:04, 20 October 2014 by Jeremy (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

For each risk we gave the probability of it occurring (1-10) and the impact (1-3, with 1 being minor, and 3 being project killer). A mitigation was provided for any risk with an impact of 3, or where the product of likelihood and impact was greater than 10.

With the project complete, all risks have a likelihood of zero. The list is retained for reference in future projects. To see how values changed over the project, use the Wiki history.

Risk register

Description Likelihood Impact Risk Mitigation
Hard limit to search space prevents useful optimization 0 3 0 New risk identified for interim report. It seems you can either superoptimize an entire instruction set for very short sequences of code, or much longer code sequences, but only for a small subset of the entire instruction set. Mitigation is to identify heuristics: 1) to guide through the search space; and 2) to reduce the size of the search space.
Computational demand is too high. 0 3 0 Focus on optimal algorithms. Ensure adequate compute power. Likelihood reduced for interim report, since we have established that there are superoptimization strategies that are feasible with current computing power (see initial results for work package 3).
Some features of modern processors cannot be superoptimized. 0 2 0 Attempt to identify ways of applying to these features. Likelihood reduced for interim report, since we have identified sufficient features to make superoptimization attractive (see work package 1).
Project is too complex for 4 months. 0 2 0 Tight project management (weekly meetings). Likelihood reduced for interim report, since we have established all the main criteria, and believe we will finish without difficulty.