为什么主机系统上的lua比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

$ 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

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 ./luagcc sumdata.lua data.log
Original Size: 117261680 kb
Compressed Size: 96727557 kb
real    0m3.090s
user    0m3.080s
sys 0m0.007s

gcc binary ~3.09 sec

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

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.

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

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

Answer 2

My guess is that the HFS+ journaling feature is adding latency. This would be easy enough to test: If TimeMachine is running on the Macbook Air, you could try disabling it, and disable journaling on the filesystem (obviously you should back up first). As root:

diskutil disableJournal YourDiskVolume

I'd see if that's the cause of the problem. Then i would immediately re-enable journaling.

diskutil enableJournal YourDiskVolume

OS X 10.9.2 had a journaling-related bug that would hang the filesystem... this page explores this bug further, and even though the bug (#15821723) hasn't been reported as fixed, journaling reportedly no longer crashes the disk controller.

Answer 3

to test the speed of lua, instead of reading a file hard-code some sample data into the test script and loop over the lines over and over as necessary. Like others mentioned, the filesystem effects are going to outweigh any compiler differences.