[LLVMdev] asmwriting times (was Re: LLVMContext: Suggestions for API Changes)

[Albert Graef]

Albert Graef wrote:
> One thing I noticed is that writing LLVM assembler code (print()
> methods) seems to be horribly slow now (some 4-5 times slower than in
> LLVM 2.5). This is a real bummer for me, since Pure's batch compiler
> uses those methods to produce output code which then gets fed into llvmc.

Let me follow up with some concrete figures. Unfortunately, I don't have
a minimal C++ example, but the effect is easy to reproduce with Pure
0.31 from http://pure-lang.googlecode.com/ and the attached little Pure
script. (I'm quite sure that this is not a bug in the Pure interpreter,
as exactly the same code runs more than a magnitude faster with LLVM 2.5
than with LLVM 2.6/2.7svn.)

The given figures are user CPU times in seconds, as given by time(1), so
they are not really that accurate, but the effect is so prominent that
this really doesn't matter. (See below for the details on how I obtained
these figures.)

                LLVM 2.5        LLVM 2.6        LLVM 2.7(svn)

execute         1.752s          2.272s          2.256s
compile         2.316s          24.458s         24.834s

codegen         0.564s          22.186s         22.578s
(compile ./. execute)

To measure the asmwriting times, I first ran the script without
generating LLVM assembler output code ("execute", pure -x hello.pure)
and then again with LLVM assembler output enabled ("compile", pure -o
hello.ll -c -x hello.pure). The difference between the two figures
("codegen") gives a rough estimate of the net asmwriting times. (That's
really all that pure -c does; at the end of script execution it takes
the IR that's already in memory and just spits it out by iterating over
the global variables and the functions of the IR module and using the
appropriate print() methods.)

The resulting LLVM assembler file hello.ll was some 5.3 MB for LLVM
2.6/2.7svn (4.4 MB for LLVM 2.5; the assembler programs are exactly the
same, though, the size differences are apparently due to formatting
changes in LLVM 2.6/2.7svn). Note that the code size is quite large
because the function definitions compiled from Pure's prelude are all
included.

The tests were performed on an AMD Phenom 9950 4x2.6GHz with 4GB RAM
running Linux x86-64 2.6.27. The following configure options were used
to compile LLVM (all versions) and Pure 0.31, respectively:

LLVM: --enable-optimized --disable-assertions --disable-expensive-checks
--enable-targets=host-only --enable-pic

Pure: --enable-release

So the effect is actually much *more* prominent than I first made it out
to be. This is just one data point, of course, but I get an easily
noticable slowdown with every Pure script I tried. In fact it's so much
slower that I consider it unusable.

I'm at a loss here. I'd have to debug the LLVM asmwriter code to see
where exactly the bottleneck is. I haven't done that yet, but I ruled
out an issue with the raw_ostream buffer sizes by trying different sizes
from 256 bytes up to 64K; it doesn't change the results very much.

So my question to fellow frontend developers is: Has anyone else seen
this? Does anyone know a workaround?

Any help will be greatly appreciated.

TIA,
Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de
WWW:    http://www.musikinformatik.uni-mainz.de/ag
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: hello.pure
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090824/7f34f61f/attachment.ksh>