Context Navigation

-              r379b6ea
+              rb1c220a
 There are tradeoffs associated with the copy-on-write mechanism.
+Several qualitative matters are detailed in the \VRef{s:PerformanceAssessment} and the qualitative issue of multi-threaded support is introduced here.
+The \CFA sting library provides a switch to disable the sharing mechanism for situations where it is inappropriate.
+Because of the inter-linked string handles, any participant managing one string is also managing, directly, the neighbouring strings, and from there, a data structure of the ``set of all strings.''  This data structure is intended for sequential access.
+A negative consequence of this decision is that multiple threads using strings need to be set up so that they avoid attempting to modify (concurrently) an instance of this structure.
+A positive consequence is that a single-threaded program, or a program with several independent threads, can use the sharing context without locking overhead.
+Several qualitative matters are detailed in \VRef{s:PerformanceAssessment} and the qualitative issue of multi-threaded support is introduced here.
+The \CFA string library provides a switch to disable threads allocating from the string buffer, when string sharing is unsafe.
+When toggled, string management is moved to the storage allocator, specifically @malloc@/@free@, where the storage allocator is assumed to be thread-safe.
+In detail, string sharing has inter-linked string handles, so any participant managing one string is also managing, directly, the neighbouring strings, and from there, a data structure of the ``set of all strings.''
+This string structure is intended for sequential access.
+Hence, multiple threads using shared strings need to avoid modifying (concurrently) an instance of this structure (like Java immutable strings).
+A positive consequence of this approach is that independent threads can use the sharing buffer without locking overhead.
 When the string library is running with sharing disabled, it runs without implicit thread-safety challenges, which is the same as the \CC STL, and with performance goals similar to the STL.
 …
 Hence, concurrent users of string objects must still bring their own mutual exclusion, but the string library does not add any cross thread uses that are not apparent in a user's code.
 The \CFA string library provides the type @string_sharectx@to control an ambient sharing context for the current thread.
+The \CFA string library provides the type @string_sharectx@ to control an ambient sharing context for a current thread.
 It allows two adjustments: to opt out of sharing entirely or to begin sharing within a private context.
 Either way, the chosen mode applies only to the current thread, for the duration of the lifetime of the created  @string_sharectx@ object, up to being suspended by child lifetimes of different contexts.
 …
         \lstinputlisting[language=CFA, firstline=10, lastline=55]{sharectx.run.cfa}
+        &
         \includegraphics{string-sharectx.pdf}
+        \raisebox{-0.17\totalheight}{\includegraphics{string-sharectx.pdf}} % lower
     \end{tabular}
         \caption{Controlling copying vs sharing of strings using \lstinline{string_sharectx}.}
 …
 To discuss: general goal of ...
 while STL makes you think about memory management, all the time, and if you do your performance can be great ...
+while STL makes you think about memory management, all the time, and if you do, your performance can be great ...
 \CFA sacrifices this advantage modestly in exchange for big wins when you're not thinking about memory management.
 [Does this position cover all of it?]
 …
 \subsection{Methodology}
 These tests use randomly generated text fragments of varying lengths.
+These tests use randomly generated varying-length strings (string content is immaterial).
 A collection of such fragments is a \emph{corpus}.
 The mean length of a fragment from a corpus is a typical explanatory variable.
 …
 \end{description}
 The geometric distribution implies that lengths much longer than the mean occur frequently.
 The special treatment of length 16 deals with comparison to STL, given that STL has short-string optimization (see [TODO: write and cross-ref future-work SSO]), currently not implemented in \CFA.
 When success, notwithstanding SSO, is illustrated, a fixed-size or from-16 distribution ensures that extra-optimized cases are not part of the mix on the STL side.
+The special treatment of length 16 deals with comparison to STL, given that STL has a short-string optimization (see [TODO: write and cross-ref future-work SSO]), currently not implemented in \CFA.
+When success is illustrated, notwithstanding SSO, a fixed-size or from-16 distribution ensures that extra-optimized cases are not part of the mix on the STL side.
 In all experiments that use a corpus, its text is generated and loaded into the SUT before the timed phase begins.
 …
 Another experimental variable is whether the user's logical allocation is fresh \vs reused.
 Here, \emph{reusing a logical allocation}, means that the program variable, into which the user is concatenating, previously held a long string:\\
+Here, \emph{reusing a logical allocation}, means that the program variable, into which the user is concatenating, previously held a long string:
 \begin{cquote}
 \setlength{\tabcolsep}{20pt}
 \begin{tabular}{@{}ll@{}}
