Re: [ANN] llvm-lua 1.0
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: [ANN] llvm-lua 1.0
- From: "Robert G. Jakabosky" <bobby@...>
- Date: Tue, 2 Jun 2009 18:31:53 -0700
On Tuesday 02, Javier Guerra wrote:
> 2009年6月2日 李慧霸 <magazine.lihuiba@163.com>:
> > I think a major difference of llvm-lua for the lua community
> > is performance. So is there a performance comparison? I didn't
> > find it on the project's web site.
>
> i think that even if LuaJIT beat llvm-lua, it would have a very
> important role because of its portability. it can do either JIT or
> statically compile to ARM, that could be a godsend for many embedded
> projects.
LuaJIT is still faster then llvm-lua. llvm-lua is about 2-3x faster then
normal Lua for some work loads, LuaJIT is about 2-3x faster then llvm-lua for
some work loads. Both LuaJIT & llvm-lua are very fast with numeric for
loops.
The main reason to use llvm-lua over LuaJIT is for the static compiling
feature (can be used for code obfuscation) and support for more architectures
then just x86.
One of the main reasons LuaJIT is faster is that llvm-lua doesn't compile Lua
functions when they are called, llvm-lua does AOT (Ahead-of-Time) compiling
of the Lua functions right after they are compiled to Lua bytecode. This
means llvm-lua can't do any runtime analysis to help with optimizing the
generated LLVM IR code. The reason llvm-lua only does AOT compiling, is that
LLVM's JIT needs a lot of C-Stack space and that would cause all coroutines
to need atleast 512Kbytes of COCO stack space instead of just 65Kbytes. I
could just allocate one large stack to be used for JIT compiling and just
switch to that stack before running the Lua->LLVM IR->JIT compiler. But I
haven't taken the time to do that, since I only really need static & AOT
compiling of Lua code.
LuaJIT is able to inline calls to math.* and some other standard library
functions because it JITs Lua functions when they are called, which allows it
to see what functions are going being called by that Lua code.
One way llvm-lua could improve the speed of static compiled code would be to
add support for recording hints during runtime and writting those hints to a
file that would then be passed to the static compiler.
Below are the results of running scimark-2008年01月22日.lua [1] for a performance
comparison.
Summary (larger is faster):
normal lua: 9.77
llvm-lua: 22.09
static compile: 21.94
LuaJIT -O3: 39.60
# taskset -c 1 /usr/bin/lua scimark-2008年01月22日.lua large
Lua SciMark 2008年01月22日, based on SciMark 2.0a. Copyright (C) 2008 Mike Pall.
FFT 5.58 [1048576]
SOR 15.97 [1000]
MC 3.99
SPARSE 11.27 [100000, 1000000]
LU 12.06 [1000]
SciMark 9.77 [large problem sizes]
# taskset -c 1 llvm-lua scimark-2008年01月22日.lua large
Lua SciMark 2008年01月22日, based on SciMark 2.0a. Copyright (C) 2008 Mike Pall.
FFT 11.64 [1048576]
SOR 38.32 [1000]
MC 8.43
SPARSE 24.52 [100000, 1000000]
LU 27.51 [1000]
SciMark 22.09 [large problem sizes]
# taskset -c 1 ./scimark-2008年01月22日 large
Lua SciMark 2008年01月22日, based on SciMark 2.0a. Copyright (C) 2008 Mike Pall.
FFT 12.09 [1048576]
SOR 38.48 [1000]
MC 9.29
SPARSE 23.27 [100000, 1000000]
LU 26.57 [1000]
SciMark 21.94 [large problem sizes]
# taskset -c 1 luajit -O3 scimark-2008年01月22日.lua large
Lua SciMark 2008年01月22日, based on SciMark 2.0a. Copyright (C) 2008 Mike Pall.
FFT 17.62 [1048576]
SOR 69.18 [1000]
MC 22.00
SPARSE 37.87 [100000, 1000000]
LU 51.32 [1000]
SciMark 39.60 [large problem sizes]
1. http://luajit.org/download/scimark-2008年01月22日.lua
--
Robert G. Jakabosky