Changeset 64dc36e

Timestamp:

Jun 24, 2019, 5:00:47 PM (5 years ago)

Author:

Peter A. Buhr <pabuhr@…>

Branches:

ADT, arm-eh, ast-experimental, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, pthread-emulation, qualifiedEnum

Children:

28564382

Parents:

1335e6f

Message:

remove qthreads benchmark and correct citation name for public access to benchmarks

Files:

• benchmark/Makefile.am (modified) (7 diffs)
• benchmark/creation/qthreads.c (deleted)
• benchmark/ctxswitch/qthreads.c (deleted)
• doc/bibliography/pl.bib (modified) (1 diff)
• doc/papers/concurrency/Paper.tex (modified) (7 diffs)

benchmark/Makefile.am

@@ -11 +11 @@
 ## Created On       : Sun May 31 09:08:15 2015
 ## Last Modified By : Peter A. Buhr
-## Last Modified On : Sun Jun 23 12:34:29 2019
-## Update Count     : 52
+## Last Modified On : Mon Jun 24 16:45:42 2019
+## Update Count     : 53
 ###############################################################################
 
@@ -31 +31 @@
 BENCH_V_JAVAC = $(__bench_v_JAVAC_$(__quiet))
 BENCH_V_UPP = $(__bench_v_UPP_$(__quiet))
-BENCH_V_QTHREAD = $(__bench_v_QTHREAD_$(__quiet))
 
 __quiet = verbose
@@ -46 +45 @@
 __bench_v_JAVAC_verbose = $(AM_V_JAVAC)
 __bench_v_UPP_verbose = $(AM_V_UPP)
-__bench_v_QTHREAD_verbose = $(AM_V_CC)
 
 
@@ -176 +174 @@
         ctxswitch-upp_thread.run        \
         ctxswitch-goroutine.run         \
-        ctxswitch-java_thread.run       \
-        ctxswitch-qthreads.run
+        ctxswitch-java_thread.run
 
 
@@ -224 +221 @@
         @echo "java JavaThread" >> a.out
         @chmod a+x a.out
-
-ctxswitch-qthreads$(EXEEXT):
-        $(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
 
 ## =========================================================================================================
@@ -320 +314 @@
         creation-upp_thread.run                 \
         creation-goroutine.run                  \
-        creation-java_thread.run                \
-        creation-qthreads.run
+        creation-java_thread.run
 
 creation-cfa_coroutine$(EXEEXT):
@@ -349 +342 @@
         @echo "java JavaThread" >> a.out
         @chmod a+x a.out
-
-creation-qthreads$(EXEEXT):
-        $(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
 
 ## =========================================================================================================

doc/bibliography/pl.bib

@@ -954 +954 @@
     key         = {Cforall Benchmarks},
     author      = {{\textsf{C}{$\mathbf{\forall}$} Benchmarks}},
-    howpublished= {\href{https://plg.uwaterloo.ca/~cforall/benchmarks}{https://\-plg.uwaterloo.ca/\-$\sim$cforall/\-benchmarks}},
+    howpublished= {\href{https://plg.uwaterloo.ca/~cforall/benchmark.tar}{https://\-plg.uwaterloo.ca/\-$\sim$cforall/\-benchmark.tar}},
 }
 

doc/papers/concurrency/Paper.tex

@@ -316 +316 @@
 Finally, 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.
 
-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}.
+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}.
 The 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.
-One solution is low-level qualifiers and functions (\eg, @volatile@ and atomics) allowing \emph{programmers} to explicitly write safe (race-free~\cite{Boehm12}) programs.
+One solution is low-level qualifiers and functions (\eg @volatile@ and atomics) allowing \emph{programmers} to explicitly write safe (race-free~\cite{Boehm12}) programs.
 A safer solution is high-level language constructs so the \emph{compiler} knows the optimization boundaries, and hence, provides implicit safety.
 This problem is best known with respect to concurrency, but applies to other complex control-flow, like exceptions\footnote{
@@ -324 +324 @@
 The 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++}
 } and coroutines.
-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.
+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.
 
 Finally, it is important for a language to provide safety over performance \emph{as the default}, allowing careful reduction of safety for performance when necessary.
-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.
+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.
 However, spurious wakeup is \emph{not} a foundational concurrency property~\cite[\S~8]{Buhr05a}, it is a performance design choice.
 Similarly, signals-as-hints are often a performance decision.
@@ -337 +337 @@
 Most 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.
 As a result, there is a significant learning curve to move to these languages, and C legacy-code must be rewritten.
-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.
+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.
 Hence, rewriting and retraining costs for these languages, even \CC, are prohibitive for companies with a large C software-base.
 \CFA with its orthogonal feature-set, its high-performance runtime, and direct access to all existing C libraries circumvents these problems.
@@ -367 +367 @@
 \section{Stateful Function}
 
-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.
+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.
 Hence, 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.
 This capability is accomplished by retaining a data/execution \emph{closure} between invocations.
-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.
-If 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.
+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.
+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.
 Hence, refactoring a stackless coroutine may require changing it to stackful.
-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.
+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.
 As well, activating a stateful function is \emph{asymmetric} or \emph{symmetric}, identified by resume/suspend (no cycles) and resume/resume (cycles).
 A fixed closure activated by modified call/return is faster than a variable closure activated by context switching.
-Additionally, any storage management for the closure (especially in unmanaged languages, \ie, no garbage collection) must also be factored into design and performance.
+Additionally, any storage management for the closure (especially in unmanaged languages, \ie no garbage collection) must also be factored into design and performance.
 Therefore, selecting between stackless and stackful semantics is a tradeoff between programming requirements and performance, where stackless is faster and stackful is more general.
 Note, creation cost is amortized across usage, so activation cost is usually the dominant factor.
@@ -648 +648 @@
 \end{center}
 The 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.
-The destructor provides a newline if formatted text ends with a full line.
+The destructor provides a newline, if formatted text ends with a full line.
 Figure~\ref{f:CFormatSim} shows the C implementation of the \CFA input generator with one additional field and the computed @goto@.
 For contrast, Figure~\ref{f:PythonFormatter} shows the equivalent Python format generator with the same properties as the Fibonacci generator.
@@ -2719 +2719 @@
 Each benchmark experiment is run 31 times.
 All omitted tests for other languages are functionally identical to the \CFA tests and available online~\cite{CforallBenchMarks}.
-
+% tar --exclude=.deps --exclude=Makefile --exclude=Makefile.in --exclude=c.c --exclude=cxx.cpp --exclude=fetch_add.c -cvhf benchmark.tar benchmark
 
 \paragraph{Object Creation}
@@ -2749 +2749 @@
 \multicolumn{1}{@{}c}{} & \multicolumn{1}{c}{Median} & \multicolumn{1}{c}{Average} & \multicolumn{1}{c@{}}{Std Dev} \\
 \CFA Coroutine Lazy             & 14.3          & 14.3          & 0.32          \\
-\CFA Coroutine Eager    & 2203.7        & 2205.6        & 26.03         \\
+\CFA Coroutine Eager    & 522.8         & 525.3         & 5.81          \\
 \CFA Thread                             & 1257.8        & 1291.2        & 86.19         \\
 \uC Coroutine                   & 92.2          & 91.4          & 1.58          \\