[Solved] Strange sluggishness of Lua in x86 TinyCore

[jazzbiker]

Greetings!

I'm currently at TC13 x86. For lua.tcz it appears:

Code: [Select]

tc@box:~$ time lua -e 'for i=1,1000000 do end'
real    0m 1.22s
user    0m 1.21s
sys     0m 0.00s
while using separately built lua 5.4.4 shows:

Code: [Select]

tc@box:~$ time /home/tc/lua/bin/lua  -e 'for i=1,1000000 do end'
real    0m 0.07s
user    0m 0.03s
sys     0m 0.00s
In TC13 x86_64 lua-5.3.tcz shows faster time for the same script (smth around 0.05s at CPU clocked with almost the same speed)

Current lua.tcz is inherited from TC12 x86 and works in the same way (slowly). In TC10 x86 lua.tcz is 5.3.5 and is slow too.

The most surprising is that I've built Lua on TC13 x86 following http://tinycorelinux.net/12.x/x86/tcz/src/lua/compile_lua recipe and it works normally (fast).

What's wrong with x86 lua.tcz?

Regards!

[patrikg]

Can it be compiled with out and with in thread support ??

SMP

[jazzbiker]

Can it be compiled with out and with in thread support ??

SMP

Lua is single-thread by design

[gadget42]

just for self-information(and general interest):
https://www.lua.org/about.html

[patrikg]

@gadget42

Thx for the link.
Don't know anything about lua. One only thing i know that some embedded systems uses lua.
I think about openwrt

But maybe there are some differences between the compilations.
Like using -o3 and maybe using clang... and maybe using more sophisticated options so gcc compile the code to use the simd instructions.

There are lots of things we don't see as (app) users/programmer, behind the curtain.
How our C, C++ code being compiled to asm instructions.
And how that asm instructions being treated in the processor, with cache alignment and so on.

[Rich]

Hi jazzbiker

... Current lua.tcz is inherited from TC12 x86 and works in the same way (slowly). In TC10 x86 lua.tcz is 5.3.5 and is slow too.

The most surprising is that I've built Lua on TC13 x86 following http://tinycorelinux.net/12.x/x86/tcz/src/lua/compile_lua recipe and it works normally (fast). ...

Run  ldd  on the slower versions of  lua:

Code: [Select]

tc@E310:~$ ldd /usr/local/bin/lua
        linux-gate.so.1 (0xb7f08000)
        libm.so.6 => /lib/libm.so.6 (0xb7e38000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7e33000)
        libreadline.so.7 => /usr/local/lib/libreadline.so.7 (0xb7df9000)
        libc.so.6 => /lib/libc.so.6 (0xb7ccc000)
        /lib/ld-linux.so.2 (0xb7f09000)
        libncursesw.so.6 => /usr/local/lib/libncursesw.so.6 (0xb7c87000)
tc@E310:~$
Then run  ldd  on the fast version you compiled:

Code: [Select]

ldd /home/tc/lua/bin/luaSee if your version shows any extra dependencies (liblua.so maybe?) that account for the speed increase.

[Rich]

Hi jazzbiker
I notice one other thing.
The compiler flags for http://tinycorelinux.net/12.x/x86/tcz/src/lua/compile_lua are:

Code: [Select]

CC= gcc -flto -march=i486 -mtune=i686 -Os -pipe -std=gnu99
The compiler flags for http://tinycorelinux.net/9.x/x86/tcz/src/lua/compile_lua (TC 10 version) are:

Code: [Select]

CC= gcc -mtune=generic -Os -pipe -std=gnu99
CFLAGS= -fPIC -Wall -Wextra -DLUA_COMPAT_5_2 -DLUA_COMPAT_5_1 $(SYSCFLAGS) $(MYCFLAGS)I suspect the lack of a  -march=i486  might mean it defaulted to the processor of the compiling machine.

I think  -mtune=generic  tries to avoid code that would be slow on some AMD CPUs and avoid other
code that would be slow on some Intel CPUs, producing code that is not optimized for any CPU.

The  DLUA_COMPAT_5  variables allow for backward compatibility with older versions which may or may not
impact performance.

Or maybe the compiler version you used generated faster code.

[jazzbiker]

Hi Rich,

ldd was the first to check and dependencies are the same. It was not surprise because lua binary is linked with liblua.a:

Code: [Select]

gcc -flto -march=i486 -mtune=i686 -Os -pipe  -std=gnu99 -o lua   lua.o liblua.a -lm -Wl,-E -ldl -lreadline -lncursesw

Fast incarnation of lua-5.3.6 in TC13 x86 was compiled literally following recipe, using the same -march=i486 and -mtune=i686.

But!!!

I've made the thing I was to do before - compiled the same lua source using the same recipe, but under TC12 x86. And this lua binary is slowpoke! The only difference is gcc version.
I've compiled lua extensions for my needs in TC13 x86 using -no-unwind-tables and -fno-asynchronous-unwind-tables as You proposed earlier for pure C code, binary sizes decreased significantly.

