# Difference between revisions of "Risk analysis"

From Superoptimization

m (→Risk register: Correct first risk value) |
(→Risk register: Updated for interim report) |
||

Line 5: | Line 5: | ||

{| class="wikitable" | {| class="wikitable" | ||

! Description !! Likelihood !! Impact !! Risk !! Mitigation | ! Description !! Likelihood !! Impact !! Risk !! Mitigation | ||

+ | |||

|- | |- | ||

− | | | + | | Hard limit to search space prevents useful optimization |

− | | | + | | 5 || 3 || 15 |

− | | | + | | 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. | | Computational demand is too high. | ||

− | | | + | | 4 || 3 || 12 |

− | | Focus on optimal algorithms. Ensure adequate compute power. | + | | 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|work package 3]]. |

+ | |- | ||

+ | | Some features of modern processors cannot be superoptimized. | ||

+ | | 4 || 2 || 8 | ||

+ | | 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|work package 1]]. | ||

|- | |- | ||

| Project is too complex for 4 months. | | Project is too complex for 4 months. | ||

− | | | + | | 2 || 2 || 4 |

− | | Tight project management (weekly meetings). | + | | 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. |

|} | |} |

## Revision as of 18:46, 1 August 2014

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

## Risk register

Description | Likelihood | Impact | Risk | Mitigation |
---|---|---|---|---|

Hard limit to search space prevents useful optimization | 5 | 3 | 15 | 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. | 4 | 3 | 12 | 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. | 4 | 2 | 8 | 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. | 2 | 2 | 4 | 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. |