1.1 --- a/0__Papers/Holistic_Model/Perf_Tune/latex/Holistic_Perf_Tuning.tex	Thu Apr 12 06:23:14 2012 -0700
     1.2 +++ b/0__Papers/Holistic_Model/Perf_Tune/latex/Holistic_Perf_Tuning.tex	Thu Apr 12 06:53:51 2012 -0700
     1.3 @@ -64,15 +64,27 @@
     1.4  
     1.5  \section{Introduction and Motivation}
     1.6  
     1.7 -(Where reader is, can all say "yeah, I agree")
     1.8 -Visualizationas have been around, and perf tuning has been around, but they are a bit fragmented, focusing on one specific view of the application, like statistics of line of code or function call or call-graph. Have core time-lines, showing which function by time, but then don't know why or how much is what wanted it to do, or have cache misses over time, but never have a coherent view of how application code connects to what happens where and when. 
     1.9 +(Where reader is, they can all say "yeah, I agree")
    1.10 +Visualizations have been around, and performance tuning tools have been around, but they leave something to be desired. They are a bit fragmented, focusing on one specific view of the application, like statistics of line of code or function call or message sends and receives. They have core time-lines, showing which function runs by time, but the user doesn't know why a function runs in that particular spot on that particular core, nor whether that  is desired behavior vs erroneous behavior. 
    1.11 +
    1.12 +There are a variety of tools, but they have in common that they are composed of several disjointed parts that fail to tell the user what they want to know. This leaves the user to guess. It's like the allegory of the five blind people and the elephant: one touches the ear and says it's round and flat, another touches the leg and says it's a tree, and so on. They each are correct, but the views don't connect to tell them the whole picture. 
    1.13 +
    1.14 +The user usually knows what the application is doing semantically, but parallel performance is all about scheduling and other runtime behavior.  The choices about which task or virtual processor is assigned to which core at what point in time is the heart of performance. The causes of that behavior is a big part of the missing information the user wants to know.
    1.15 +
    1.16 +=============
    1.17 +
    1.18 + the   or have cache misses over time, but never have a coherent view of how application code connects to what happens where and when. 
    1.19  
    1.20  Can have a timeline view, and next to that execution by function and what percent by function, next to that histogram of cache misses.  But no coherent view of how to connect these things. There is information missing that connects the views. The user still has to guess about what the cause might be.
    1.21  
    1.22 +The problem of the other vis is they don't give shape of application..
    1.23 + the fundamental parallelism related structure.
    1.24 +
    1.25 +===================
    1.26 +
    1.27  To fix this, want is a mental framework that the views all fit into, so that they connect to each other when one looks at the information. 
    1.28  
    1.29 -The problem of the other vis is they don't give shape of application..
    1.30 - the fundamental parallelism related structure. Scheduling is a fundamental part of parallel execution. The views must include both constraints on scheduling and the actual scheduling choices. The parts that affect what scheduling ch
    1.31 + Scheduling is a fundamental part of parallel execution. The views must include both constraints on scheduling and the actual scheduling choices. The parts that affect what scheduling choices are possible must connect to the parts that show which ones were taken.
    1.32  
    1.33  to have more theoretical underpinning and several views that connect to each other. The user needs more information, with some mental framework to 
    1.34