this is for holding javascript data
Daniele Cono D'Elia edited experim.tex
over 8 years ago
Commit id: 6e5bbd674ca32a87e878c58143e7d3085799958b
deletions | additions
diff --git a/experim.tex b/experim.tex
index 908db8f..6fd49cf 100644
--- a/experim.tex
+++ b/experim.tex
...
For {\tt b-trees} - the only benchmark in our suite showing a recursive pattern - we insert an OSR point in the body of the method that accounts for the largest {\em self} execution time of the program. Such an OSR point might be useful to trigger recompilation of the code at a higher degree of optimization, or to enable some form of dynamic optimization (for instance, in a recursive search algorithm we might want to inline the comparator method provided by the user at the call).
Results for the unoptimized and optimized versions of the benchmarks are reported in
Figure\ref{fig:code-quality-base} Figure~\ref{fig:code-quality-base} and \ref{fig:code-quality-O1}, respectively.
For both scenarios we observe that the overhead is very small, i.e. less than $1\%$ for most benchmarks and less than $2\%$ in the worst case. In some cases, code might run slightly faster after OSR point have been inserted due to cache and instruction alignment effects. We analyzed the code produced by the x86_64 back-end: the OSR machinery is lowered into three native instructions that load a counter in a register, compare it against a constant value and jump to the OSR block accordingly. The number of times the OSR condition is checked in each benchmark is identical to those reported for the experiments in Table~\ref{tab:sameFun}
\paragraph{Overhead of OSR transitions}