Changes in / [b0ab7853:35a408b7]


Ignore:
Files:
2 added
4 edited

Legend:

Unmodified
Added
Removed

  • benchmark/Makefile.am

    rb0ab7853 r35a408b7  
    1111## Created On       : Sun May 31 09:08:15 2015
    1212## Last Modified By : Peter A. Buhr
    13 ## Last Modified On : Mon Jun 24 16:45:42 2019
    14 ## Update Count     : 53
     13## Last Modified On : Sun Jun 23 12:34:29 2019
     14## Update Count     : 52
    1515###############################################################################
    1616
    … …  
    3131BENCH_V_JAVAC = $(__bench_v_JAVAC_$(__quiet))
    3232BENCH_V_UPP = $(__bench_v_UPP_$(__quiet))
     33BENCH_V_QTHREAD = $(__bench_v_QTHREAD_$(__quiet))
    3334
    3435__quiet = verbose
    … …  
    4546__bench_v_JAVAC_verbose = $(AM_V_JAVAC)
    4647__bench_v_UPP_verbose = $(AM_V_UPP)
     48__bench_v_QTHREAD_verbose = $(AM_V_CC)
    4749
    4850
    … …  
    174176        ctxswitch-upp_thread.run        \
    175177        ctxswitch-goroutine.run         \
    176         ctxswitch-java_thread.run
     178        ctxswitch-java_thread.run       \
     179        ctxswitch-qthreads.run
    177180
    178181
    … …  
    221224        @echo "java JavaThread" >> a.out
    222225        @chmod a+x a.out
     226
     227ctxswitch-qthreads$(EXEEXT):
     228        $(BENCH_V_QTHREADS)$(COMPILE) -DBENCH_N=50000000 -I/u/pabuhr/software/qthreads/include -L/u/pabuhr/software/qthreads/lib -Xlinker -R/u/pabuhr/software/qthreads/lib $(srcdir)/ctxswitch/qthreads.c -lqthread
    223229
    224230## =========================================================================================================
    … …  
    314320        creation-upp_thread.run                 \
    315321        creation-goroutine.run                  \
    316         creation-java_thread.run
     322        creation-java_thread.run                \
     323        creation-qthreads.run
    317324
    318325creation-cfa_coroutine$(EXEEXT):
    … …  
    342349        @echo "java JavaThread" >> a.out
    343350        @chmod a+x a.out
     351
     352creation-qthreads$(EXEEXT):
     353        $(BENCH_V_QTHREADS)$(COMPILE) -DBENCH_N=50000000 -I/u/pabuhr/software/qthreads/include -L/u/pabuhr/software/qthreads/lib -Xlinker -R/u/pabuhr/software/qthreads/lib $(srcdir)/ctxswitch/qthreads.c -lqthread
    344354
    345355## =========================================================================================================

  • doc/bibliography/pl.bib

    rb0ab7853 r35a408b7  
    954954    key         = {Cforall Benchmarks},
    955955    author      = {{\textsf{C}{$\mathbf{\forall}$} Benchmarks}},
    956     howpublished= {\href{https://plg.uwaterloo.ca/~cforall/benchmark.tar}{https://\-plg.uwaterloo.ca/\-$\sim$cforall/\-benchmark.tar}},
     956    howpublished= {\href{https://plg.uwaterloo.ca/~cforall/benchmarks}{https://\-plg.uwaterloo.ca/\-$\sim$cforall/\-benchmarks}},
    957957}
    958958

  • doc/papers/concurrency/Paper.tex

    rb0ab7853 r35a408b7  
    316316Finally, performant user-threading implementations (both time and space) meet or exceed direct kernel-threading implementations, while achieving the programming advantages of high concurrency levels and safety.
    317317
    318 A further effort over the past two decades is the development of language memory models to deal with the conflict between language features and compiler/hardware optimizations, \ie some language features are unsafe in the presence of aggressive sequential optimizations~\cite{Buhr95a,Boehm05}.
     318A further effort over the past two decades is the development of language memory models to deal with the conflict between language features and compiler/hardware optimizations, \ie, some language features are unsafe in the presence of aggressive sequential optimizations~\cite{Buhr95a,Boehm05}.
    319319The consequence is that a language must provide sufficient tools to program around safety issues, as inline and library code is all sequential to the compiler.
    320 One solution is low-level qualifiers and functions (\eg @volatile@ and atomics) allowing \emph{programmers} to explicitly write safe (race-free~\cite{Boehm12}) programs.
     320One solution is low-level qualifiers and functions (\eg, @volatile@ and atomics) allowing \emph{programmers} to explicitly write safe (race-free~\cite{Boehm12}) programs.
    321321A safer solution is high-level language constructs so the \emph{compiler} knows the optimization boundaries, and hence, provides implicit safety.
    322322This problem is best known with respect to concurrency, but applies to other complex control-flow, like exceptions\footnote{
    … …  
    324324The key feature that dovetails with this paper is nonlocal exceptions allowing exceptions to be raised across stacks, with synchronous exceptions raised among coroutines and asynchronous exceptions raised among threads, similar to that in \uC~\cite[\S~5]{uC++}
    325325} and coroutines.
    326 Finally, language solutions allow matching constructs with language paradigm, \ie imperative and functional languages often have different presentations of the same concept to fit their programming model.
     326Finally, language solutions allow matching constructs with language paradigm, \ie, imperative and functional languages often have different presentations of the same concept to fit their programming model.
    327327
    328328Finally, it is important for a language to provide safety over performance \emph{as the default}, allowing careful reduction of safety for performance when necessary.
    329 Two concurrency violations of this philosophy are \emph{spurious wakeup} (random wakeup~\cite[\S~8]{Buhr05a}) and \emph{barging} (signals-as-hints~\cite[\S~8]{Buhr05a}), where one is a consequence of the other, \ie once there is spurious wakeup, signals-as-hints follow.
     329Two concurrency violations of this philosophy are \emph{spurious wakeup} (random wakeup~\cite[\S~8]{Buhr05a}) and \emph{barging} (signals-as-hints~\cite[\S~8]{Buhr05a}), where one is a consequence of the other, \ie, once there is spurious wakeup, signals-as-hints follow.
    330330However, spurious wakeup is \emph{not} a foundational concurrency property~\cite[\S~8]{Buhr05a}, it is a performance design choice.
    331331Similarly, signals-as-hints are often a performance decision.
    … …  
    337337Most augmented traditional (Fortran 18~\cite{Fortran18}, Cobol 14~\cite{Cobol14}, Ada 12~\cite{Ada12}, Java 11~\cite{Java11}) and new languages (Go~\cite{Go}, Rust~\cite{Rust}, and D~\cite{D}), except \CC, diverge from C with different syntax and semantics, only interoperate indirectly with C, and are not systems languages, for those with managed memory.
    338338As a result, there is a significant learning curve to move to these languages, and C legacy-code must be rewritten.
    339 While \CC, like \CFA, takes an evolutionary approach to extend C, \CC's constantly growing complex and interdependent features-set (\eg objects, inheritance, templates, etc.) mean idiomatic \CC code is difficult to use from C, and C programmers must expend significant effort learning \CC.
     339While \CC, like \CFA, takes an evolutionary approach to extend C, \CC's constantly growing complex and interdependent features-set (\eg, objects, inheritance, templates, etc.) mean idiomatic \CC code is difficult to use from C, and C programmers must expend significant effort learning \CC.
    340340Hence, rewriting and retraining costs for these languages, even \CC, are prohibitive for companies with a large C software-base.
    341341\CFA with its orthogonal feature-set, its high-performance runtime, and direct access to all existing C libraries circumvents these problems.
    … …  
    367367\section{Stateful Function}
    368368
    369 The stateful function is an old idea~\cite{Conway63,Marlin80} that is new again~\cite{C++20Coroutine19}, where execution is temporarily suspended and later resumed, \eg plugin, device driver, finite-state machine.
     369The stateful function is an old idea~\cite{Conway63,Marlin80} that is new again~\cite{C++20Coroutine19}, where execution is temporarily suspended and later resumed, \eg, plugin, device driver, finite-state machine.
    370370Hence, a stateful function may not end when it returns to its caller, allowing it to be restarted with the data and execution location present at the point of suspension.
    371371This capability is accomplished by retaining a data/execution \emph{closure} between invocations.
    372 If the closure is fixed size, we call it a \emph{generator} (or \emph{stackless}), and its control flow is restricted, \eg suspending outside the generator is prohibited.
    373 If the closure is variable size, we call it a \emph{coroutine} (or \emph{stackful}), and as the names implies, often implemented with a separate stack with no programming restrictions.
     372If the closure is fixed size, we call it a \emph{generator} (or \emph{stackless}), and its control flow is restricted, \eg, suspending outside the generator is prohibited.
     373If the closure is variably sized, we call it a \emph{coroutine} (or \emph{stackful}), and as the names implies, often implemented with a separate stack with no programming restrictions.
    374374Hence, refactoring a stackless coroutine may require changing it to stackful.
    375 A foundational property of all \emph{stateful functions} is that resume/suspend \emph{do not} cause incremental stack growth, \ie resume/suspend operations are remembered through the closure not the stack.
     375A foundational property of all \emph{stateful functions} is that resume/suspend \emph{do not} cause incremental stack growth, \ie, resume/suspend operations are remembered through the closure not the stack.
    376376As well, activating a stateful function is \emph{asymmetric} or \emph{symmetric}, identified by resume/suspend (no cycles) and resume/resume (cycles).
    377377A fixed closure activated by modified call/return is faster than a variable closure activated by context switching.
    378 Additionally, any storage management for the closure (especially in unmanaged languages, \ie no garbage collection) must also be factored into design and performance.
     378Additionally, any storage management for the closure (especially in unmanaged languages, \ie, no garbage collection) must also be factored into design and performance.
    379379Therefore, selecting between stackless and stackful semantics is a tradeoff between programming requirements and performance, where stackless is faster and stackful is more general.
    380380Note, creation cost is amortized across usage, so activation cost is usually the dominant factor.
    … …  
    648648\end{center}
    649649The example takes advantage of resuming a generator in the constructor to prime the loops so the first character sent for formatting appears inside the nested loops.
    650 The destructor provides a newline, if formatted text ends with a full line.
     650The destructor provides a newline if formatted text ends with a full line.
    651651Figure~\ref{f:CFormatSim} shows the C implementation of the \CFA input generator with one additional field and the computed @goto@.
    652652For contrast, Figure~\ref{f:PythonFormatter} shows the equivalent Python format generator with the same properties as the Fibonacci generator.
    … …  
    27192719Each benchmark experiment is run 31 times.
    27202720All omitted tests for other languages are functionally identical to the \CFA tests and available online~\cite{CforallBenchMarks}.
    2721 % tar --exclude=.deps --exclude=Makefile --exclude=Makefile.in --exclude=c.c --exclude=cxx.cpp --exclude=fetch_add.c -cvhf benchmark.tar benchmark
     2721
    27222722
    27232723\paragraph{Object Creation}
    … …  
    27492749\multicolumn{1}{@{}c}{} & \multicolumn{1}{c}{Median} & \multicolumn{1}{c}{Average} & \multicolumn{1}{c@{}}{Std Dev} \\
    27502750\CFA Coroutine Lazy             & 14.3          & 14.3          & 0.32          \\
    2751 \CFA Coroutine Eager    & 522.8         & 525.3         & 5.81          \\
     2751\CFA Coroutine Eager    & 2203.7        & 2205.6        & 26.03         \\
    27522752\CFA Thread                             & 1257.8        & 1291.2        & 86.19         \\
    27532753\uC Coroutine                   & 92.2          & 91.4          & 1.58          \\

  • doc/user/user.tex

    rb0ab7853 r35a408b7  
    1111%% Created On       : Wed Apr  6 14:53:29 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Tue Jun 25 08:51:33 2019
    14 %% Update Count     : 3871
     13%% Last Modified On : Sat Jun 15 16:29:45 2019
     14%% Update Count     : 3847
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
    … …  
    33463346
    33473347
    3348 \section{Stream I/O Library}
    3349 \label{s:StreamIOLibrary}
     3348\section{I/O Stream Library}
     3349\label{s:IOStreamLibrary}
    33503350\index{input/output stream library}
    33513351\index{stream library}
    33523352
    3353 The goal of \CFA stream input/output (I/O) is to simplify the common cases\index{I/O!common case}, while fully supporting polymorphism and user defined types in a consistent way.
    3354 Stream I/O can be implicitly or explicitly formatted.
    3355 Implicit formatting means \CFA selects the output or input format for values that match with the type of a variable.
    3356 Explicit formatting means additional information is specified to augment how an output or input of value is interpreted.
    3357 \CFA formatting is a cross between C ©printf© and \CC ©cout© manipulators, and Python implicit spacing and newline.
    3358 Specifically:
     3353The goal of \CFA input/output (I/O) is to simplify the common cases\index{I/O!common case}, while fully supporting polymorphism and user defined types in a consistent way.
     3354\CFA I/O combines ideas from C ©printf©, \CC, and Python.
     3355I/O can be unformatted or formatted.
     3356Unformatted means \CFA selects the output or input format for values that match with the type of a variable.
     3357Formatted means additional information is specified to augment how an output or input of value is interpreted.
     3358\CFA formatting is a cross between C ©printf© and \CC ©cout© manipulators.
    33593359\begin{itemize}
    33603360\item
    3361 ©printf©/Python format codes are dense, making them difficult to read and remember.
     3361©printf© format codes are dense, making them difficult to read and remember.
    33623362\CFA/\CC format manipulators are named, making them easier to read and remember.
    33633363\item
    3364 ©printf©/Python separates format codes from associated variables, making it difficult to match codes with variables.
     3364©printf© separates format codes from associated variables, making it difficult to match codes with variables.
    33653365\CFA/\CC co-locate codes with associated variables, where \CFA has the tighter binding.
    33663366\item
    3367 Format manipulators in \CFA have local effect, whereas \CC have global effect, except ©setw©.
     3367Format manipulators in \CC have global rather than local effect, except ©setw©.
    33683368Hence, it is common programming practice to toggle manipulators on and then back to the default to prevent downstream side-effects.
    33693369Without this programming style, errors occur when moving prints, as manipulator effects incorrectly flow into the new location.
    33703370(To guarantee no side-effects, manipulator values must be saved and restored across function calls.)
    3371 \item
    3372 \CFA has more sophisticated implicit spacing between values than Python, plus implicit newline at the end of a print.
    33733371\end{itemize}
    33743372The \CFA header file for the I/O library is \Indexc{fstream.hfa}.
    33753373
    3376 For implicit formatted output, the common case is printing a series of variables separated by whitespace.
     3374For unformatted output, the common case is printing a sequence of variables separated by whitespace.
    33773375\begin{cquote}
    3378 \begin{tabular}{@{}l@{\hspace{2em}}l@{\hspace{2em}}l@{}}
    3379 \multicolumn{1}{c@{\hspace{2em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{\CC}}       & \multicolumn{1}{c}{\textbf{Python}}   \\
     3376\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
     3377\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{\CC}}      \\
    33803378\begin{cfa}
    33813379int x = 1, y = 2, z = 3;
    … …  
    33873385cout << x ®<< " "® << y ®<< " "® << z << endl;
    33883386\end{cfa}
    3389 &
    3390 \begin{cfa}
    3391 x = 1;  y = 2;  z = 3
    3392 print( x, y, z )
    3393 \end{cfa}
    33943387\\
    3395 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
    3396 1® ®2® ®3
    3397 \end{cfa}
    3398 &
    33993388\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
    340033891® ®2® ®3
    … …  
    34403429There is a weak similarity between the \CFA logical-or operator and the \Index{Shell pipe-operator} for moving data, where data flows in the correct direction for input but the opposite direction for output.
    34413430
    3442 For implicit formatted input, the common case is reading a sequence of values separated by whitespace, where the type of an input constant must match with the type of the input variable.
     3431For unformatter input, the common case is reading a sequence of values separated by whitespace, where the type of an input constant must match with the type of the input variable.
    34433432\begin{cquote}
    34443433\begin{lrbox}{\LstBox}
    … …  
    34473436\end{cfa}
    34483437\end{lrbox}
    3449 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{3em}}l@{}}
     3438\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    34503439\multicolumn{1}{@{}l@{}}{\usebox\LstBox} \\
    3451 \multicolumn{1}{c@{\hspace{2em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{\CC}}       & \multicolumn{1}{c}{\textbf{Python}}   \\
     3440\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{\CC}}      \\
    34523441\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    34533442sin | x | y | z;
    … …  
    34573446cin >> x >> y >> z;
    34583447\end{cfa}
    3459 &
    3460 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
    3461 x = int(input());  y = float(input());  z = input();
    3462 \end{cfa}
    34633448\\
    34643449\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
    34653450®1® ®2.5® ®A®
    3466 
    3467 
    34683451\end{cfa}
    34693452&
    34703453\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
    34713454®1® ®2.5® ®A®
    3472 
    3473 
    3474 \end{cfa}
    3475 &
    3476 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
    3477 ®1®
    3478 ®2.5®
    3479 ®A®
    34803455\end{cfa}
    34813456\end{tabular}
    … …  
    373037050b0 0b11011 0b11011 0b11011 0b11011
    37313706sout | bin( -27HH ) | bin( -27H ) | bin( -27 ) | bin( -27L );
    3732 0b11100101 0b1111111111100101 0b11111111111111111111111111100101 0b®(58 1s)®100101
     37070b11100101 0b1111111111100101 0b11111111111111111111111111100101 0b(58 1s)100101
    37333708\end{cfa}
    37343709
    … …  
    38073782®  ®4.000000 ® ®4.000000 4.000000
    38083783®  ®ab ® ®ab ab
     3784    ab    ab ab
    38093785\end{cfa}
    38103786If the value is larger, it is printed without truncation, ignoring the ©minimum©.
Note: See TracChangeset for help on using the changeset viewer.