this is for holding javascript data
Daniele Cono D'Elia edited case-study.tex
over 8 years ago
Commit id: 91239f2098b905f9d93161fd1ba41b4709a24c7c
deletions | additions
diff --git a/case-study.tex b/case-study.tex
index c2840ad..cdb9776 100644
--- a/case-study.tex
+++ b/case-study.tex
...
Unfortunately, we are unable to compute direct performance metrics for the solution by Lameed and Hendren since its source code has not been released. Numbers in their paper~\cite{lameed2013feval} show that for these benchmarks the speed-up of the OSR-based approach is equal on average to a $30.1\%$ percentage of the speed-up from hand-coded calls, ranging from $9.2\%$ to $73.9\%$; for the JIT-based approach the percentage grows to $84.7\%$, ranging from $75.7\%$ to $96.5\%$.
Our optimization technique yields speed-ups that are very close to the upper bound from by-hand optimization. In particular, in the worst case we observe a $94.1\%$ percentage when the optimized code is JIT-compiled, which becomes $97.5\%$ when a cached version is available ({\tt odeRK4} benchmark). Compared to their OSR-based approach,
more type-specialized code better type specialization enabled by the compensation entry block is
indeed the key driver
for better of improved performance.
We believe our approach can generate slightly better code than their JIT-based approach