Changeset 262deda


Ignore:
Timestamp:
Aug 19, 2021, 1:59:53 PM (9 months ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
enum, forall-pointer-decay, jacob/cs343-translation, master
Children:
fe8aa21
Parents:
f79ee0d
Message:

proofread performance chapter and add local bibliography entry

Location:
doc/theses/andrew_beach_MMath
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • doc/theses/andrew_beach_MMath/performance.tex

    rf79ee0d r262deda  
    33
    44Performance is of secondary importance for most of this project.
    5 Instead, the focus is to get the features working. The only performance
     5Instead, the focus was to get the features working. The only performance
    66requirement is to ensure the tests for correctness run in a reasonable
    7 amount of time.
     7amount of time. Hence, a few basic performance tests were performed to
     8check this requirement.
    89
    910\section{Test Set-Up}
     
    1415C++ is the most comparable language because both it and \CFA use the same
    1516framework, libunwind.
    16 In fact, the comparison is almost entirely a quality of implementation
    17 comparison: \CFA's EHM has had significantly less time to be optimized and
     17In fact, the comparison is almost entirely a quality of implementation.
     18Specifically, \CFA's EHM has had significantly less time to be optimized and
    1819does not generate its own assembly. It does have a slight advantage in that
    1920there are some features it handles directly instead of through utility functions,
    20 but otherwise \Cpp has a significant advantage.
    21 
    22 Java is another very popular language with similar termination semantics.
    23 It is implemented in a very different environment, a virtual machine with
     21but otherwise \Cpp should have a significant advantage.
     22
     23Java is a popular language with similar termination semantics, but
     24it is implemented in a very different environment, a virtual machine with
    2425garbage collection.
    2526It also implements the @finally@ clause on @try@ blocks allowing for a direct
    2627feature-to-feature comparison.
    27 As with \Cpp, Java's implementation is mature, optimizations
     28As with \Cpp, Java's implementation is mature, optimized
    2829and has extra features.
    2930
    30 Python is used as an alternative point of comparison because of the \CFA EHM's
     31Python is used as an alternative comparison because of the \CFA EHM's
    3132current performance goals, which is not to be prohibitively slow while the
    3233features are designed and examined. Python has similar performance goals for
     
    3637resumption exceptions. Even the older programming languages with resumption
    3738seem to be notable only for having resumption.
    38 So instead, resumption is compared to a less similar but much more familiar
    39 feature, termination exceptions.
     39So instead, resumption is compared to its simulation in other programming
     40languages using fixup functions that are explicitly passed for correction or
     41logging purposes.
     42% So instead, resumption is compared to a less similar but much more familiar
     43%feature, termination exceptions.
    4044
    4145All tests are run inside a main loop that repeatedly performs a test.
    4246This approach avoids start-up or tear-down time from
    4347affecting the timing results.
    44 Each test is run a million times.
    45 The Java versions of the test run this loop an extra 1000 times before
    46 beginning to actual test to ``warm-up" the JVM.
     48Each test is run a N times (configurable from the command line).
     49The Java tests runs the main loop 1000 times before
     50beginning the actual test to ``warm-up" the JVM.
    4751
    4852Timing is done internally, with time measured immediately before and
     
    6670
    6771The tests are compiled with gcc-10 for \CFA and g++-10 for \Cpp. Java is
    68 compiled with 11.0.11. Python with 3.8. The tests were run on:
     72compiled with version 11.0.11. Python with version 3.8. The tests were run on:
    6973\begin{itemize}[nosep]
    7074\item
     
    7377AMD 6380 Abu Dhabi 16-core 4$\times$socket \lstinline{@} 2.5 GHz running Linux v5.11.0-25
    7478\end{itemize}
     79Two kinds of hardware architecture allows discriminating any implementation and
     80architectural effects.
     81
    7582
    7683% We don't use catch-alls but if we did:
     
    8491
    8592\paragraph{Raise and Handle}
    86 The first group measures the cost of a try statement when exceptions are raised
    87 and \emph{the stack is unwound}.  Each test has has a repeating function like
    88 the following
    89 \begin{cfa}
     93This group measures the cost of a try statement when exceptions are raised and
     94the stack is unwound (termination) or not unwound (resumption).  Each test has
     95has a repeating function like the following
     96\begin{lstlisting}[language=CFA,{moredelim=**[is][\color{red}]{@}{@}}]
    9097void unwind_empty(unsigned int frames) {
    9198        if (frames) {
    92                 unwind_empty(frames - 1);
     99                @unwind_empty(frames - 1);@ // AUGMENTED IN OTHER EXPERIMENTS
    93100        } else throw (empty_exception){&empty_vt};
    94101}
    95 \end{cfa}
    96 which is called M times, where each call recurses to a depth of N, an
     102\end{lstlisting}
     103which is called N times, where each call recurses to a depth of R (configurable from the command line), an
    97104exception is raised, the stack is a unwound, and the exception caught.
    98105\begin{itemize}[nosep]
    99106\item Empty:
    100 This test measures the cost of raising (stack walking) an exception through empty
    101 empty stack frames to an empty handler. (see above)
     107For termination, this test measures the cost of raising (stack walking) an
     108exception through empty stack frames from the bottom of the recursion to an
     109empty handler, and unwinding the stack. (see above code)
     110
     111\medskip
     112For resumption, this test measures the same raising cost but does not unwind
     113the stack. For languages without resumption, a fixup function is to the bottom
     114of the recursion and called to simulate a fixup operation at that point.
     115\begin{cfa}
     116void nounwind_fixup(unsigned int frames, void (*raised_rtn)(int &)) {
     117        if (frames) {
     118                nounwind_fixup(frames - 1, raised_rtn);
     119        } else {
     120                int fixup = 17;
     121                raised_rtn(fixup);
     122        }
     123}
     124\end{cfa}
     125where the passed fixup function is:
     126\begin{cfa}
     127void raised(int & fixup) {
     128        fixup = 42;
     129}
     130\end{cfa}
     131For comparison, a \CFA version passing a function is also included.
    102132\item Destructor:
    103 
    104 This test measures the cost of raising an exception through non-empty frames
    105 where each frame has an object requiring destruction, to an empty
    106 handler. Hence, there are N destructor calls during unwinding.
    107 \begin{cfa}
    108 if (frames) {
     133This test measures the cost of raising an exception through non-empty frames,
     134where each frame has an object requiring destruction, from the bottom of the
     135recursion to an empty handler. Hence, there are N destructor calls during
     136unwinding.
     137
     138\medskip
     139This test is not meaningful for resumption because the stack is only unwound as
     140the recursion returns.
     141\begin{cfa}
    109142        WithDestructor object;
    110         unwind_empty(frames - 1);
     143        unwind_destructor(frames - 1);
    111144\end{cfa}
    112145\item Finally:
    113146This test measures the cost of establishing a try block with an empty finally
    114 clause on the front side of the recursion and running the empty finally clause
    115 on the back side of the recursion during stack unwinding.
    116 \begin{cfa}
    117 if (frames) {
     147clause on the front side of the recursion and running the empty finally clauses
     148during stack unwinding from the bottom of the recursion to an empty handler.
     149\begin{cfa}
    118150        try {
    119151                unwind_finally(frames - 1);
    120152        } finally {}
    121153\end{cfa}
     154
     155\medskip
     156This test is not meaningful for resumption because the stack is only unwound as
     157the recursion returns.
    122158\item Other Handler:
    123 This test is like the finally test but the try block has a catch clause for an
    124 exception that is not raised, so catch matching is executed during stack
    125 unwinding but the match never successes until the catch at the bottom of the
    126 stack.
    127 \begin{cfa}
    128 if (frames) {
     159For termination, this test is like the finally test but the try block has a
     160catch clause for an exception that is not raised, so catch matching is executed
     161during stack unwinding but the match never successes until the catch at the
     162bottom of the recursion.
     163\begin{cfa}
    129164        try {
    130165                unwind_other(frames - 1);
    131166        } catch (not_raised_exception *) {}
    132167\end{cfa}
     168
     169\medskip
     170For resumption, this test measures the same raising cost but does not unwind
     171the stack. For languages without resumption, the same fixup function is passed
     172and called.
    133173\end{itemize}
    134174
    135 \paragraph{Cross Try Statement}
    136 The next group measures just the cost of executing a try statement so
     175\paragraph{Try/Handle/Finally Statement}
     176This group measures just the cost of executing a try statement so
    137177\emph{there is no stack unwinding}.  Hence, the program main loops N times
    138178around:
     
    143183\begin{itemize}[nosep]
    144184\item Handler:
    145 The try statement has a handler.
     185The try statement has a handler (catch/resume).
    146186\item Finally:
    147 The try statement replaces the handler with a finally clause.
     187The try statement has a finally clause.
    148188\end{itemize}
    149189
    150190\paragraph{Conditional Matching}
    151 This final group measures the cost of conditional matching.
     191This group measures the cost of conditional matching.
    152192Only \CFA implements the language level conditional match,
    153 the other languages must mimic with an ``unconditional" match (it still
    154 checks the exception's type) and conditional re-raise if it was not supposed
     193the other languages mimic with an ``unconditional" match (it still
     194checks the exception's type) and conditional re-raise if it is not suppose
    155195to handle that exception.
    156196\begin{center}
     
    180220The condition is always false. (Never matches or always re-raises.)
    181221\end{itemize}
     222
     223\medskip
     224\noindent
     225All omitted test code for other languages is functionally identical to the \CFA
     226tests or simulated, and available online~\cite{CforallExceptionBenchmarks}.
    182227
    183228%\section{Cost in Size}
     
    192237
    193238\section{Results}
    194 In cases where a feature is not supported by a language the test is skipped
    195 for that language.
    196 \PAB{Report all values.
    197 
    198 Similarly, if a test does not change between resumption
    199 and termination in \CFA, then only one test is written and the result
    200 was put into the termination column.
    201 }
     239One result not directly related to \CFA but important to keep in
     240mind is that, for exceptions, the standard intuition about which languages
     241should go faster often does not hold. For example, there are a few cases where Python out-performs
     242\CFA, \Cpp and Java. The most likely explanation is that, since exceptions are
     243rarely considered to be the common case, the more optimized languages
     244make that case expense. In addition, languages with high-level
     245representations have a much easier time scanning the stack as there is less
     246to decode.
     247
     248Tables~\ref{t:PerformanceTermination} and~\ref{t:PerformanceResumption} show
     249the test results for termination and resumption, respectively.  In cases where
     250a feature is not supported by a language, the test is skipped for that language
     251(marked N/A).  For some Java experiments it was impossible to measure certain
     252effects because the JIT corrupted the test (marked N/C). No workaround was
     253possible~\cite{Dice21}.  To get experiments in the range of 1--100 seconds, the
     254number of times an experiment is run (N) is varied (N is marked beside each
     255experiment, e.g., 1M $\Rightarrow$ 1 million test iterations).
     256
     257An anomaly exists with gcc nested functions used as thunks for implementing
     258much of the \CFA EHM. If a nested-function closure captures local variables in
     259its lexical scope, performance dropped by a factor of 10.  Specifically, in try
     260statements of the form:
     261\begin{cfa}
     262        try {
     263                unwind_other(frames - 1);
     264        } catch (not_raised_exception *) {}
     265\end{cfa}
     266the try block is hoisted into a nested function and the variable @frames@ is
     267the local parameter to the recursive function, which triggers the anomaly. The
     268workaround is to remove the recursion parameter and make it a global variable
     269that is explicitly decremented outside of the try block (marked with a ``*''):
     270\begin{cfa}
     271        frames -= 1;
     272        try {
     273                unwind_other();
     274        } catch (not_raised_exception *) {}
     275\end{cfa}
     276To make comparisons fair, a dummy parameter is added and the dummy value passed
     277in the recursion. Note, nested functions in gcc are rarely used (if not
     278completely unknown) and must follow the C calling convention, unlike \Cpp
     279lambdas, so it is not surprising if there are performance issues efficiently
     280capturing closures.
     281
     282% Similarly, if a test does not change between resumption
     283% and termination in \CFA, then only one test is written and the result
     284% was put into the termination column.
    202285
    203286% Raw Data:
     
    235318% Match None    & 0.0 & 0.0 &  9476060146 & 0.0 & 0.0 \\
    236319
    237 \begin{tabular}{|l|c c c c c|}
    238 \hline
    239               & \CFA (Terminate) & \CFA (Resume) & \Cpp & Java & Python \\
    240 \hline
    241 Raise Empty   & 0.0 & 0.0 & 0.0 & 0.0 & 0.0 \\
    242 Raise D'tor   & 0.0 & 0.0 & 0.0 & N/A & N/A \\
    243 Raise Finally & 0.0 & 0.0 & N/A & 0.0 & 0.0 \\
    244 Raise Other   & 0.0 & 0.0 & 0.0 & 0.0 & 0.0 \\
    245 Cross Handler & 0.0 & 0.0 & 0.0 & 0.0 & 0.0 \\
    246 Cross Finally & 0.0 & N/A & N/A & 0.0 & 0.0 \\
    247 Match All     & 0.0 & 0.0 & 0.0 & 0.0 & 0.0 \\
    248 Match None    & 0.0 & 0.0 & 0.0 & 0.0 & 0.0 \\
    249 \hline
    250 \end{tabular}
    251 
    252320% run-plg7a-a.sat
    253321% ---------------
     
    284352% Match None    & 0.0 & 0.0 &  7829059869 & 0.0 & 0.0 \\
    285353
    286 % PLG7A (in seconds)
    287 \begin{tabular}{|l|c c c c c|}
     354\begin{table}
     355\centering
     356\caption{Performance Results Termination (sec)}
     357\label{t:PerformanceTermination}
     358\begin{tabular}{|r|*{2}{|r r r r|}}
    288359\hline
    289               & \CFA (Terminate) & \CFA (Resume) & \Cpp & Java & Python \\
    290 \hline
    291 Raise Empty   & 0.0 & 0.0 & 0.0 & 0.0 & 0.0 \\
    292 Raise D'tor   & 0.0 & 0.0 & 0.0 & N/A & N/A \\
    293 Raise Finally & 0.0 & 0.0 & N/A & 0.0 & 0.0 \\
    294 Raise Other   & 0.0 & 0.0 & 0.0 & 0.0 & 0.0 \\
    295 Cross Handler & 0.0 & 0.0 & 0.0 & 0.0 & 0.0 \\
    296 Cross Finally & 0.0 & N/A & N/A & 0.0 & 0.0 \\
    297 Match All     & 0.0 & 0.0 & 0.0 & 0.0 & 0.0 \\
    298 Match None    & 0.0 & 0.0 & 0.0 & 0.0 & 0.0 \\
     360                        & \multicolumn{4}{c||}{AMD}             & \multicolumn{4}{c|}{ARM}      \\
     361\cline{2-9}
     362N\hspace{8pt}           & \multicolumn{1}{c}{\CFA} & \multicolumn{1}{c}{\Cpp} & \multicolumn{1}{c}{Java} & \multicolumn{1}{c||}{Python} &
     363                          \multicolumn{1}{c}{\CFA} & \multicolumn{1}{c}{\Cpp} & \multicolumn{1}{c}{Java} & \multicolumn{1}{c|}{Python} \\
     364\hline                                                                             
     365Throw Empty (1M)        & 3.4   & 2.8   & 18.3  & 23.4          & 3.7   & 3.2   & 15.5  & 14.8  \\
     366Throw D'tor (1M)        & 48.4  & 23.6  & N/A   & N/A           & 64.2  & 29.0  & N/A   & N/A   \\
     367Throw Finally (1M)      & 3.4*  & N/A   & 17.9  & 29.0          & 4.1*  & N/A   & 15.6  & 19.0  \\
     368Throw Other (1M)        & 3.6*  & 23.2  & 18.2  & 32.7          & 4.0*  & 24.5  & 15.5  & 21.4  \\
     369Try/Catch (100M)        & 6.0   & 0.9   & N/C   & 37.4          & 10.0  & 0.8   & N/C   & 32.2  \\
     370Try/Finally (100M)      & 0.9   & N/A   & N/C   & 44.1          & 0.8   & N/A   & N/C   & 37.3  \\
     371Match All (10M)         & 32.9  & 20.7  & 13.4  & 4.9           & 36.2  & 24.5  & 12.0  & 3.1   \\
     372Match None (10M)        & 32.7  & 50.3  & 11.0  & 5.1           & 36.3  & 71.9  & 12.3  & 4.2   \\
    299373\hline
    300374\end{tabular}
    301 
    302 One result not directly related to \CFA but important to keep in
    303 mind is that, for exceptions, the standard intuition about which languages
    304 should go faster often does not hold. For example, there are cases where Python out-performs
    305 \Cpp and Java. The most likely explanation is that, since exceptions are
    306 rarely considered to be the common case, the more optimized languages
    307 make that case expense. In addition, languages with high-level
    308 representations have a much easier time scanning the stack as there is less
    309 to decode.
    310 
    311 This observation means that while \CFA does not actually keep up with Python in every
    312 case, it is usually no worse than roughly half the speed of \Cpp. This performance is good
    313 enough for the prototyping purposes of the project.
     375\end{table}
     376
     377\begin{table}
     378\centering
     379\small
     380\caption{Performance Results Resumption (sec)}
     381\label{t:PerformanceResumption}
     382\setlength{\tabcolsep}{5pt}
     383\begin{tabular}{|r|*{2}{|r r r r|}}
     384\hline
     385                        & \multicolumn{4}{c||}{AMD}             & \multicolumn{4}{c|}{ARM}      \\
     386\cline{2-9}
     387N\hspace{8pt}           & \multicolumn{1}{c}{\CFA (R/F)} & \multicolumn{1}{c}{\Cpp} & \multicolumn{1}{c}{Java} & \multicolumn{1}{c||}{Python} &
     388                          \multicolumn{1}{c}{\CFA (R/F)} & \multicolumn{1}{c}{\Cpp} & \multicolumn{1}{c}{Java} & \multicolumn{1}{c|}{Python} \\
     389\hline                                                                             
     390Resume Empty (10M)      & 3.8/3.5       & 14.7  & 2.3   & 176.1 & 0.3/0.1       & 8.9   & 1.2   & 119.9 \\
     391Resume Other (10M)      & 4.0*/0.1*     & 21.9  & 6.2   & 381.0 & 0.3*/0.1*     & 13.2  & 5.0   & 290.7 \\
     392Try/Resume (100M)       & 8.8           & N/A   & N/A   & N/A   & 12.3          & N/A   & N/A   & N/A   \\
     393Match All (10M)         & 0.3           & N/A   & N/A   & N/A   & 0.3           & N/A   & N/A   & N/A   \\
     394Match None (10M)        & 0.3           & N/A   & N/A   & N/A   & 0.4           & N/A   & N/A   & N/A   \\
     395\hline
     396\end{tabular}
     397\end{table}
     398
     399As stated, the performance tests are not attempting to compare exception
     400handling across languages.  The only performance requirement is to ensure the
     401\CFA EHM implementation runs in a reasonable amount of time, given its
     402constraints. In general, the \CFA implement did very well. Each of the tests is
     403analysed.
     404\begin{description}
     405\item[Throw/Resume Empty]
     406For termination, \CFA is close to \Cpp, where other languages have a higher cost.
     407
     408For resumption, \CFA is better than the fixup simulations in the other languages, except Java.
     409The \CFA results on the ARM computer for both resumption and function simulation are particularly low;
     410I have no explanation for this anomaly, except the optimizer has managed to remove part of the experiment.
     411Python has a high cost for passing the lambda during the recursion.
     412
     413\item[Throw D'tor]
     414For termination, \CFA is twice the cost of \Cpp.
     415The higher cost for \CFA must be related to how destructors are handled.
     416
     417\item[Throw Finally]
     418\CFA is better than the other languages with a @finally@ clause, which is the
     419same for termination and resumption.
     420
     421\item[Throw/Resume Other]
     422For termination, \CFA is better than the other languages.
     423
     424For resumption, \CFA is equal to or better the other languages.
     425Again, the \CFA results on the ARM computer for both resumption and function simulation are particularly low.
     426Python has a high cost for passing the lambda during the recursion.
     427
     428\item[Try/Catch/Resume]
     429For termination, installing a try statement is more expressive than \Cpp
     430because the try components are hoisted into local functions.  At runtime, these
     431functions are than passed to libunwind functions to set up the try statement.
     432\Cpp zero-cost try-entry accounts for its performance advantage.
     433
     434For resumption, there are similar costs to termination to set up the try
     435statement but libunwind is not used.
     436
     437\item[Try/Finally]
     438Setting up a try finally is less expensive in \CFA than setting up handlers,
     439and is significantly less than other languages.
     440
     441\item[Throw/Resume Match All]
     442For termination, \CFA is close to the other language simulations.
     443
     444For resumption, the stack unwinding is much faster because it does not use
     445libunwind.  Instead resumption is just traversing a linked list with each node
     446being the next stack frame with the try block.
     447
     448\item[Throw/Resume Match None]
     449The same results as for Match All.
     450\end{description}
     451
     452\begin{comment}
     453This observation means that while \CFA does not actually keep up with Python in
     454every case, it is usually no worse than roughly half the speed of \Cpp. This
     455performance is good enough for the prototyping purposes of the project.
    314456
    315457The test case where \CFA falls short is Raise Other, the case where the
    316458stack is unwound including a bunch of non-matching handlers.
    317459This slowdown seems to come from missing optimizations.
    318 
    319 Importantly, there is a huge slowdown in \Cpp's results bringing that brings
    320 \CFA's performance back in that roughly half speed area. However many other
    321 \CFA benchmarks increase their run-time by a similar amount falling far
    322 behind their \Cpp counter-parts.
    323460
    324461This suggests that the performance issue in Raise Other is just an
     
    364501The difference in relative performance does show that there are savings to
    365502be made by performing the check without catching the exception.
     503\end{comment}
     504
     505
     506\begin{comment}
     507From: Dave Dice <dave.dice@oracle.com>
     508To: "Peter A. Buhr" <pabuhr@uwaterloo.ca>
     509Subject: Re: [External] : JIT
     510Date: Mon, 16 Aug 2021 01:21:56 +0000
     511
     512> On 2021-8-15, at 7:14 PM, Peter A. Buhr <pabuhr@uwaterloo.ca> wrote:
     513>
     514> My student is trying to measure the cost of installing a try block with a
     515> finally clause in Java.
     516>
     517> We tried the random trick (see below). But if the try block is comment out, the
     518> results are the same. So the program measures the calls to the random number
     519> generator and there is no cost for installing the try block.
     520>
     521> Maybe there is no cost for a try block with an empty finally, i.e., the try is
     522> optimized away from the get-go.
     523
     524There's quite a bit of optimization magic behind the HotSpot curtains for
     525try-finally.  (I sound like the proverbial broken record (:>)).
     526
     527In many cases we can determine that the try block can't throw any exceptions,
     528so we can elide all try-finally plumbing.  In other cases, we can convert the
     529try-finally to normal if-then control flow, in the case where the exception is
     530thrown into the same method.  This makes exceptions _almost cost-free.  If we
     531actually need to "physically" rip down stacks, then things get expensive,
     532impacting both the throw cost, and inhibiting other useful optimizations at the
     533catch point.  Such "true" throws are not just expensive, they're _very
     534expensive.  The extremely aggressive inlining used by the JIT helps, because we
     535can convert cases where a heavy rip-down would normally needed back into simple
     536control flow.
     537
     538Other quirks involve the thrown exception object.  If it's never accessed then
     539we're apply a nice set of optimizations to avoid its construction.  If it's
     540accessed but never escapes the catch frame (common) then we can also cheat.
     541And if we find we're hitting lots of heavy rip-down cases, the JIT will
     542consider recompilation - better inlining -- to see if we can merge the throw
     543and catch into the same physical frame, and shift to simple branches.
     544
     545In your example below, System.out.print() can throw, I believe.  (I could be
     546wrong, but most IO can throw).  Native calls that throw will "unwind" normally
     547in C++ code until they hit the boundary where they reenter java emitted code,
     548at which point the JIT-ed code checks for a potential pending exception.  So in
     549a sense the throw point is implicitly after the call to the native method, so
     550we can usually make those cases efficient.
     551
     552Also, when we're running in the interpreter and warming up, we'll notice that
     553the == 42 case never occurs, and so when we start to JIT the code, we elide the
     554call to System.out.print(), replacing it (and anything else which appears in
     555that if x == 42 block) with a bit of code we call an "uncommon trap".  I'm
     556presuming we encounter 42 rarely.  So if we ever hit the x == 42 case, control
     557hits the trap, which triggers synchronous recompilation of the method, this
     558time with the call to System.out.print() and, because of that, we now to adapt
     559the new code to handle any traps thrown by print().  This is tricky stuff, as
     560we may need to rebuild stack frames to reflect the newly emitted method.  And
     561we have to construct a weird bit of "thunk" code that allows us to fall back
     562directly into the newly emitted "if" block.  So there's a large one-time cost
     563when we bump into the uncommon trap and recompile, and subsequent execution
     564might get slightly slower as the exception could actually be generated, whereas
     565before we hit the trap, we knew the exception could never be raised.
     566
     567Oh, and things also get expensive if we need to actually fill in the stack
     568trace associated with the exception object.  Walking stacks is hellish.
     569
     570Quite a bit of effort was put into all this as some of the specjvm benchmarks
     571showed significant benefit.
     572
     573It's hard to get sensible measurements as the JIT is working against you at
     574every turn.  What's good for the normal user is awful for anybody trying to
     575benchmark.  Also, all the magic results in fairly noisy and less reproducible
     576results.
     577
     578Regards
     579Dave
     580
     581p.s., I think I've mentioned this before, but throwing in C++ is grim as
     582unrelated throws in different threads take common locks, so nothing scales as
     583you might expect.
     584\end{comment}
  • doc/theses/andrew_beach_MMath/uw-ethesis.bib

    rf79ee0d r262deda  
    22% For use with BibTeX
    33
    4 @book{goossens.book,
    5         author =        "Michel Goossens and Frank Mittelbach and
    6                          Alexander Samarin",
    7         title =         "The \LaTeX\ Companion",
    8         year =          "1994",
    9         publisher =     "Addison-Wesley",
    10         address =       "Reading, Massachusetts"
     4@misc{Dice21,
     5    author      = {Dave Dice},
     6    year        = 2021,
     7    month       = aug,
     8    howpublished= {personal communication}
    119}
    1210
    13 @book{knuth.book,
    14         author =        "Donald Knuth",
    15         title =         "The \TeX book",
    16         year =          "1986",
    17         publisher =     "Addison-Wesley",
    18         address =       "Reading, Massachusetts"
     11@misc{CforallExceptionBenchmarks,
     12    contributer = {pabuhr@plg},
     13    key         = {Cforall Exception Benchmarks},
     14    author      = {{\textsf{C}{$\mathbf{\forall}$} Exception Benchmarks}},
     15    howpublished= {\href{https://github.com/cforall/ExceptionBenchmarks_SPE20}{https://\-github.com/\-cforall/\-ExceptionBenchmarks\_SPE20}},
    1916}
    20 
    21 @book{lamport.book,
    22         author =        "Leslie Lamport",
    23         title =         "\LaTeX\ --- A Document Preparation System",
    24         edition =       "Second",
    25         year =          "1994",
    26         publisher =     "Addison-Wesley",
    27         address =       "Reading, Massachusetts"
    28 }
Note: See TracChangeset for help on using the changeset viewer.