3 ms·

Not sure if a portable jit-constructed interpreter can reach the performance of the hand-written assembly interpreter of LuaJIT. My assumption is that what make

Not sure if a portable jit-constructed interpreter can reach the performance of the hand-written assembly interpreter of LuaJIT. My assumption is that what makes LuaJIT fast is careful consideration of architecture specific details. Maybe you've seen this already: http://nominolo.blogspot.co.uk/2012/07/implementing-fast-interpreters.html http://nominolo.blogspot.co.uk/2012/07/implementing-fast-int... (notice the part about portability)

gsnedders 10y ago
> Not sure if a portable jit-constructed interpreter can reach the performance of the hand-written assembly interpreter of LuaJIT. My assumption is that what makes LuaJIT fast is careful consideration of architecture specific details. > Maybe you've seen this already: http://nominolo.blogspot.co.uk/2012/07/implementing-fast-interpreters.html http://nominolo.blogspot.co.uk/2012/07/implementing-fast-int... (notice the part about portability) My assumption would be that architecture specific details contribute relatively little towards the performance of LuaJIT outside of register constrained architectures (x86-32, most obviously). Mike's comment on Reddit years ago about the performance of LuaJIT's interpreter seems to be consistent with that: https://www.reddit.com/r/programming/comments/badl2/luajit_2_beta_3_is_out_support_both_x32_x64/c0lrus0?st=iq43mp4g&sh=6b15e555 https://www.reddit.com/r/programming/comments/badl2/luajit_2.... We're now reaching a point where x86-32 performance isn't such a consideration any more (simply because it's an increasingly rare architecture), so you can just bound your number of virtual registers to the lower-bound of the architectures you care more about (so therefore you maintain 1:1 mapping on all those you care much about). As that post says in its bit about portability (LLInt is JavaScriptCore's interpreter, mentioned in my post above, for those unaware), most of these portable assembly implementations have means to drop down and hand-write architecture specific code for the cases where it makes much difference, and in general you can do smart enough instruction selection it won't make much difference. Some of the big gains come from having control over stack layout (as you don't need to separately maintain an interpreter stack separate to the thread's), which accounted for a lot of the overhead in JavaScriptCore's old interpreter, and which LLInt deliberately uses the same stack layout as the JITs do, hence allowing on-stack replacement (OSR) between the interpreter and JIT. This is something that Ignition is aiming to do, and it's something that LuaJIT does.
- saynsedit 10y ago
  Thanks for replying, I agree with this.

gsnedders 10y ago

> Not sure if a portable jit-constructed interpreter can reach the performance of the hand-written assembly interpreter of LuaJIT. My assumption is that what makes LuaJIT fast is careful consideration of architecture specific details. > Maybe you've seen this already: http://nominolo.blogspot.co.uk/2012/07/implementing-fast-interpreters.html http://nominolo.blogspot.co.uk/2012/07/implementing-fast-int... (notice the part about portability) My assumption would be that architecture specific details contribute relatively little towards the performance of LuaJIT outside of register constrained architectures (x86-32, most obviously). Mike's comment on Reddit years ago about the performance of LuaJIT's interpreter seems to be consistent with that: https://www.reddit.com/r/programming/comments/badl2/luajit_2_beta_3_is_out_support_both_x32_x64/c0lrus0?st=iq43mp4g&sh=6b15e555 https://www.reddit.com/r/programming/comments/badl2/luajit_2.... We're now reaching a point where x86-32 performance isn't such a consideration any more (simply because it's an increasingly rare architecture), so you can just bound your number of virtual registers to the lower-bound of the architectures you care more about (so therefore you maintain 1:1 mapping on all those you care much about). As that post says in its bit about portability (LLInt is JavaScriptCore's interpreter, mentioned in my post above, for those unaware), most of these portable assembly implementations have means to drop down and hand-write architecture specific code for the cases where it makes much difference, and in general you can do smart enough instruction selection it won't make much difference. Some of the big gains come from having control over stack layout (as you don't need to separately maintain an interpreter stack separate to the thread's), which accounted for a lot of the overhead in JavaScriptCore's old interpreter, and which LLInt deliberately uses the same stack layout as the JITs do, hence allowing on-stack replacement (OSR) between the interpreter and JIT. This is something that Ignition is aiming to do, and it's something that LuaJIT does.

saynsedit 10y ago
Thanks for replying, I agree with this.