Suppose you are writing a high-performance system program (network stack / hypervisor / database / unikernel / etc) and you want to write that in Lua with RaptorJIT or LuaJIT instead of C. You think this will make the development quicker and more pleasant but you are concerned about the performance. How will it work out in practice?
I have good news, bad news, and more good news for you.
The good news is that once you get the hang of how tracing JIT works then 95% of your code will perform perfectly fine. This is true even for performance sensitive inner loops where you are counting CPU cycles. Getting this performance will take some work, for example you will need to select algorithms and datastructures that minimize unpredictable branches, but you will be able to do it.
The bad news is that occasionally you will have a subroutine that can't be implemented efficiently in Lua. It might need to use special CPU instructions for SIMD or AES or CRC. It might have wild and crazy control flow that can't be tamed. Or it might just be a couple of lines of code that screw up the trace compiler by inserting a loop or unpredictable branch in otherwise optimal branch-free inner-loop code. These cases are fairly rare and a large program might only have one or two of them, if any. But when they come up you do have to deal with them.
The other good news is that you can easily write those troublesome routines in C or assembler and call them from Lua. The FFI makes calling C/asm code just as efficient as if you were programming in C. You can insert FFI calls into even your most optimized inner loops without disturbing the trace compiler. This means you always have a suitable Plan B for handling difficult cases without disturbing the rest of your program: you just write a few isolated lines of C or assembler and then get back to your Lua hacking.
Suppose you are writing a high-performance system program (network stack / hypervisor / database / unikernel / etc) and you want to write that in Lua with RaptorJIT or LuaJIT instead of C. You think this will make the development quicker and more pleasant but you are concerned about the performance. How will it work out in practice?
I have good news, bad news, and more good news for you.
The good news is that once you get the hang of how tracing JIT works then 95% of your code will perform perfectly fine. This is true even for performance sensitive inner loops where you are counting CPU cycles. Getting this performance will take some work, for example you will need to select algorithms and datastructures that minimize unpredictable branches, but you will be able to do it.
The bad news is that occasionally you will have a subroutine that can't be implemented efficiently in Lua. It might need to use special CPU instructions for SIMD or AES or CRC. It might have wild and crazy control flow that can't be tamed. Or it might just be a couple of lines of code that screw up the trace compiler by inserting a loop or unpredictable branch in otherwise optimal branch-free inner-loop code. These cases are fairly rare and a large program might only have one or two of them, if any. But when they come up you do have to deal with them.
The other good news is that you can easily write those troublesome routines in C or assembler and call them from Lua. The FFI makes calling C/asm code just as efficient as if you were programming in C. You can insert FFI calls into even your most optimized inner loops without disturbing the trace compiler. This means you always have a suitable Plan B for handling difficult cases without disturbing the rest of your program: you just write a few isolated lines of C or assembler and then get back to your Lua hacking.