[LLVMdev] Status of use-diet so far (NO API CHANGES)
ggreif at gmail.com
Mon Apr 28 04:19:47 PDT 2008
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
> co-allocating Use arrays with their users, and how much is due to the
> actual shrinking of the size of Use?
I cannot give you the results of extensive research, but some strong
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
ggreif$ time ~/llvm/Release/binReg/opt -disable-opt sqlite3.linked.rbc
-o sqlite3.linked.bc -f
There is a significant speedup for my patch:
expr 515000 / 521
For real times:
expr 556000 / 564
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-
When not restricting ourselves to opt, but simply building the sqlite3
application, the times become much more reasonable:
grep "^real" < sqlite3Diet.scatter.backup2 | sort
grep "^real" < sqlite3Regular.scatter.backup2 | sort
expr 96489000 / 96057
0.4% when looking at the 10th values.
I explain this with the fact that opt only runs once (paying the
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
use-diet.table:MultiSource/Applications/kimwitu++/kc 6.6518 3564968
ggreif$ expr 66518000 / 64902
> 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.
More information about the llvm-dev