RE: LuaJit FFI with iOS
- From: William Adams <william_a_adams@xxxxxxx>
- To: "luajit@xxxxxxxxxxxxx" <luajit@xxxxxxxxxxxxx>
- Date: Tue, 25 Jun 2013 15:02:24 +0000
===============================
- Shaping clay is easier than digging it out of the ground.
I wonder if it would just be better to use Lua as a front end to LLVM and call
it a day for such cases...
----------------------------------------
> From: dtull@xxxxxxxxx
> To: luajit@xxxxxxxxxxxxx
> Date: Tue, 25 Jun 2013 06:59:37 -0700
> Subject: RE: LuaJit FFI with iOS
>
> 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 the 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.
>
Other related posts:
