|
Boost Users : |
From: Mike Marchywka (marchywka_at_[hidden])
Date: 2007-11-27 12:06:25
( sorry if the formatting is bad, I'm fighting the new hotmail editor that seems to think
graphics are more important then text....)
> Can you share a test case?
And, the compiled code if it is not too difficult?
I don't know if I can contribute anything but I am curious to see what the compilers generate.
If there is a spurious flag or combination of flags, it may be obvious in the generated code.
( extra calls in inner loop or some other dumb thing).
I guess it is possible you could have a wierd case where padding makes things worse by
increasing cache miss rate or something but otherwise I wouldn't expect it to be a big
deal.
Thanks.
Mike Marchywka586 Saint James WalkMarietta GA 30067-7165404-788-1216 (C)<- leave message989-348-4796 (P)<- emergency onlymarchywka_at_hotmail.comNote: Hotmail is blocking my mom's entireISP claiming it is to reduce spam but probably to force users to use hotmail. Please DON'Tassume I am ignoring you and tryme on marchywka_at_[hidden] if no replyhere. Thanks.
----------------------------------------
> From: john_at_[hidden]
> To: boost-users_at_[hidden]
> Date: Tue, 27 Nov 2007 16:52:28 +0000
> Subject: Re: [Boost-users] [Boost.Array] surprising performance issue
>
> Bryan Green wrote:
> > Hello,
> > I've discovered a situation where using boost::array results in a
> > 2-fold performance degradation over other array types, including C
> > arrays, tr1::array, and a simple handwritten array class.
> > While the tr1::array performs well, I was suprised to find that it
> > pads the array, so sizeof(tr1::array<3,float>) ==
> > sizeof(tr1::array<4,float>). Is that a requirement of tr1::array?
>
> No, that will be an effect of the compiler's structure alignment rules.
>
> BTW tr1::array and boost::array are basically the same thing, so I'm
> surprised that there's any difference at all.
>
> > Anyway, the performance problem can be seen using Intel C++ (v9.1) on
> > the Itanium platform, using '-O3' optimization.
> >
> > I'm forced to take boost::array out of my computation's inner loop.
> > Is this a previously known issue? Any ideas why this performance
> > discrepancy might exist?
>
> Can you share a test case?
>
> As others have already noted, defining NDEBUG is likely to have quite an
> effect as well.
>
> HTH, John.
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
_________________________________________________________________
Share life as it happens with the new Windows Live.Download today it's FREE!
http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net