X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=ghc%2Fdocs%2Fusers_guide%2Fprofiling.lit;fp=ghc%2Fdocs%2Fusers_guide%2Fprofiling.lit;h=0000000000000000000000000000000000000000;hb=abdd55c9c4a2873c2f4b25b4ea54ca921bca4f5e;hp=356a60503cf061c398401b2da6025b026521582b;hpb=5e1ab44baabe589b050e614de6212bd17e8aacd5;p=ghc-hetmet.git diff --git a/ghc/docs/users_guide/profiling.lit b/ghc/docs/users_guide/profiling.lit deleted file mode 100644 index 356a605..0000000 --- a/ghc/docs/users_guide/profiling.lit +++ /dev/null @@ -1,248 +0,0 @@ -\begin{onlystandalone} -\documentstyle[11pt,literate]{article} -\begin{document} -\title{The Glorious Haskell Compilation System\\ Profiling Guide} -\author{The GHC Team (Patrick M. Sansom)\\ -Department of Computing Science\\ -University of Glasgow\\ -Glasgow, Scotland\\ -G12 8QQ\\ -\\ -Email: glasgow-haskell-\{users,bugs\}-request\@dcs.gla.ac.uk} -\maketitle -\begin{rawlatex} -\tableofcontents -\end{rawlatex} -\end{onlystandalone} - -\section[profiling]{Profiling Haskell programs} -\index{profiling, with cost-centres} -\index{cost-centre profiling} - -Glasgow Haskell comes with a time and space profiling system. Its -purpose is to help you improve your understanding of your program's -execution behaviour, so you can improve it. - -%This profiling system is still under development. -%Please e-mail reports of any bugs you discover to -%\tr{glasgow-haskell-bugs@dcs.gla.ac.uk}. - -Any comments, suggestions and/or improvements you have to are welcome. -Recommended ``profiling tricks'' would be especially cool! - -\subsection[profiling-intro]{How to profile a Haskell program} - -The GHC approach to profiling is very simple: annotate the expressions -you consider ``interesting'' with {\em cost centre} labels (strings); -so, for example, you might have: - -\begin{verbatim} -f x y - = let - output1 = _scc_ "Pass1" ( pass1 x ) - output2 = _scc_ "Pass2" ( pass2 output1 y ) - output3 = _scc_ "Pass3" ( pass3 (output2 `zip` [1 .. ]) ) - in concat output3 -\end{verbatim} - -The costs of the evaluating the expressions bound to \tr{output1}, -\tr{output2} and \tr{output3} will be attributed to the ``cost -centres'' \tr{Pass1}, \tr{Pass2} and \tr{Pass3}, respectively. - -The costs of evaluating other expressions, e.g., \tr{concat output4}, -will be inherited by the scope which referenced the function \tr{f}. - -You can put in cost-centres via \tr{_scc_} constructs by hand, as in -the example above. Perfectly cool. That's probably what you {\em -would} do if your program divided into obvious ``passes'' or -``phases'', or whatever. - -If your program is large or you have no clue what might be gobbling -all the time, you can get GHC to mark all functions with \tr{_scc_} -constructs, automagically. Add an \tr{-auto} compilation flag to the -usual \tr{-prof} option. - -Once you start homing in on the Guilty Suspects, you may well switch -from automagically-inserted cost-centres to a few well-chosen ones of -your own. - -To use profiling, you must {\em compile} and {\em run} with special -options. (We usually forget the ``run'' magic!---Do as we say, not as -we do...) Details follow. - -If you're serious about this profiling game, you should probably read -one or more of the Sansom/Peyton Jones papers about the GHC profiling -system. Just visit the Glasgow FP Web page... - -%************************************************************************ -%* * -\subsection[prof-compiler-options]{Compiling programs for profiling} -\index{profiling options} -\index{options, for profiling} -%* * -%************************************************************************ - -\input{prof-compiler-options.lit} - -%************************************************************************ -%* * -\subsection[prof-rts-options]{How to control your profiled program at runtime} -\index{profiling RTS options} -\index{RTS options, for profiling} -%* * -%************************************************************************ - -\input{prof-rts-options.lit} - -%************************************************************************ -%* * -\subsection[prof-output]{What's in a profiling report?} -\index{profiling report, meaning thereof} -%* * -%************************************************************************ - -\input{prof-output.lit} - -%************************************************************************ -%* * -\subsection[prof-graphs]{Producing graphical heap profiles} -\index{heap profiles, producing} -%* * -%************************************************************************ - -\input{prof-post-processors.lit} - -% \subsection[cost-centres]{Profiling by Cost Centres} -% -% Problems with lazy evaluation -% -% The central idea is to identify particular source code expressions of -% interest. These expressions are annotated with a {\em cost -% centre}\index{cost centre} label. Execution and allocation costs are -% attributed to the cost centre label which encloses the expression -% incurring the costs. -% -% Simple example -% -% (Note: the paper in \tr{ghc/docs/papers/profiling.ps} may have some -% decent examples...) -% -% Costs are attribution to one cost centre. -% Inheritance of un-profiled costs. -% -% Degree of evaluation -% Unevaluated arguments -% Optimisation and transformation -% Evaluation of instances -% escaping functions: evaluation vs lexical -% -% \subsection[prof-annotations]{Annotating your Haskell source} -% -% Explicit annotations -% Automatic annotation -% -% \subsection[prof-information]{Profiling information} -% -% Cost Centre Label,Module,Group -% Example time/alloc profile -% -% Description of heap profile -% Closure Description, Type and Kind -% \subsection[limitations]{Limitations of the current profiling system} -% -% There are a number of limitations and shortcomings of the current -% profiling system. Any comments on the impact of these and any -% suggested improvements would be greatly appreciated. -% -% \begin{onlylatex} -% \subsubsection*{Explicit \tr{_scc_} annotations} -% \end{onlylatex} -% \begin{onlyinfo} -% Explicit \tr{_scc_} annotations: -% \end{onlyinfo} -% -% The explicit \tr{_scc_} source annotations cannot annotate entire -% function declarations as the clauses, pattern matching are not part of -% the expression syntax --- they are syntactic sugar. It is possible to -% remove the syntactic sugar by hand, translating to a simple -% declaration with case expressions on the rhs, but this is very -% tiresome. -% -% We propose to introduce an additional annotation to enable a \tr{_scc_} -% annotation to be placed around an entire declaration. -% -% To further ease the explicit annotation process we also propose to -% provide annotations which instruct the compiler to annotate all the -% declarations in a particular \tr{let} or \tr{where} clause with the -% name of the declaration. -% -% Other annotation schemes are feasible. Any suggestions / requests? -% -% -% \begin{onlylatex} -% \subsubsection*{Closure descriptions} -% \end{onlylatex} -% \begin{onlyinfo} -% Closure descriptions: -% \end{onlyinfo} -% -% The closure descriptions are by no means perfect ... -% -% The descriptions for expressions are somewhat tedious as they reflect -% some of the structure of the transformed STG code. This is largely to -% provide additional information so use of the STG code can be made if -% required (use the compiler option \tr{-ddump-stg}). This may be -% removed if the name of the \pl{corner} is considered sufficient. -% -% Local bindings introduced by the compiler have a name \tr{?}. -% Most of these are not related to the source in any meaningful way. For -% example, the \tr{?stg} names are introduced during the CoreToStg pass. -% Some other arbitrary compiler introduced names are: \tr{?ds}, -% \tr{?tpl}, \tr{?si}, \tr{?cs}, \tr{?ll}, and \tr{?sat}. Please let us -% know if any of these turn out to be a problem. We could introduce a -% more meaningful naming scheme into the compiler which assigns names -% that reflect the nearest enclosing source binding. Another possibility -% is to add the unique identifier so they aren't all clumped together as -% one indistinguishable description. -% -% There is only one closure description and type for all black holes, -% ``BH''. It might be useful to record the closure that is currently -% being evaluated as part of the black hole description. -% -% Similarly there is only one partial application description, ``PAP''. -% It might be useful to record the function being applied in the partial -% application as part of the partial application description. -% -% -% \begin{onlylatex} -% \subsubsection*{Garbage collection and paging} -% \end{onlylatex} -% \begin{onlyinfo} -% Garbage collection and paging: -% \end{onlyinfo} -% -% Currently the profiling implementation requires the two-space -% (\tr{-gc-2s}) garbage collector to be used. When using the \tr{-prof} -% options a particular garbage collector should not be specified. This -% imposes particular paging characteristics which may be different from -% the garbage collector your program normally uses. These paging -% characteristics may distort the user time profiling results, though we -% do not believe this is a significant problem. -% -% -% \subsection[references]{Papers describing this work} -% -% A discussion of our initial ideas are described in the paper -% ``Profiling Lazy Functional Languages'' by Patrick Sansom and Simon -% Peyton Jones. -% -% It is in the GHC distribution in \tr{ghc/docs/papers/profiling.ps}, -% or it can be retrieved using ftp from -% \tr{ftp.dcs.gla.ac.uk} (\tr{[130.209.240.50]}) -% in the file -% \tr{pub/glasgow-fp/papers/lazy-profiling.ps}. - -\begin{onlystandalone} -\printindex -\end{document} -\end{onlystandalone}