[LLVMdev] Very slow performance of lli on x86
Óscar Fuentes
ofv at wanadoo.es
Sun Nov 15 02:05:45 PST 2009
Prasanth J <j.prasanth.j at gmail.com>
writes:
> LLVM is built without debug enabled. Also i am not forcing lli to use
> interpreter mode. so i dont think the reason is not because of debug build
> or interpreter mode.
>
>
> *step 1: *
> compiled the 3 files (generic_replica.c ,xacc.c and dacc.c) with clang-cc to
> llvm bytecode files using -emit-llvm-bc and (-O0/-O3) options
> *step 2:*
> bytecode obtained from step 1 (generic_replica.bc, xacc.bc and dacc.bc) is
> passed to opt tool using (-O0/-O3) options
> *step 3:*
> optimized bytecode obtained from step 2 (generic_replica.opt.bc, xacc.opt.bc
> and dacc.opt.c) is combinde to a single bytecode file (monolith.bc) using
> llvm-ld tool
> *step 4: *
> running monolith.bc for 10000 iterations using lli tool and measured the
> time.
So if I understand you correctly, you build executables with
llvm-gcc and clang, and ran it 10000 times taking about 10 seconds. Then
you generate some .bc files, combine and optimized them, and invoke
lli 10000 times with the resulting .bc file.
lli needs to generate the native code from the .bc file each time you
invoke it, so it is not a fair comparision, unless you are testing lli's
native code generation speed.
So if your program executes fast (<1 ms) when compiled with llvm-gcc
but have a moderately large (a few KB) .bc file, that could explain why
lli seems slow.
If the .bc file is short then, for some unknown reason, lli may be using
the interpreter instead of generating and running native code.
Which operative system do you use? How long is the .bc file you pass to
lli? What's the output of running your .bc file passing the command line
option -stats to lli? Is there any difference if you pass to lli the
-force-interpreter option too?
> I also tried using llvm-gcc for emiting bytecode in step 1 but got almost
> the same output. As i have my entire setup in office i cant attach my
> makefile today. i will attach my entire setup tom once i get back to office.
> Also i will attach the configuration options i used for compiling LLVM. Let
> me know in case i am wrong anywhere.
--
Óscar
More information about the llvm-dev
mailing list