Changeset 3428


Ignore:
Timestamp:
Feb 12, 2014, 11:30:21 AM (5 years ago)
Author:
campbell
Message:

More minor stuff.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • Papers/fopara2013/fopara13.tex

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