+\multicolumn{1}{c}{\textbf{fresh}} & \multicolumn{1}{c}{\textbf{reuse}} \\
 \begin{cfa}
 for ( ... ) {
         @string x;@   // fresh
+        @string x;@
         for ( ... )
                 x += ...
 …
 string x;
 for ( ... ) {
         @x = "";@  // reused
+        @x = "";@
         for ( ... )
                 x += ...
 …
 \end{tabular}
 \end{cquote}
+These benchmark drivers have an outer loop for ``until a sample-worthy amount of execution has happened'' and an inner loop for ``build up the desired-length string.''
+All benchmark drivers have an outer loop for ``until a sample-worthy amount of execution has happened'' and an inner loop for ``building up the desired-length string.''
 In general, a user should not have to care about this difference, yet the STL performs differently in these cases.
 Furthermore, if a routine takes a string by reference, if cannot use the fresh approach.
 …
 For the STL, this cost includes obtaining a fresh buffer from the memory allocator and copying older characters into the new buffer, while \CFA-sharing hides such a cost entirely.
 The fresh \vs reuse distinction is only relevant in the \emph{append} tests.
-The \emph{append} tests use the varying-from-1 corpus construction, \ie they do not assume away the STL's advantage for small-string optimization.
-\PAB{To discuss: any other case variables introduced in the performance intro}
-\VRef[Figure]{fig:string-graph-peq-cppemu} shows this behaviour, by the STL and by \CFA in STL emulation mode.
-\CFA reproduces STL's performance, up to a 15\% penalty averaged over the cases shown, diminishing with larger strings, and 50\% in the worst case.
-This penalty characterizes the amount of implementation fine tuning done with STL and not done with \CFA in present state.
-The larger inherent penalty, for a user mismanaging reuse, is 40\% averaged over the cases shown, is minimally 24\%, shows up consistently between the STL and \CFA implementations, and increases with larger strings.
 \begin{figure}
 …
 \end{figure}
+The \emph{append} tests use the varying-from-1 corpus construction, \ie they assume the STL's advantage of small-string optimization.
+\PAB{To discuss: any other case variables introduced in the performance intro}
+\VRef[Figure]{fig:string-graph-peq-cppemu} shows this behaviour, by the STL and by \CFA in STL emulation mode.
+\CFA reproduces STL's performance, up to a 15\% penalty averaged over the cases shown, diminishing with larger strings, and 50\% in the worst case.
+This penalty characterizes the amount of implementation fine tuning done with STL and not done with \CFA in present state.
+\PAB{The larger inherent penalty, for a user mismanaging reuse, is 40\% averaged over the cases shown, is minimally 24\%, shows up consistently between the STL and \CFA implementations, and increases with larger strings.}
 \begin{figure}
 \centering
 …
         \includegraphics{string-graph-pta-sharing.pdf}
 %       \includegraphics[width=\textwidth]{string-graph-pta-sharing.png}
         \caption{Average time per iteration (lower is better) with one \lstinline{x = x + y} invocation (new, purple bands), comparing \CFA (having implicit sharing activated) with STL.
+        \caption{Average time per iteration (lower is better) with one \lstinline{x = x + y} invocation, comparing \CFA (having implicit sharing activated) with STL.
 For context, the results from \VRef[Figure]{fig:string-graph-peq-sharing} are repeated as the bottom bands.
 While not a design goal, and not graphed out, \CFA in STL-emulation mode outperformed STL in this case; user-managed allocation reuse did not affect any of the implementations in this case.}
 …
 To have introduced:  STL string library forces users to think about memory management when communicating values across a function call
+\begin{cfa}
+void foo( string s );
+string s = "abc";
+foo( s );
+\end{cfa}
 STL charges a prohibitive penalty for passing a string by value.
 With implicit sharing active, \CFA treats this operation as normal and supported.
 …
 STL's performance worsens as string length increases, while \CFA has the same performance at all sizes.
 The \CFA cost to pass is nontrivial.
+The \CFA cost to pass a string is nontrivial.
 The contributor is adding and removing the callee's string handle from the global list.
 This cost is $1.5 \times$ to $2 \times$ over STL's when small-string optimization applies, though this cost should be avoidable in the same case, given a \CFA realization of this optimization.

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset b1c220a for doc/theses/mike_brooks_MMath/string.tex

Legend:

doc/theses/mike_brooks_MMath/string.tex

Download in other formats: