Re: [DynInst_API:] DynInst Overhead

[Bill Williams <bill@xxxxxxxxxxx>]

On 07/21/2014 01:59 PM, Buddhika Chamith Kahawitage Don wrote:
> Please find my responses inline.
>
> On Mon, Jul 21, 2014 at 1:48 PM, Bill Williams <bill@xxxxxxxxxxx
> <mailto:bill@xxxxxxxxxxx>> wrote:
>
>     On 07/21/2014 11:52 AM, Matthew LeGendre wrote:
>
>
>         Presumably you're running the CodeCoverage tool in two steps: 1)
>         Rewriting the binary 2) Running the rewritten binary.  All of the
>         analysis/rewriting overheads are in step 1, and the instrumentation
>         overhead can be measured just by timing step 2.
>
>
> That's true.
>
>
>         If you're getting 50x overhead on just step 2 then something's very
>         wrong. I've got my own codeCoverage tool (which I unfortunately
>         can't
>         share yet) and I only see 10% overhead.
>
>     Hrm. If this is with a prebuilt, statically linked binary and not
>     with a build from source against current Dyninst, we may also be
>     hitting traps in an inner loop. That's more the right order of
>     magnitude than trampguards would be--trampguards would be in the
>     1.5-5x sort of neighborhood off the top of my head.
>
>
> In fact that was the use case I had in my mind. But I was just checking
> the static rewriting case first up since it was readily available with
> code-coverage tool.
Sorry, I meant a statically linked version of the CodeCoverage tool; 
apologies for the confusion.
>     The source for CodeCoverage (which you can build against the latest
>     Dyninst and be reasonably sure of *not* hitting traps in almost all
>     of SPEC) is in our tools.git repository. I know we've fixed some
>     performance regressions that turned up between the AWAT paper and 8.1.2.
>
>
> I am using dyninst 8.1.2 which I built from source.
Then yes, it's probably trap overhead, and 8.2 should fix it--I believe 
h264 was on the list of benchmarks that had a performance regression 
that we've fixed for the current release.
If you set DYNINST_DEBUG_SPRINGBOARD=1 in your environment and send me 
the output of the rewriting pass with that enabled, I'll be able to 
confirm the cause (and status) of this problem.
>         Just an educated guess--I frequently see big overheads
>         associated with
>         trampoline guards.  Dyninst should have realized trampoline
>         guards are
>         unnecessary for codeCoverage and not emited them.  But if
>         something went
>         wrong you can manually turn them off by putting a call to:
>
>             bpatch.setTrampRecursive(true)__;
>
>
> Tried it without any success :(
>
>
>         Near the top of codeCoverage.C's main() function.  If that makes a
>         difference then let the list know.  That implies there's a bug that
>         should be investigated.
>
>
> Any ideas on how to debug this?
>
> Thanks
> Bud

--
--bw

Bill Williams
Paradyn Project
bill@xxxxxxxxxxx