[LLVMdev] Status of use-diet so far (NO API CHANGES)

[heisenbug]

On Apr 25, 8:52 pm, Dan Gohman <goh... at apple.com> wrote:
> On Apr 24, 2008, at 9:03 AM, Gabor Greif wrote:
>
>
>
> > As you can see, the use-diet changes actually lower the build time
> > of kimwitu++! (this is as of yesterday's r50182).
> > Parity is not only reached, but surpassed.
>
> Thanks for these numbers. Do you know how much of this increase is due
> to
> co-allocating Use arrays with their users, and how much is due to the
> actual shrinking of the size of Use?

Hi Dan!

I cannot give you the results of extensive research, but some strong
indication.

I ran opt without optimization passes on the raw linked bitcode of
sqlite3, with and without my patches:

ggreif$ time ~/llvm/Release/binDiet/opt -disable-opt
sqlite3.linked.rbc -o sqlite3.linked.bc -f

real    0m0.556s
user    0m0.515s
sys     0m0.037s

ggreif$ time ~/llvm/Release/binReg/opt -disable-opt sqlite3.linked.rbc
-o sqlite3.linked.bc -f

real    0m0.564s
user    0m0.521s
sys     0m0.041s

There is a significant speedup for my patch:
expr 515000 / 521
988

For real times:
expr 556000 / 564
985

This is 1.5% speedup. Of course this already contains the size changes
from 16->12 bytes, so we may have the extra effect (less bytes
allocated) factored in.

When running standard optmizations, there is a 5% slowdown on this
test, which I have chosen because it is the most extreme example. The
majority of the opt runs get a 2% penalty. Use::getUser() seems to
claim 1.8% of the samples in sqlite3 under shark with -std-compile-
opts.

When not restricting ourselves to opt, but simply building the sqlite3
application, the times become much more reasonable:

grep "^real" < sqlite3Diet.scatter.backup2 | sort
real    1m35.643s
real    1m35.924s
real    1m35.941s
real    1m36.033s
real    1m36.140s
real    1m36.151s
real    1m36.198s
real    1m36.249s
real    1m36.309s
real    1m36.489s

grep "^real" < sqlite3Regular.scatter.backup2 | sort
real    1m35.417s
real    1m35.459s
real    1m35.497s
real    1m35.593s
real    1m35.632s
real    1m35.694s
real    1m35.703s
real    1m35.928s
real    1m35.986s
real    1m36.057s

expr 96489000 / 96057
1004

0.4% when looking at the 10th values.

I explain this with  the fact that opt only runs once (paying the
penalty), but
the other llvm-tools all reap benefits.

On a side-note kimwitu++ spent 1.2% of its shark samples in getUser,
accordingly the opt penalty is around 2%:

normal.table:MultiSource/Applications/kimwitu++/kc 6.4902 3564968
8.1354
use-diet.table:MultiSource/Applications/kimwitu++/kc 6.6518 3564968
8.1064
ggreif$ expr 66518000 / 64902
1024



>
> Using less memory is great, though the approach used by use-diet to
> eliminate the User field makes the code significantly more complicated,
> so I'm looking forward to some nice comforting data on what the
> savings is :-).

Yes, Owen kindly provided shark Malloc statistics of the dealII SPEC
test. It has shown 13% of memory savings.

Cheers,

   Gabor


>
> Thanks,
>
> Dan