this is for holding javascript data
Camil Demetrescu
over 8 years ago
Commit id : b2db9d61ae18ae6c5fc9ba05ee151b4c81165eba
deletions | additions
diff --git a/artifact/session2.tex b/artifact/session2.tex
index b97d4bc..2956abb 100644
--- a/artifact/session2.tex
+++ b/artifact/session2.tex
...
\noindent Note that the second line inserts a never-firing open OSR point at instruction labeled with {\tt 8} (actually {\tt
:8}) in function {\tt bench} of file {\tt shootout/n-body/bench.ll}, using branch weight of 5\% as a hint for the LLVM native code generation back-end that OSR firing is very unlikely.
The experiment duration was $\approx1$m with a time per trial: trial of $\approx5.673$s. The ratio $5.673/5.725=0.990$ for {\tt n-body} is slightly smaller than the one reported in \ref{fig:code-quality-base} on the Intel Xeon. The experiment for building \ref{fig:code-quality-O1} uses scripts in {\tt bench-O1} and {\tt codeQuality-O1}.
\paragraph{Question Q2.} This experiment assesses the run-time overhead of an OSR transition by measuring the duration of an always-firing OSR execution and of a never-firing OSR execution, and reporting the difference averaged over the number of fired OSRs. The always-firing OSR execution for {\tt n-body} (unoptimized) is as follows:
\begin{small}