[LLVMdev] [cfe-dev] Very slow performance of lli on x86
Garrison Venn
gvenn.cfe.dev at gmail.com
Sun Nov 15 03:42:20 PST 2009
Granted I'm not up on using bit code files, but I don't believe the
debug build affects whether or not the jit is used (non-interpretive
mode). Ignoring other debug build effects on the efficiency of the
jitted code, it would be interesting if you also could measure the
time to jit--don't actually execute the 10000 iteration. I don't
believe this would explain the time scale shown, but it should have
some effect. To my mind, the proffered time scale also implies
interpretive mode which you might be able to force to see if this is
the culprit. I'll help test when you supply the build (make files).
Garrison
On Nov 15, 2009, at 2:55, Prasanth J wrote:
> Sorry i really forgot to mention one thing. I downloaded the X86
> binaries of llvm+clang and llvm-gcc from llvm download site. i hope
> that is not a debug build.
>
> Prasanth J
>
>
>
>
>
> On Sun, Nov 15, 2009 at 1:22 PM, Prasanth J <j.prasanth.j at gmail.com>
> wrote:
> Hi all,
>
> 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.
>
> 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.
>
> Thanks & Regards,
> Prasanth J
>
>
>
>
>
>
> On Sun, Nov 15, 2009 at 3:40 AM, Evan Cheng <evan.cheng at apple.com>
> wrote:
> He is probably using the interpreter on a debug build.
>
> Evan
>
>
> On Nov 14, 2009, at 1:40 PM, Eric Christopher <echristo at apple.com>
> wrote:
>
>
> for -O3 results refer attachment.
> time clang (-
> O0) llvm-gcc(-O0)
> gcc(-O0)
> real
> 0m10.247s
> 0m11.324s 0m10.963s
> user
> 0m2.644s
> 0m2.478s 0m2.263s
> sys
> 0m5.949s
> 0m6.000s 0m5.953s
>
> llvm-jit
> i used clang-cc -O0 -emit-llvm-bc to emit llvm bytecode and then
> passed it to opt tool and then linked all bytecode files to single
> bytecode using llvm-ld, i used lli tool to run this single bytecode
> file and noticed the following output
> real 6m33.786s
> user 5m12.612s
> sys 1m1.205s
>
> why is lli taking such a loooong time to execute this particular
> piece of code.??
>
> Something's wrong on your machine or something. I did the same (but
> using llvm-gcc for the .ll files). Using a debug build of current
> ToT I got this:
>
> [ghostwheel:~/Desktop] echristo% time ~/builds/build-llvm-64bit/
> Debug/bin/lli foo.bc.bc
> 0.210u 0.010s 0:00.22 100.0% 0+0k 0+0io 0pf+0w
>
>
> That's a 64-bit build, but you'll notice the time difference. That
> said I'm guessing that there's something missing since it takes no
> time to execute. Step by step directions on what you did might help.
>
> -eric
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091115/e528d0d1/attachment.html>
More information about the llvm-dev
mailing list