\documentclass[handout]{beamer}
\usepackage{pgfpages}\pgfpagesuselayout{4 on 1}[a4paper,landscape,border shrink=5mm]

\usepackage{xmpmulti,multimedia,xspace}
\usepackage[latin1]{inputenc}

%\usetheme{Berlin}
\usetheme{AnnArbor}

\setbeamercovered{invisible}
\setbeamersize{text margin left=7.5mm}
\setbeamersize{text margin right=7.5mm}

%==============================================================================

\begin{document}
\title{Building your own C Toolkit: Part 2}
\author[Duncan White]{Duncan C. White, \\
	d.white@imperial.ac.uk}
\institute[Imperial]{Dept of Computing, \\
	Imperial College London}
\date{5th June 2014}

\begin{frame}
\titlepage
\end{frame}

%\section*{Outline}
%\begin{frame}
%\tableofcontents
%\end{frame}

\section{Today's Contents}

\begin{frame}[fragile]
  \begin{itemize}
    \item
      Last week, we introduced the idea of building a
      \alert{C programming toolkit},
      and covered the following tools or techniques:

      \begin{itemize}
      \item
        \alert{Programmer's Editors}.
      \item
        \alert{Automatic Compilation: Make}.
      \item
        \alert{Automatic Ruthless Testing}.
      \item
        \alert{Debugging: gdb}.
      \item
        \alert{Building shortlived tools on the fly}.
      \end{itemize}

    \item
      Today, we're going to carry on, and cover:
      \begin{itemize}
      \item
        \alert{Generating prototypes automatically: proto}.
      \item
        \alert{Fixing memory leaks: libmem}.
      \item
        \alert{Optimization and Profiling}.
      \pause
      \item
        Generating \alert{ADT modules} automatically.
      \pause
      \item
        \alert{Reusable ADT modules}: hashes, sets, lists, trees etc.
    \end{itemize}
    \pause
    \item
    As last week, there's a tarball of examples associated with this lecture.
    Both lectures' slides and tarballs are available on CATE and at:
    \verb+http://www.doc.ic.ac.uk/~dcw/c-tools-2014/+
  \end{itemize}
\end{frame}

\section{Generating Prototypes Automatically}

\subsection{proto: (tarball 01.proto)}

\begin{frame}[fragile]
    \begin{itemize}
      \item
      Irritating C problem:
      keeping the \alert{prototype declarations} in interfaces
      (.h files) in sync with the \alert{function definitions}
      in the implementation (.c files).
    \pause
      \item
      Whenever you \alert{add a public function} to \alert{list.c}
      you need to remember to add the corresponding prototype to
      \alert{list.h}.
    \pause
      \item
      Even \alert{adding or removing parameters} to existing functions
      means you need to make a corresponding change
      in the prototype too.
    \pause
      \item
      \alert{Don't live with broken windows} (PP tip 4) - write a tool
      to do the work,
      then integrate it into your editor for convenience!
    \pause
      \item
      Years ago, I wrote \alert{proto} - a tool to solve this.
      It reads a C file looking for function definitions, and
      produces a prototype for each function.
    \pause
      \item
      LIMITATION: whole function heading must be placed on one line.
    \pause
      \item
      Then I wrote a vi macro bound to an unused key that
      piped the next paragraph into \alert{proto \%} (current filename).
      Can do same for forward declarations of static functions using
      \alert{proto -s \%}.
    \end{itemize}
\end{frame}

\section{Fixing memory leaks}
\subsection{libmem (tarball 02.libmem/03.mem-eg)}

\begin{frame}[fragile]
    Memory leaks are the most serious C problem:
    \begin{itemize}
      \item
      Often claimed that
      \alert{99\% of serious C bugs are memory-allocation related}.
      \item
      C uses \alert{pointers and malloc()} so much, with
      so little checking, that debugging memory related
      problems can be challenging even with gdb.
    \pause
      \item
      Failing to \alert{free() what you malloc()} is
      very bad for long running programs, that
      continuously \alert{modify their data structures}.
    \pause
      \item
      Such programs can `leak' memory until they run out of
      memory (use more memory than the computer has physical RAM)!
    \pause
      \item
      \alert{free()ing a block twice} is equally dangerous.
    \pause
      \item
      \alert{dereferencing} an uninitialized/reclaimed pointer
      gives \alert{non-deterministic behaviour} (really hard to debug!).
    \pause
      \item
      \alert{Segmentation faults} - \alert{gdb where} (frame stack)
      may show it crashes in system libraries.
    \end{itemize}
\end{frame}

\begin{frame}[fragile]
    \begin{itemize}
      \item
      Why can't the system diagnose these?
    \pause
      \item
      There are several tools that can - \alert{Electric Fence}
      and \alert{valgrind/memcheck} among them.
      \item
      Here's a homebrew alternative:
    \pause
      \item
      The \alert{August 1990 Dr Dobbs Journal} provided
      \alert{libmem}, a very simple C module which uses the C pre-processor
      to redefine \alert{malloc(), free(), exit(), strdup()} etc
      to add extra checking.
    \pause
      \item
      Let's see it in action:
      \begin{itemize}
        \item
        First \verb+make install+ \alert{libmem} from tarball directory \alert{02.libmem}
        \pause
        \item
        Now go into tarball directory \alert{03.mem-eg}, 2 test programs.
        \item
	\verb+make+ and run the programs without libmem.
        \pause
        \item
        Add \verb+#include <mem.h>+ to both .c files
        \item
	Add \verb+-lmem+ to \verb+LDLIBS+ in \alert{Makefile}
        \pause
        \item
	Rebuild using \verb+make clean all+
	\item
	Run the two examples now!  They tell you exactly what you've
	forgotten to \verb+free()+!  Magic!
        \end{itemize}
	\pause
	\item
	You may say: but those test programs are tiny.
	Does libmem scale to larger size programs?
    \end{itemize}
\end{frame}

\subsection{Large-scale leaks (tarball 04.badhash/05.badhash+mem)}

\begin{frame}[fragile]
    \begin{itemize}
    \item
      Suppose we have a \alert{pre-written, pre-tested}
      hash table module, plus a unit test program {\bf testhash}.
      \alert{Passes all tests} (creating, populating,
      finding, iterating over, freeing a single hash table).
    \item
      We've even used it in several successful projects - so
      we're pretty confident that it works!
    \item
      But \alert{we have never checked it} with libmem!  Why not?
    \pause
    \item
      When we prepare to embed our hash table in a larger system,
      we'll need to create, populate and destroy whole hash tables
      \alert{thousands of times}.
    \pause
    \item
      Voice of bitter experience: \alert{Test that scenario} before doing it:-)
    \pause
    \item
      New test program \verb+iterate N M+ that (silently)
      performs all previous tests N times,
      sleeping M seconds afterwards.
    \item
      Behaviour (with M=0) \alert{should be linear with N}.  Test it
      with \verb+time ./iterate N 0+ for several values of N, graph results.
    \pause
    \item
      Find \alert{dramatic non-linear behaviour} around 10-11k
      iterations on lab machines:
      Twice as slow, CPU \%age falls, starts doing I/O.
    \item
      What on earth is happening?
    \end{itemize}
\end{frame}

\begin{frame}[fragile]
    \begin{itemize}
    \item
      Try monitoring with \verb+top+, configured to update
      every second (\alert{d 1}), sort by \%age of memory
      (\alert{O n}).  Write this config out (\alert{W}).
    \pause
    \item
      Run iterate with a time delay: \verb+time ./iterate 11000 10+
      and watch top!  iterate's memory
      \alert{grows bigger than the physical memory},
      tops out at about 85\% of physical memory, the system starts
      \alert{swapping} (\%wait goes busy), load average goes high,
      machine goes \alert{very slow}!
    \pause
    \item
      Hypothesis: the hash table module is leaking some memory,
      ie. failing to free everything that it mallocs.
      A job for libmem!
    \pause
    \item
    Proceed as before:
      \begin{itemize}
       \item append -lmem to LDLIBS in the Makefile
       \item edit *.c and add \verb+#include <mem.h>+ to each
       \item rebuild using 'make clean all'
       \pause
       \item run \verb+./testhash+ [simpler test program]
       \item result: 2 non-freed 256K chunks reported:
\begin{verbatim}
File          Line    Size
hash.c        114     260264
hash.c        75      260264
\end{verbatim}

    \end{itemize}
  \end{itemize}
\end{frame}


\begin{frame}[fragile]
    \begin{itemize}
       \item
       Libmem debugging session continued:
       \begin{itemize}
       \item look at those two lines: line 75 is in \verb+hashCreate(...)+:

\begin{verbatim}
h->data = (tree *) malloc( NHASH*sizeof(tree) );
\end{verbatim}
       \item and line 114 is nearly identical in hashCopy().
\begin{verbatim}
result->data = (tree *) malloc( NHASH*sizeof(tree) );
\end{verbatim}

  \item Look in corresponding \verb+hashFree(hash h)+ function.

  \pause
  \item        Aha!  \verb+h->data+ is NOT FREED.

  \item Add the missing \verb+free(h->data)+, recompile (make).
  \item Rerun \verb+./testhash+ and it reports no unfree()d blocks.
  \item Rerun \verb+./iterate 11000 10+ again - no non linear behaviour,
  no memory leak reported.  Job done!  libmem rocks!
  \end{itemize}

    \pause
    \item
      Summary: \alert{compile everything with libmem from day one}.
      Save yourself loads of grief, double your confidence.
    \item
      Exercise: verify that the list example (in
      Lecture 1's \alert{01.list}) runs cleanly with libmem.
      (Import CFLAGS and LDLIBS from \alert{03.mem-eg}'s Makefile).
    \end{itemize}
\end{frame}

\section{Optimization and Profiling}
\subsection{tarball 06.hash-profile}

\begin{frame}[fragile]
    \begin{itemize}
    \item
      \alert{gcc} and most other C compilers can be asked to
      \alert{optimize the code they generate}, gcc's option for this
      is \alert{-O}.
      Worth trying, rarely makes a significant difference.
    \pause
    \item
      What makes far more difference is finding the \alert{hot spots}
      using a \alert{profiler} and selectively optimizing them.
      Can produce dramatic speedups, and profiling often produces surprises.
    \pause
    \item
      Let's try profiling the bugfixed hash module's \alert{iterate 10000}
      test program, and see what surprises there may be:
      \begin{itemize}
      \item
        Add -pg to CFLAGS and LDLIBS in Makefile.
      \pause
      \item
	Run \verb+make clean all+
	(compile and link with \alert{-pg}, which generates instrumented
        code which tracks function entry and exit times.
      \pause
      \item
	Run \verb+./iterate 10000+, which
	runs a bit slower than normal
  	(because profiling slows it down a bit),
  	producing a binary profiling file called \alert{gmon.out}.
      \pause
      \item
      The tool \alert{gprof} then analyzes the executable and the
      data file, producing a report showing the top 10 functions
      (across all their calls) sorted by percentage of total runtime.
      Run:
         \verb+gprof ./iterate gmon.out > profile.orig+
      \end{itemize}
    \end{itemize}
\end{frame}

\begin{frame}[fragile]
    \begin{itemize}
    \item
      \alert{head profile.orig} shows results like:
\small
\begin{verbatim}
  %    cumul    self              self   total           
 time  seconds  seconds  calls us/call us/call name    
 38.71   3.37   3.37     20000  168.37  206.96 hashFree
 22.92   5.36   1.99     10000  199.44  289.14 hashCopy
 11.29   6.34   0.98     10000   98.22   98.22 hashCreate
 10.31   7.24   0.90 325330000   0.00    0.00 copy_tree
  8.87   8.01   0.77 650660000   0.00    0.00 free_tree
\end{verbatim}
    \pause
    \item
    650 million calls to \alert{free\_tree} and
    325 million calls to \alert{copy\_tree} are suspicious.
    Aha!  The hash table's \alert{array of trees} has 32533 entries!
    \pause
    \item
    \alert{hashFree} and \alert{hashCopy} have the same
    structure, iterating over the array of trees
    making one call to \alert{free\_tree/copy\_tree} per tree.
    The \alert{vast majority} of these trees are \alert{empty}.
    \pause
    \item
    We can \alert{double the speed} of \alert{iterate} by adding
    \alert{if( the\_tree != NULL )} conditions on tree calls
    in \alert{hashFree, hashCopy}
    and others.
    \pause
    \item
    We might also consider shrinking the size of the array of trees
    to some smaller prime number - or, more radically, adding code to
    dynamically resize the array (and rehash all the keys) when the
    hash gets full.
    \end{itemize}
\end{frame}

\section{Autogenerating ADTs}
\subsection{datadec (08.datadec/09.datadec-eg)}

\begin{frame}[fragile]
    \begin{itemize}
    \item
      \alert{Principle:}
      It's often an excellent idea to
      \alert{import cool features from other languages}.
    \item
      For example, Perl teaches us the importance of
      \alert{hashes}
      (aka Java dictionaries) -
      \alert{(key,value)} storage implemented using hash tables.
      We've already seen a hash module bring this ability to C.
    \pause
    \item
      Many years ago, I realised that one of the best
      features of \alert{functional programming languages}
      such as Haskell is the ability to define
      \alert{inductive data types}, as in:
\begin{verbatim}
intlist = nil or cons( int head, intlist tail );
\end{verbatim}
    \pause
    \item
      I'd dearly love to have that ability in C.
      \pause
      If only there
      was a tool that \alert{reads such type definitions} and automatically
      writes a \alert{C module that implements them}..
    \pause
    \item
      I looked around, couldn't find anything anywhere.
      Noone seemed to have ever suggested that such a tool could
      be useful!
    \pause
    \item
      Decision time: do I abandon my brilliant idea, or \alert{make the tool}?
    \item
      Think hard: a serious tool, parser, lexical analyser,
      data structures, tree walking code generator:
      at least a week's work!
    \end{itemize}
\end{frame}

\begin{frame}[fragile]
    \begin{itemize}
    \item
      I made the tool!  After a fortnight's work, the
      result was \alert{datadec} - in the \alert{08.datadec} directory,
      older version installed on DoC linux machines.
      After installing it, use it as follows:
    \pause
    \item
      In \alert{09.datadec-eg} you'll find an input file
      \alert{types.in} containing:
      \small
\begin{verbatim}
TYPE {
       intlist =  nil or cons( int first, intlist next );
       illist  =  nil or cons( intlist first, illist next );
       idtree  =  leaf( string id )
               or node( idtree left, idtree right );
}
\end{verbatim}
    \pause
    \item
       To generate a C module called \alert{datatypes} from \alert{types.in},
       invoke:
\begin{verbatim}
  datadec datatypes types.in
\end{verbatim}
    \pause
    \item
       \alert{datatypes.c} and \alert{datatypes.h} are normal C files,
       you can read them, write test programs against the interface,
       use them in production code.
       \pause
       But don't modify these files - if you do then you can't...
    \pause
    \item
       ... change \alert{types.in} later - suppose you realise that
       an idtree node needs to store an id as well as the trees.  Change the
       type defn, rerun \alert{datadec}.  The \verb+idtree_node()+
       constructor now takes 3 arguments!
    \end{itemize}
\end{frame}

\begin{frame}[fragile]
    \begin{itemize}
    \item
      Let's look inside \alert{datatypes.h},
      to find what \alert{idtree} functions datadec generates.
      First we find two {\em constructors}:
      \tiny
\begin{verbatim}
  extern idtree idtree_leaf( string );
  extern idtree idtree_node( idtree, idtree );
\end{verbatim}
      \small

    %\pause
    \item
      Then we find a function telling you whether a tree is a leaf
      or a node:
      \tiny
\begin{verbatim}
  extern kind_of_idtree idtree_kind( idtree );
\end{verbatim}
      \small
    %\pause
      Using the enumerated type:
      \tiny
\begin{verbatim}
  typedef enum { idtree_is_leaf, idtree_is_node } kind_of_idtree;
\end{verbatim}
      \small
    %\pause
    \item
      Then two deconstructor functions which, given a tree of the
      appropriate shape, breaks it into it's constituent pieces:
      \tiny
\begin{verbatim}
  extern void get_idtree_leaf( idtree, string * );
  extern void get_idtree_node( idtree, idtree *, idtree * );
\end{verbatim}
      \small

    \pause
    \item
      The final function prints a tree to a file in human readable format
      (which you can control):
      \tiny
\begin{verbatim}
  extern void print_idtree( FILE *, idtree );
\end{verbatim}
      \small
    %\pause
    \item
      By default, there's no free functions.  Surprisingly hard to
      automatically generate due to shallow vs deep considerations.
    \pause
    \item
      New this year: run \alert{datadec -f..} and get experimental
      \alert{free\_TYPE()} functions.  If you don't
      want a parameter freed, mark it in the input file with a `-',
      as in:

      \tiny
\begin{verbatim}
  idtree  =  leaf( -string id )
          or node( idtree left, idtree right );
\end{verbatim}
\small

    \end{itemize}
\end{frame}


\begin{frame}[fragile]
    \begin{itemize}
    \item
      Looking in \alert{testidtree.c}, we build two leaves, and then
      test that we can break them apart again:
\tiny
\begin{verbatim}
  idtree t1 = idtree_leaf( "absolutely" );
  testleaf( t1, "absolutely", "ab" );
  idtree t2 = idtree_leaf( "fabulous" );
  testleaf( t2, "fabulous", "fab" );
\end{verbatim}
\small
    \item
      \alert{testleaf(t, expected, treename)} tests that t is
      a leaf with the expected id, treename is a symbolic name for the tree:
\tiny
\begin{verbatim}
  void testleaf( idtree t, char *expected, char *treename )
  {
    char label[1024];
    sprintf( label, "isnode(%s)", treename );
    inteqtest( idtree_kind(t), idtree_is_leaf, label );
    string id;
    get_idtree_leaf( t, &id );
    sprintf( label, "getleaf(%s)", treename );
    streqtest( id, expected, label );
  }
\end{verbatim}
\small

    \pause
    \item
      \alert{inteqtest(value, expected, label)} and
      \alert{streqtest(value, expected, label)}
      are integer and string equality tests that print ok/fail messages.
    \pause
    \item
      Next, \alert{testidtree.c} constructs a node from our two leaves,
      and tests that we can break it apart correctly:
\tiny
\begin{verbatim}
  idtree t = idtree_node( t1, t2 );
  inteqtest( idtree_kind(t), idtree_is_node,
             "isnode((ab,fab))" );
  idtree l, r;
  get_idtree_node( t, &l, &r );
  testleaf( l, "absolutely", "left((ab,fab))" );
  testleaf( r, "fabulous", "right((ab,fab))" );
\end{verbatim}
\small
\end{itemize}
\end{frame}

\section{Reusable ADT modules}
\subsection{hashes, lists, trees, sets etc}

\begin{frame}
    \begin{itemize}
    \item
      Most problems are made a lot easier by having a library
      of trusted modules -
      whether \alert{datadec-generated} or handwritten:
      \begin{itemize}
      \item
      indefinite length \alert{dynamic strings}
      \item
      indefinite length \alert{dynamic arrays}
      \item
      indefinite length \alert{sparse dynamic arrays}
      \pause
      \item
      \alert{linked lists} (single or double linked)
      \item
      \alert{stacks} (can just use lists)
      \item
      \alert{queues} and \alert{priority queues}
      \item
      \alert{binary trees}
      \pause
      \item
      \alert{hashes}
      \item
      \alert{sets} - hashes with no values?  trees? sparse arrays?
      \item
      \alert{bags} - frequency hashes
      \pause
      \item
      anything else you find useful (.ini file parsers? test frameworks?)
      \end{itemize}
    \pause
    \item
      The C standard library fails to provide any of the following
      (C++ provides the \alert{Standard Template Library}):
      So \alert{build them yourself} as and when you need them, and
      \alert{reuse them} at every opportunity, to raise C to
      a higher level!
    \item
      Reuse can be done without object orientation, it's
      not hard!
    \end{itemize}
\end{frame}

\end{document}
