lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Mon, Jun 25, 2018 at 10:20 PM, Russell Haley <> wrote:

On Mon, Jun 25, 2018 at 1:47 PM, Russell Haley <> wrote:

On Mon, Jun 25, 2018 at 12:35 PM, dyngeccetor8 <> wrote:
On 06/25/2018 09:00 AM, Russell Haley wrote:
> Raw numbers on Windows 10 - Third Gen i7 laptop
> Lua 5.3:
> Lua 5.4:
> 5.4 seems a smidgen faster.
> Night,
> Russ

It's strange that on your machine there is no difference.

Idea was to exploit new garbage collector. More specifically,
it's performance in registering new objects. Which gives
two-fold performance drop on my machine. It looks like
on your machine new collector works just same (or disabled
in both cases). I have no ideas to explain this.

I have 16 GB ram on the computer.  Could that explain anything? I'll try it again on FreeBSD if my "Attention Deficit Disorder" doesn't distract me tonight (I get about 1.5 - 2 hours at night, it's hard to stay focused on anything).  I see there is possible DTrace support for Lua via this er.. add in.. That would be a fun little project as I've been looking for a reason to do some more DTrace scripting.

My results are invalid. I was using the following command line from powershell:

Measure-Command {lua.exe C:\temp\gc_benchmark.lua}

which  was actually calling C:\Program Files\WinLua\Lua\5.3\bin\lua.exe. All I was actually doing was comparing 5.3 32 bit to 5.3 64 bit. oops!

When run *correctly* Lua 5.3 uses about 14 MB of memory (times still similar to last night). 5.4 eats a GB of memory on Windows 10 before it's killed with a 'not enough memory' error:

C:\Users\russh\lua\lua-5.4.0-work2\src> lua.exe C:\temp\gc_benchmark.lua
Lua 5.3
C:\Users\russh\lua\lua-5.4.0-work2\src> .\lua.exe C:\temp\gc_benchmark.lua
Lua 5.4
C:\Users\russh\lua\lua-5.4.0-work2\src\lua.exe: not enough memory

On FreeBSD the results are much much different. BOTH lua53 (installed via binary from pkg) and lua 5.4 (run from the 5.4 src directory to be sure) eat all the memory of my virtual machine and then chew up my swap and kill the entire VM. How cool is that? I'm going to try it on my FreeBSD server with 24 GB of ram! tee hee...


The results on FreeBSD are more in line with your original results.

I reported the final memory usage, but it doesn't really tell much of a story. When watching the memory climb in 'top' the 5.4 interpreter memory usage seemed to rise more slowly in more measured increments. I noticed in 5.3 that it will allocate big chunks (300 or more MB) of memory at a time, but also de-allocate big chunks at a time (I saw the system free over 1 GB of memory once, but often ~400 MB). 


-- Martin