Commit 6372e677798cab6c71dcf57f5a2cf93fe5f9e85d

Authored by Geoffrey Challen
1 parent 3a5d204d

New.

certainty.tex
1 \section{From Uncertainty to Certainty} 1 \section{From Uncertainty to Certainty}
2 \label{sec-certainty} 2 \label{sec-certainty}
3 3
4 -While \texttt{maybe} allows programmers to specify multiple alternatives,  
5 -ultimately only one alternative may be used. Either a single, globally best  
6 -alternative must be chosen,  
7 -or a deterministic decision procedure  
8 -must be selected. Before discussing options for \textit{adapting} an app  
9 -to its runtime environment, we first  
10 -explain our runtime's support for \texttt{maybe} alternatives, including post-mortem  
11 -evaluation and data-collection.  
12 -%system implements \texttt{maybe} statements and collects data used to tailor or  
13 -%\textit{adapt} an app to its host environment.  
14 -Then, we discuss how \texttt{maybe} testing  
15 -enables a variety of different adaptation patterns.  
16 -  
17 -\subsection{Evaluating Alternatives}  
18 -The optional \texttt{better} block of a \texttt{maybe} statement allows  
19 -programmers to provide app-specific post-mortem logic. However, in many  
20 -cases, we expect that \texttt{maybe} statements will be used to achieve  
21 -common objectives such as improving performance or saving energy.  
22 -To steamline application development, our current  
23 -system assesses \texttt{maybe} statements without a \texttt{better}  
24 -block in terms of both energy and performance. In cases where one  
25 -alternative is a clear winner in terms of both energy and performance, that alternative will be used---although note that this selection may  
26 -still need to be time-varying since it may depend on exogenous factors. 4 +While \texttt{maybe} allows programmers to specify multiple alternatives,
  5 +ultimately only one alternative may be used. Either a single, globally best
  6 +alternative must be chosen, or a deterministic decision procedure must be
  7 +selected. Before discussing options for \textit{adapting} an app to its
  8 +runtime environment, we first explain our runtime's support for
  9 +\texttt{maybe} alternatives, including \textit{a posteriori} evaluation and
  10 +data-collection. Then, we discuss how \texttt{maybe} testing enables a
  11 +variety of different adaptation patterns.
  12 +
  13 +\subsection{Evaluating Alternatives} The optional \texttt{evaluate} block of
  14 +a \texttt{maybe} statement allows programmers to provide app-specific
  15 +\textit{a posteriori} evaluation logic. However, in many cases, we expect
  16 +that \texttt{maybe} statements will be used to achieve common objectives such
  17 +as improving performance or saving energy. To steamline application
  18 +development, our current system assesses \texttt{maybe} statements without a
  19 +\texttt{better} block in terms of both energy and performance. In cases where
  20 +one alternative is a clear winner in terms of both energy and performance,
  21 +that alternative will be used---although note that this selection may still
  22 +need to be time-varying since it may depend on exogenous factors.
27 23
28 Cases where \texttt{maybe} blocks provide an energy-performance tradeoff 24 Cases where \texttt{maybe} blocks provide an energy-performance tradeoff
29 require more investigation to handle. We are exploring several options, 25 require more investigation to handle. We are exploring several options,
@@ -79,7 +75,7 @@ selection as described in more detail later in this section. @@ -79,7 +75,7 @@ selection as described in more detail later in this section.
79 75
80 We next describe the pre- and post-deployment testing that helps developers to 76 We next describe the pre- and post-deployment testing that helps developers to
81 design an \textit{adaptation} policy, a strategy for ultimately selecting 77 design an \textit{adaptation} policy, a strategy for ultimately selecting
82 -between alternatives. While the \texttt{maybe} system 78 +between alternatives. While the \texttt{maybe} system
83 automates many of the tedious tasks normally associated with large-scale 79 automates many of the tedious tasks normally associated with large-scale
84 testing, we still provide ways for the developer to guide and even override 80 testing, we still provide ways for the developer to guide and even override
85 any step in the process. 81 any step in the process.
include/start.tex
  1 +\pdfobjcompresslevel=1
1 \documentclass[letterpaper,twocolumn]{sig-alternate} 2 \documentclass[letterpaper,twocolumn]{sig-alternate}
2 \usepackage{url,graphicx,multirow,hyperref,color,calc,ulem,threeparttable,tabularx,booktabs,enumitem,comment,subcaption,balance,leading} 3 \usepackage{url,graphicx,multirow,hyperref,color,calc,ulem,threeparttable,tabularx,booktabs,enumitem,comment,subcaption,balance,leading}
3 \usepackage{minted} 4 \usepackage{minted}
maybe.tex
@@ -24,7 +24,7 @@ maybe { @@ -24,7 +24,7 @@ maybe {
24 ret = fastPowerHungryAlgorithm(input); 24 ret = fastPowerHungryAlgorithm(input);
25 } or { 25 } or {
26 ret = slowPowerEfficientAlgorithm(input); 26 ret = slowPowerEfficientAlgorithm(input);
27 -} analyze { 27 +} evaluate {
28 return { "repeat": false, 28 return { "repeat": false,
29 "score" : nanoTime() + powerDrain() } 29 "score" : nanoTime() + powerDrain() }
30 } 30 }
@@ -69,16 +69,17 @@ statement providing syntactic sugar. \texttt{maybe} function annotations @@ -69,16 +69,17 @@ statement providing syntactic sugar. \texttt{maybe} function annotations
69 allow uncertainty to be expressed at the function level, with the 69 allow uncertainty to be expressed at the function level, with the
70 alternatives consisting of multiple function definitions with identical 70 alternatives consisting of multiple function definitions with identical
71 signatures. Finally, \texttt{maybe} blocks that require special performance 71 signatures. Finally, \texttt{maybe} blocks that require special performance
72 -evaluation logic can include that in the form of a \texttt{better} statement  
73 -following the main \texttt{maybe} block, as shown in the final example.  
74 -\texttt{better} blocks provide application-specific logic that analyze the  
75 -selected execution path. The \texttt{better} block must return a single JSON  
76 -object that includes two components: A score, with smaller being interpreted  
77 -as better; and a boolean indicating whether the system should use the same  
78 -branch next time, or if it is free to try another. Note that hints and  
79 -dedicated evaluation logic can also be applied to variable and function-level  
80 -\texttt{maybe} statements through annotations. We will return to post-mortem  
81 -evaluation in Section~\ref{sec-certainty}. 72 +evaluation logic can include that in the form of a \texttt{evaluate}
  73 +statement following the main \texttt{maybe} block, as shown in the final
  74 +example. \texttt{evaluate} blocks provide app-specific \textit{a posteriori}
  75 +logic to evaluate the selected alternative. The \texttt{evaluate} block must
  76 +return a single JSON object that includes two components: A score, with
  77 +smaller being interpreted as better; and a boolean indicating whether the
  78 +system should use the same branch next time, or if it is free to try another.
  79 +Note that hints and dedicated evaluation logic can also be applied to
  80 +variable and function-level \texttt{maybe} statements through annotations. We
  81 +will return to \textit{a posteriori} evaluation in
  82 +Section~\ref{sec-certainty}.
82 83
83 \subsection{Discussion} 84 \subsection{Discussion}
84 85