Why is lua on host system slower than in the linux vm?

Question

Comparing executing time of this Lua Script on a Macbook Air (Mac OS 10.9.4, i5-4250U (1.3GHz), 8GB RAM) to a VM (virtualbox) running Arch Linux.

Compiling Lua 5.2.3 in a Arch Linux virtualbox

First I've compiled lua by myself using clang, to compare it with the Mac OS X clang binary.

using tcc, gcc and clang

$ tcc *[^ca].c lgc.c lfunc.c lua.c -lm -o luatcc
$ gcc -O3 *[^ca].c lgc.c lfunc.c lua.c -lm -o luagcc
/tmp/ccxAEYH8.o: In function `os_tmpname':
loslib.c:(.text+0x29c): warning: the use of `tmpnam' is dangerous, better use `mkstemp'
$ clang -O3 *[^ca].c lgc.c lfunc.c lua.c -lm -o luaclang
/tmp/loslib-bd4ef4.o:loslib.c:function os_tmpname: warning: the use of `tmpnam' is dangerous, better use `mkstemp'

clang version in VM

$ clang --version
clang version 3.4.2 (tags/RELEASE_34/dot2-final)
Target: x86_64-unknown-linux-gnu
Thread model: posix

compare the file size

$ ls -lh |grep lua
-rwxr-xr-x 1 markus markus 210K 20. Aug 18:21 luaclang
-rwxr-xr-x 1 markus markus 251K 20. Aug 18:22 luagcc
-rwxr-xr-x 1 markus markus 287K 20. Aug 18:22 luatcc

VM benchmarking

clang binary ~3.1 sec

$ time ./luaclang sumdata.lua data.log
Original Size: 117261680 kb
Compressed Size: 96727557 kb
real    0m3.124s
user    0m3.100s
sys  0m0.020s

gcc binary ~3.09 sec

$ time ./luagcc sumdata.lua data.log
Original Size: 117261680 kb
Compressed Size: 96727557 kb
real    0m3.090s
user    0m3.080s
sys 0m0.007s

tcc binary ~7.0 sec - no surprise here :)

$ time ./luatcc sumdata.lua data.log
Original Size: 117261680 kb
Compressed Size: 96727557 kb
real    0m7.071s
user    0m7.053s
sys 0m0.010s

Compiling on Mac OS X

Now compiling lua with the same clang command/options like in the VM.

$ clang -O3 *[^ca].c lgc.c lfunc.c lua.c -lm -o luaclangmac
loslib.c:108:3: warning: 'tmpnam' is deprecated: This function is provided for
compatibility reasons only. Due to security concerns inherent in the design of tmpnam(3),
it is highly recommended that you use mkstemp(3)
instead. [-Wdeprecated-declarations]
lua_tmpnam(buff, err);
^
loslib.c:57:33: note: expanded from macro 'lua_tmpnam'
#define lua_tmpnam(b,e) { e = (tmpnam(b) == NULL); }
^
/usr/include/stdio.h:274:7: note: 'tmpnam' declared here
char *tmpnam(char *);
^
1 warning generated.

clang version Mac OS X

I've tried two version. 3.4.2 and the one which is provided by xcode. The version 3.4.2 is a bit slower.

Markuss-MacBook-Air:bin markus$ ./clang --version
clang version 3.4.2 (tags/RELEASE_34/dot2-rc1)
Target: x86_64-apple-darwin13.3.0
Thread model: posix
Markuss-MacBook-Air:bin markus$ clang --version
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.3.0
Thread model: posix

file size

$ ls -lh|grep lua
-rwxr-xr-x 1 markus staff 194K 20 Aug 18:26 luaclangmac

HOST benchmarking

clang binary ~4.3 sec

$ time ./luaclangmac sumdata.lua data.log
Original Size: 117261680 kb
Compressed Size: 96727557 kb
real    0m4.338s
user    0m4.264s
sys 0m0.062s

Why?

I would have expected that the host system is a little faster than the virtualization (or roughly the same speed). But not that the host system is reproducible slower.

So, any ideas or explanations?

Update 2014.10.30

Meanwhile I've installed Arch Linux nativly on my MBA. The benchmarks are as fast as in the Arch Linux VM.

Answer 1

Can you try to run 'perf stat' instead of 'time'. It provides you much more details and the time measurement is more correct, avoiding timing differences inside the VM.

Here is an example:

$ perf stat ls > /dev/null

Performance counter stats for 'ls':

     23.348076      task-clock (msec)         #    0.989 CPUs utilized          
             2      context-switches          #    0.086 K/sec                  
             0      cpu-migrations            #    0.000 K/sec                  
            93      page-faults               #    0.004 M/sec                  
    74,628,308      cycles                    #    3.196 GHz                     [65.75%]
       740,755      stalled-cycles-frontend   #    0.99% frontend cycles idle    [48.66%]
    29,200,738      stalled-cycles-backend    #   39.13% backend  cycles idle    [60.02%]
    80,592,001      instructions              #    1.08  insns per cycle        
                                              #    0.36  stalled cycles per insn
    17,746,633      branches                  #  760.090 M/sec                   [60.00%]
       642,360      branch-misses             #    3.62% of all branches         [48.64%]

   0.023609439 seconds time elapsed