On Mon, Nov 2, 2009 at 02:24, John Fine <johnsfine@xxxxxxxxxxx> 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 ?
>>
>>
>