Should we dig further? It may be useful, but I have no ideas in what direction. It may be useful for another extensions packing too.

Thanks!

[jazzbiker]

But maybe there are some differences between the compilations.
Like using -o3 and maybe using clang... and maybe using more sophisticated options so gcc compile the code to use the simd instructions.

There are lots of things we don't see as (app) users/programmer, behind the curtain.
How our C, C++ code being compiled to asm instructions.
And how that asm instructions being treated in the processor, with cache alignment and so on.

Well, well, well... See previous post

[Rich]

Hi jazzbiker

... The only difference is gcc version. ...

And older versions of dependencies.

... I've made the thing I was to do before - compiled the same lua source using the same recipe, but under TC12 x86. And this lua binary is slowpoke! ...

If you copy that to TC13 does it run faster?

[jazzbiker]

And older versions of dependencies.

But the only non-system dependence is readline and it undoubtedly is not engaged in the test chunk execution - empty cycle.

I've compiled vanilla lua-5.3.6 in TC12 x86 without any patches and editing - simply

Code: [Select]

make linux
and the result is the same slow.

[jazzbiker]

I've built lua-5.3.6 in TC12 x86 with tcc. The changes made in src/Makefile:

Code: [Select]

CC= tcc -std=gnu99
linux:
        $(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX" SYSLIBS="-ldl -lreadline"

And

Code: [Select]

tc@box:/tmp/lua-5.3.6/src$ time ./lua -e 'for i=1,1000000 do end'
real    0m 0.12s
user    0m 0.11s
sys     0m 0.00s

tcc produced the fast code )

[jazzbiker]

Looks like something in Lua sources makes gcc 10 and earlier insane, while gcc 11 keeps conscious )

[jazzbiker]

TC12 x86 lua-5.3.6 gcc, no optimization.
src/Makefile

Code: [Select]

CFLAGS= -Wall -Wextra -DLUA_COMPAT_5_2 $(SYSCFLAGS) $(MYCFLAGS)

 Testing:

Code: [Select]

tc@box:/tmp/lua-5.3.6/src$ time ./lua -e 'for i=1,1000000 do end'
real    0m 0.12s
user    0m 0.11s
sys     0m 0.00s
fast, still slower than gcc 11 in TC13 x86 with -Os.

[jazzbiker]

TC12 x86 gcc 10.2 lua-5.3.6

tcc

Code: [Select]

tc@box:/tmp/lua-5.3.6/src$ ls -l liblua.a lua luac
-rw-r--r--    1 tc       staff       359332 Sep 16 22:00 liblua.a
-rwxr-xr-x    1 tc       staff       243008 Sep 16 22:00 lua
-rwxr-xr-x    1 tc       staff       170488 Sep 16 22:00 luac
tc@box:/tmp/lua-5.3.6/src$ time ./lua -e 'for i=1,1000000 do end'
real    0m 0.14s
user    0m 0.13s
sys     0m 0.00s

gcc 10 no optimizations

Code: [Select]

tc@box:/tmp/lua-5.3.6/src$ ls -l liblua.a lua luac
-rw-r--r--    1 tc       staff       342388 Sep 16 22:03 liblua.a
-rwxr-xr-x    1 tc       staff       270888 Sep 16 22:03 lua
-rwxr-xr-x    1 tc       staff       186408 Sep 16 22:03 luac
tc@box:/tmp/lua-5.3.6/src$ time ./lua -e 'for i=1,1000000 do end'
real    0m 0.12s
user    0m 0.11s
sys     0m 0.00s

gcc 10 -O2

Code: [Select]

tc@box:/tmp/lua-5.3.6/src$ ls -l liblua.a lua luac
-rw-r--r--    1 tc       staff       359420 Sep 16 22:06 liblua.a
-rwxr-xr-x    1 tc       staff       284032 Sep 16 22:06 lua
-rwxr-xr-x    1 tc       staff       181220 Sep 16 22:06 luac
tc@box:/tmp/lua-5.3.6/src$ time ./lua -e 'for i=1,1000000 do end'
real    0m 1.20s
user    0m 1.19s
sys     0m 0.00s

gcc 10 -Os

Code: [Select]

tc@box:/tmp/lua-5.3.6/src$ ls -l liblua.a lua luac
-rw-r--r--    1 tc       staff       269664 Sep 16 22:09 liblua.a
-rwxr-xr-x    1 tc       staff       200160 Sep 16 22:09 lua
-rwxr-xr-x    1 tc       staff       129348 Sep 16 22:09 luac
tc@box:/tmp/lua-5.3.6/src$ time ./lua -e 'for i=1,1000000 do end'
real    0m 1.20s
user    0m 1.20s
sys     0m 0.00s