[LLVMdev] PATCH: Use size reduction -- wave2
ggreif at gmail.com
Wed Apr 23 05:07:25 PDT 2008
On Apr 17, 4:12 am, Chris Lattner <sa... at nondot.org> wrote:
> On Apr 16, 2008, at 11:25 AM, Dan Gohman wrote:
> >> So, my idea is that these changes are performance neutral.
> I strongly agree with Dan that we need to measure performance to
> ensure there is no significant performance regression.
finally I am in possession of hard performance data on
a realistic testcase (kimwitu++).
I have 20 measurements regading trunk LLVM and 5 with my changes
###### TRUNK + DIET
pixxi:~ ggreif$ cat kimwituFastDiet50147.scatter|grep user|sort
pixxi:~ ggreif$ cat kimwituRegular.scatter.backup|grep user|sort
ratio of the two best CPU times:
pixxi:~ ggreif$ expr 854040000 / 85127
ratio of the two second best CPU times:
pixxi:~ ggreif$ expr 854530000 / 85132
It looks like we have a degradation of 0.3%.
The <system> and <real> times show no surprises at all.
There is one important change still missing from the
use-diet branch, viz. the capacity of the BitcodeReaderValueList
is computed very naively with the new algorithm at each push_back.
I left this in to see whether the algorithm scales.
Kimwitu++ bitcode-reading puts more than 250.000 Use
objects into a contiguous array. To get its capacity
my algoritm has to visit more than 18 pointers each time.
Tonight I will store the capacity in a member variable,
and run comprehensive tests. I expect further speedups,
possibly even parity.
Barring any surprises I plan to merge the use-diet branch to
trunk this weekend. Owen promised to help me doing more
performance evaluations till then, so we get a clearer
I have also downloaded CHUD, so maybe even looking at
(and fixing) of bottlenecks is feasible in the next days.
What do you think?
PS: Yes I will send out several mails to llvm-dev before
and after merging.
> >> I hope that this is interesting, but I'd like to ask anybody who is
> >> comfortable with performance testing to help provide some hard
> >> data :-)
> > I agree that performance testing is not easy and requires resources,
> > but I'm curious what's motivating this project here. My assumption
> > has been that no one would likely go to the extreme of inventing a
> > mini-language encoded in the least significant bits of pointer
> > members in successive structs unless they were pretty desperate for
> > performance or scalability.
> Ah, this question is easy: it shrinks the Use class by a word, which
> reduces the most popular class in the LLVM IR by 25%. This directly
> makes all binary operators 8 bytes smaller for example, which is a
> pretty big memory footprint win, and memory footprint translates to
> dcache efficiency as well.
> LLVM Developers mailing list
> LLVM... at cs.uiuc.edu http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
More information about the llvm-dev