Changeset 3428

Timestamp:

Feb 12, 2014, 11:30:21 AM (5 years ago)

Author:

campbell

Message:

More minor stuff.

File:

• Papers/fopara2013/fopara13.tex (modified) (4 diffs)

Papers/fopara2013/fopara13.tex

@@ -814 +814 @@
 unpredictable amount of time in I/O. What is interesting is the reaction time 
 that measure the time spent between I/O events. Moreover, we are interested in 
-predicting and ruling out programs that crash running out of space on a certain 
-input.
+predicting and ruling out crashes due to running out of space on certain 
+inputs.
 Therefore we need to look for a statement that talks about sub-runs of a 
 program. The most natural statement is that the time predicted on the source 
@@ -879 +879 @@
 dependencies on the `non-functional' parts of the state.
 
-The non-functional state has no correspondence in the high level state and does 
-not influence the functional properties. What can be done is to expose the 
-non-functional state in the source code. We present here the basic 
-intuition in a simplified form: the technical details that allow us to handle the 
-general case are more complex and can be found in~\cite{paolo}. We add 
-to the source code an additional global variable that represents the 
-non-functional state and another one that remembers the last labels emitted. The 
-state variable must be updated at every label emission statement, using an 
-update function which is computed during static analysis too. The update 
-function associates to each label a function from the recently emitted labels 
-and old state to the new state. It is computed by composing the semantics of every 
-instruction in a basic block and restricting it to the non-functional part of 
-the state.
+The non-functional state is not directly related to the high level
+state and does not influence the functional properties. What can be
+done is to expose key aspects of the non-functional state in the
+source code. We present here the basic intuition in a simplified form:
+the technical details that allow us to handle the general case are
+more complex and can be found in~\cite{paolo}. We add to the source
+code an additional global variable that represents the non-functional
+state and another one that remembers the last few labels emitted. The
+state variable must be updated at every label emission statement,
+using an update function which is computed during static analysis
+too. The update function associates to each label a function from the
+recently emitted labels and old state to the new state. It is computed
+by composing the semantics of every instruction in a basic block and
+restricting it to the non-functional part of the state.
 
 Not all the details of the non-functional state needs to be exposed, and the 
@@ -902 +903 @@
 program. Moreover, at any moment the user, or the invariant generator tools that 
 analyse the instrumented source code produced by the compiler, can decide to 
-trade precision of the analysis for simplicity by approximating the parametric 
-cost with safe non parametric bounds. Interestingly, the functional analysis of 
+trade precision of the analysis for simplicity by approximating the
+cost with safe bounds that do not depend on the processor state. Interestingly, the functional analysis of 
 the code could determine which blocks are executed more frequently in order to 
 use more aggressive approximations for the ones that are executed least.
@@ -1063 +1064 @@
 The most important future work is dealing with hardware architectures
 characterized by history dependent stateful components, like caches and
-pipelines. The main issue consists in assigning a parametric, dependent cost
+pipelines. The main issue is to assign a parametric, dependent cost
 to basic blocks that can be later transferred by the labeling approach to
 the source code and represented in a meaningful way to the user. The dependent
 labeling approach that we have studied seems a promising tool to achieve
-this goal, but the cost model generated for a realistic processor could be too
-large and complex to be exposed in the source code. Further study is required
-to evaluate the technique on a realistic processor and to introduce early
-approximations of the cost model to make the technique feasible.
-
-Examples of further future work consist in improving the cost invariant
-generator algorithms and the coverage of compiler optimizations, in combining
+this goal, but more work is required to provide good source level
+approximations of the relevant processor state.
+
+Other examples of future work are to improve the cost invariant
+generator algorithms and the coverage of compiler optimizations, to combining
 the labeling approach with the type and effect discipline of~\cite{typeffects}
-to handle languages with implicit memory management, and in experimenting with
-our tools in early development phases. Some larger case study is also necessary
+to handle languages with implicit memory management, and to experiment with
+our tools in the early phases of development. Larger case studies are also necessary
 to evaluate the CerCo's prototype on realistic, industrial-scale programs.