llvm dev - Mar 2016 - LLD: Possible optimization for TargetInfo

I was wandering how much is the overhead of virtual function calls of
TargetInfo member functions. TargetInfo handles platform-specific details,
and we have target-specific subclasses of that class. The subclasses
override functions defined in TargetInfo.

The TargetInfo member functions are called multiple times for each
relocation. So the cost of virtual function calls may be non-neglible. That
is a motication to do the following test.

As a test, I removed all TargetInfo subclasses except for x86-64, move all
code from X86_64TargetInfo to TargetInfo, and remove `virtual` from
TargetInfo.

The original LLD links itself (with debug info) in 7.499 seconds. The
de-virtualized version did the same thing in 7.364 seconds. So it can
improve it by 1.8%.

I'm just pointing out that there's room there to improve performance,
and
I'm not suggesting we do something for this right now. We probably
shouldn't do anything for this because the current code is pretty
straightforward. But I'd expect that we will eventually want do something
for this in future.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160330/2da3e72f/attachment.html>

I believe the relocation stuff that Rafael is currently working on will
make this a non-issue (it will make relocation application much friendlier
for the CPU).

However, even in the current scheme, since the target is fixed, all the
indirect call sites should be monomorphic and so there shouldn't be much
branch-prediction cost (certainly nothing that would cause 1.8% performance
delta for the entire link).

Notice that 1.8% is smaller than the performance variation from r263227
which is a very innocuous-looking change but caused ~2-3% slowdown for
ScyllaDB (see the thread "LLD performance w.r.t. local symbols (and
--build-id)").

-- Sean Silva

On Wed, Mar 30, 2016 at 3:39 PM, Rui Ueyama via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I was wandering how much is the overhead of virtual function calls of
> TargetInfo member functions. TargetInfo handles platform-specific details,
> and we have target-specific subclasses of that class. The subclasses
> override functions defined in TargetInfo.
>
> The TargetInfo member functions are called multiple times for each
> relocation. So the cost of virtual function calls may be non-neglible. That
> is a motication to do the following test.
>
> As a test, I removed all TargetInfo subclasses except for x86-64, move all
> code from X86_64TargetInfo to TargetInfo, and remove `virtual` from
> TargetInfo.
>
> The original LLD links itself (with debug info) in 7.499 seconds. The
> de-virtualized version did the same thing in 7.364 seconds. So it can
> improve it by 1.8%.
>
> I'm just pointing out that there's room there to improve
performance, and
> I'm not suggesting we do something for this right now. We probably
> shouldn't do anything for this because the current code is pretty
> straightforward. But I'd expect that we will eventually want do
something
> for this in future.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160330/0bc1b292/attachment.html>

On Wed, Mar 30, 2016 at 4:20 PM, Sean Silva <chisophugis at gmail.com>
wrote:
> I believe the relocation stuff that Rafael is currently working on will
> make this a non-issue (it will make relocation application much friendlier
> for the CPU).
>
I don't think Rafael's patch would make this a non-issue. He's
making
scanRelocs to create data, which would reduce the number of calls to the
virtual functions, but it wouldn't be reduced to zero.

However, even in the current scheme, since the target is fixed, all
the
> indirect call sites should be monomorphic and so there shouldn't be
much
> branch-prediction cost (certainly nothing that would cause 1.8% performance
> delta for the entire link).
>
Agreed. We could template functions that call TargetInfo's member functions
for each target to eliminate the virtual function calls.

> Notice that 1.8% is smaller than the performance variation from r263227
> which is a very innocuous-looking change but caused ~2-3% slowdown for
> ScyllaDB (see the thread "LLD performance w.r.t. local symbols (and
> --build-id)").
>
> -- Sean Silva
>
> On Wed, Mar 30, 2016 at 3:39 PM, Rui Ueyama via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> I was wandering how much is the overhead of virtual function calls of
>> TargetInfo member functions. TargetInfo handles platform-specific
details,
>> and we have target-specific subclasses of that class. The subclasses
>> override functions defined in TargetInfo.
>>
>> The TargetInfo member functions are called multiple times for each
>> relocation. So the cost of virtual function calls may be non-neglible.
That
>> is a motication to do the following test.
>>
>> As a test, I removed all TargetInfo subclasses except for x86-64, move
>> all code from X86_64TargetInfo to TargetInfo, and remove `virtual` from
>> TargetInfo.
>>
>> The original LLD links itself (with debug info) in 7.499 seconds. The
>> de-virtualized version did the same thing in 7.364 seconds. So it can
>> improve it by 1.8%.
>>
>> I'm just pointing out that there's room there to improve
performance, and
>> I'm not suggesting we do something for this right now. We probably
>> shouldn't do anything for this because the current code is pretty
>> straightforward. But I'd expect that we will eventually want do
something
>> for this in future.
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160330/b7a72d70/attachment.html>