[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libunwind-devel] Testing time

From: Lassi Tuura
Subject: Re: [Libunwind-devel] Testing time
Date: Thu, 5 May 2011 18:09:02 +0200


>> I refreshed the performance optimisation patch to reflect the current git 
>> tree; attached at the end.
> Sorry for the delay in reviewing this. I was a bit worried about the
> static branch prediction hints, given articles such as [1].

Yup, I'd agree, but I don't really know how we'd go about using 'real'
benchmark results to guide builds to use better data. And they do make
a difference - I think I profiled most of the changes individually to
check for improvement.

Of course my sample is tiny in terms of systems. But at least there is
some measurement behind it, not just gut feeling.

> But it doesn't look like it's causing gcc to emit prefixes to branch
> instructions. Gcc (at least the version I looked at) is doing the
> right thing, by moving the unlikely code to a forward branch, which is
> statically predicted to be not taken (and probably resulting in better
> icache behavior).


> -HIDDEN void *
> -tdep_uc_addr (ucontext_t *uc, int reg)
> -{
> -  return x86_64_r_uc_addr (uc, reg);
> -}
> Things like this could be handled by gcc-4.6 -flto (some simple
> examples I tried worked). But I'm guessing that most libunwind users
> aren't doing it and there is a benefit by eliminating the extra
> function call.

Yes, over time LTO should help things like this. I guess there are
more opportunities for this in libunwind - some things are done with
macros, some with functions, I think a few things could be helped by
inlining and resulting optimisation opportunities. OTOH, at least in
our use case with x86-64 fast trace, the total percentage of time
spent in those other things starts to be quite small.

> I went ahead and applied this patch as-is with minor whitespace fixes.

Thanks! I've confirmed everything works fine for us with current git head.

There was one more patch I submitted before, any thoughts on including
it? Original was
(03-single-level-hash.patch). I've reattached an updated version after
updating to git head (line number changes only) and removing references
to unused variables (hi, lo; the make output is so verbose I missed these,
used -Werror build to catch warnings).

This adds a separate further small optimisation which isn't critical. The
improvement is marginal.


Attachment: libunwind-perf-v2.patch
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]