Re: Squeezing more performance from the Lua interpreter

[Dibyendu Majumdar <mobile@...>]

On Fri, 21 Aug 2020 at 17:11, Eduardo Bart <edub4rt@gmail.com> wrote:
>
> Thanks for the tip!
>
> Seems like I got another ~4% improvement with those flags! (although I've enabled globally)
> What are they doing in the interpreter? Better jumping when executing the lua instructions?

I wouldn't enable globally as it disables some optimizations -
specially global common subexpression - which is likely bad for the
code.
The only code that needs these options is the VM which uses computed
goto - I think in 5.4 this is enabled for gcc.
If you see the generated assembly output - without these flags the
code may not be using computed goto at all.

>
> Custom allocator also benefits me on Linux, the results I've shown were all on linux.
> I've managed to bundle my Lua interpreter with this allocator https://github.com/mjansson/rpmalloc
> Seems to work fine and it's much more simple to use (a single C file) and performs the same as mimalloc,
> and much faster than my system's standard malloc.
> I think it could be even faster if the thread safety was removed from that allocator.
> All good allocators in C that I find out there are thread safe and I don't see much need in the Lua case.
>
> I've also experimented porting the LuaJIT's allocator to Lua 5.4 (was quite easy to do),
> and it performed worse than mimalloc or rpmalloc for my use case.

You can use dlmalloc - which was used by LuaJIT (with some mods).
I use it in Ravi.
It has an arena mode (ONLY_MSPACES ) - and you can disable all locking
too. So that makes it suited for Lua as a single threaded allocator.
I used this instead of the LuaJIT version as it is well documented and
just drop-in.

Regards