This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Aliasing performance problem.


On Mon, Nov 2, 2009 at 02:24, John Fine <johnsfine@verizon.net> wrote:
> My first guess would be an alignment problem.

I tried to add __attribute__ ((align)) to the tab array, didn't help a bit.
Any other way I can try?

> But that is just a guess
> especially since you didn't say anything about how Elt aligns.

Elt usually is an int as well, but ocasionally a struct made of bunch of ints.

>
> Also, an alignment problem is a little less likely in the code you actually
> posted than it would be in the real code that you cut this out of. ÂDo you
> really have the performance problem with this code?

I optimized this code very much: consistent 1-2% perfomance improvemnt
was enough to accept the change to repository.
This way I learned a lot (especially how costly branches are). So yes,
25% loss is a big problem for me.


>ÂOr have you simplified
> the code to the point that you can't measure the performance?

The code iself is not simplified. But the calling patters are compicated.
For instance I use
NatMap <Vertex, Vertex> next;
to represent set of disjont cyclic lists with:
act = next [act];   // act is of type Vertex
going to next element. I loop over this lists, merge them, etc
There is more but I think this example is enough to ilustrate the usage.



>
> I understand the strict-aliasing issue, but in this case it shouldn't
> actually be a problem.

> ÂYou always access the data as Elt and never as char,
> so the fact that you allocate as char should only be an alignment issue, not
> an aliasing issue.
>
> Åukasz Lew wrote:
>>
>> Hi,
>>
>> I have a container similar to this one.
>>
>> template <typename Nat, typename Elt>
>> class NatMap {
>> Âpublic:
>> ÂElt& operator[] (Nat nat) {
>> Â Âreturn tab [nat.GetRaw()];
>> Â}
>> Âprivate:
>> ÂElt tab [Nat::kBound];
>> };
>>
>> I wanted to drop the requirement for Elt to have a default constructor:
>>
>> template <typename Nat, typename Elt>
>> class NatMap {
>> Âpublic:
>> ÂElt& operator[] (Nat nat) {
>> Â Âreturn ((Elt*)tab) [nat.GetRaw()];
>> Â}
>> Âprivate:
>> Âchar tab [Nat::kBound * sizeof(Elt)];
>> };
>>
>> I use g++-4.3 and this code works 25% slower in my application than
>> the previous one. Unfortunately the slowdown does not manifest in a
>> synthetic benchmark. I guess it is something about compiler
>> optimizations, aliasing, aligning, or similar stuff.
>>
>> Just now I tried new g++-4.4 and it gave me a following warning for
>> the latter code:
>> dereferencing pointer '<anonymous>' does break strict-aliasing rules
>>
>> What should I do to get my performance back? (while not needing the
>> default constructor)
>>
>> Thanks for any suggestion.
>> Lukasz
>> PS
>> If this is lack optimizations because of aliasing info, this has to be
>> doable somehow as STL have the same problem, doesn'it ?
>>
>>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]