Shawn Fox wrote:
> On Mon, Jun 24, 2013 at 5:33 AM, Mike Pall <mike-1306@xxxxxxxxxx>
wrote:
> > Alas, the FFI is quite slow when only interpreted.
>
> Mike, do you intend to improve interpreted FFI performance at some
point?
Mike Pall <mike-1306@xxxxxxxxxx> wrote:
Maybe. But I don't know how. :-|
Apologies if this has been discussed before (or is otherwise crazy
and/or impractical),
but how hard would it be to save* aside %08the results of running with
the JIT during a
"representative" execution example and persist it into a binary that
could be linked
with the app?
At runtime, the JIT would run in a mode where it'd use those
pre-compiled segments
whenever they matched up (including for FFI code) but not try to create
new ones
and fall back to interpreted mode for everything else.
Presuming a good enough representative sample, you'd get the speed in
the places
that matter and the misses wouldn't be worse off than with the JIT
disabled except for
any overhead involved in watching for opportunities to use the
pre-compiled bits.
Again though, not having written a JIT myself I might be missing an
obvious reason
why such a scheme wouldn't work well.
DT
* This might not be quite accurate since the "sample" might be run on
x86 in the
simulator instead of ARM, so "save" might include cross compiling.
