Index: doc/theses/andrew_beach_MMath/performance.tex =================================================================== --- doc/theses/andrew_beach_MMath/performance.tex (revision 3548ddb251fc74192149b70dec9f8c2c4338b334) +++ doc/theses/andrew_beach_MMath/performance.tex (revision f93d7fc7d039f77b2be3d58e385d38f6a309824c) @@ -21,6 +21,6 @@ but otherwise \Cpp should have a significant advantage. -Java, a popular language with similar termination semantics, but -it is implemented in a very different environment, a virtual machine with +Java, a popular language with similar termination semantics, +is implemented in a very different environment, a virtual machine with garbage collection. It also implements the finally clause on try blocks allowing for a direct @@ -45,5 +45,4 @@ The number of times the loop is run is configurable from the command line; the number used in the timing runs is given with the results per test. -% Tests ran their main loop a million times. The Java tests run the main loop 1000 times before beginning the actual test to ``warm-up" the JVM. @@ -140,5 +139,5 @@ The repeating function calls itself inside a try block with a handler that does not match the raised exception, but is of the same kind of handler. -This means that the EHM has to check each handler, but continue +This means that the EHM has to check each handler, and continue over all of them until it reaches the base of the stack. Comparing this to the empty test gives the time to traverse over and @@ -147,7 +146,8 @@ \paragraph{Cross Try Statement} -This group of tests measures the cost for setting up exception handling, if it is +This group of tests measures the cost for setting up exception handling, +if it is not used (because the exceptional case did not occur). -Tests repeatedly cross (enter, execute, and leave) a try statement but never +Tests repeatedly cross (enter, execute and leave) a try statement but never perform a raise. \begin{itemize}[nosep] @@ -301,6 +301,5 @@ \multicolumn{1}{c}{Raise} & \multicolumn{1}{c}{\CFA} & \multicolumn{1}{c}{\Cpp} & \multicolumn{1}{c}{Java} & \multicolumn{1}{c|}{Python} \\ \hline -Resume Empty (10M) & 3.8 & 3.5 & 14.7 & 2.3 & 176.1 & 0.3 & 0.1 & 8.9 & 1.2 & 119.9 \\ -%Resume Other (10M) & 4.0* & 0.1* & 21.9 & 6.2 & 381.0 & 0.3* & 0.1* & 13.2 & 5.0 & 290.7 \\ +Resume Empty (10M) & 1.5 & 1.5 & 14.7 & 2.3 & 176.1 & 1.0 & 1.4 & 8.9 & 1.2 & 119.9 \\ \hline \end{tabular} @@ -313,4 +312,5 @@ For example, there are a few cases where Python out-performs \CFA, \Cpp and Java. +\todo{Make sure there are still cases where Python wins.} The most likely explanation is that, since exceptions are rarely considered to be the common case, the more optimized languages @@ -328,5 +328,5 @@ Details on the different test cases follow. -\subsection{Termination, \autoref{t:PerformanceTermination}} +\subsection{Termination \texorpdfstring{(\autoref{t:PerformanceTermination})}{}} \begin{description} @@ -334,11 +334,13 @@ \CFA is slower than \Cpp, but is still faster than the other languages and closer to \Cpp than other languages. -This result is to be expected as \CFA is closer to \Cpp than the other languages. +This result is to be expected, +as \CFA is closer to \Cpp than the other languages. \item[D'tor Traversal] Running destructors causes a huge slowdown in the two languages that support them. \CFA has a higher proportionate slowdown but it is similar to \Cpp's. -Considering the amount of work done in destructors is virtually zero (asm instruction), the cost -must come from the change of context required to trigger the destructor. +Considering the amount of work done in destructors is effectively zero +(an assembly comment), the cost +must come from the change of context required to run the destructor. \item[Finally Traversal] @@ -360,5 +362,4 @@ but they could avoid the spike by not having the same kind of overhead for switching to the check's context. - \todo{Could revisit Other Traversal, after Finally Traversal.} @@ -366,5 +367,5 @@ Here \CFA falls behind \Cpp by a much more significant margin. This is likely due to the fact \CFA has to insert two extra function -calls, while \Cpp does not have to execute any other instructions. +calls, while \Cpp does not have to do execute any other instructions. Python is much further behind. @@ -391,5 +392,5 @@ \end{description} -\subsection{Resumption, \autoref{t:PerformanceResumption}} +\subsection{Resumption \texorpdfstring{(\autoref{t:PerformanceResumption})}{}} Moving on to resumption, there is one general note, @@ -413,12 +414,10 @@ The run-time is actually very similar to Finally Traversal. As resumption does not unwind the stack, both destructors and finally -clauses are run while walking down the stack during the recursion returns. +clauses are run while walking down the stack during the recursive returns. So it follows their performance is similar. \item[Finally Traversal] -% The increase in run-time from Empty Traversal (once adjusted for -% the number of iterations) is roughly the same as for termination. -% This suggests that the -See D'tor Traversal discussion. +Same as D'tor Traversal, +except termination did not have a spike in run-time on this test case. \item[Other Traversal] @@ -431,8 +430,7 @@ The only test case where resumption could not keep up with termination, although the difference is not as significant as many other cases. -It is simply a matter of where the costs come from. \PAB{What does this mean? -Even if \CFA termination -is not ``zero-cost", passing through an empty function still seems to be -cheaper than updating global values.} +It is simply a matter of where the costs come from, +both termination and resumption have some work to set-up or tear-down a +handler. It just so happens that resumption's work is slightly slower. \item[Conditional Match] @@ -443,5 +441,5 @@ \end{description} -\subsection{Resumption/Fixup, \autoref{t:PerformanceFixupRoutines}} +\subsection{Resumption/Fixup \texorpdfstring{(\autoref{t:PerformanceFixupRoutines})}{}} Finally are the results of the resumption/fixup routine comparison. @@ -449,8 +447,11 @@ has more to do with performance than passing the argument through layers of calls. -Even with 100 stack frames though, resumption is only about as fast as -manually passing a fixup routine. -However, as the number of fixup routines is increased, the cost of passing them -should make the resumption dynamic-search cheaper. -So there is a cost for the additional power and flexibility exceptions -provide. +At 100 stack frames, resumption and manual fixup routines have similar +performance in \CFA. +More experiments could try to tease out the exact trade-offs, +but the prototype's only performance goal is to be reasonable. +It has already in that range, and \CFA's fixup routine simulation is +one of the faster simulations as well. +Plus exceptions add features and remove syntactic overhead, +so even at similar performance resumptions have advantages +over fixup routines.