this is for holding javascript data
Daniele Cono D'Elia edited case-study.tex
over 8 years ago
Commit id: 0fff3fa88cf61d47ee81dfb34c60e230c8328d91
deletions | additions
diff --git a/case-study.tex b/case-study.tex
index b0ef95f..1679aca 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
given from by-hand
optimization. In particular, optimization; in the worst case
- {\tt odeRK4} benchmark - we observe a $94.1\%$ percentage when the optimized code is
JIT-compiled, generated on-the-fly, which becomes $97.5\%$ when a cached version is
available ({\tt odeRK4} benchmark). available. Compared to their OSR-based approach, the compensation entry block is a key driver of improved performance, as the benefits from a better type-specialized whole function body outweigh those from
simply performing a direct call using boxed arguments and return values in place of the original \feval.