For performance small arrays should be the same as individual members
(I can see the annoying fact that initialization is a headache - this has
annoyed me as well). For larger arrays (4 members), aliasing will
make a difference possibly, making the array variant slower. Any union
variant is
On 7/25/07, Paolo Bonzini [EMAIL PROTECTED] wrote:
For performance small arrays should be the same as individual members
(I can see the annoying fact that initialization is a headache - this has
annoyed me as well). For larger arrays (4 members), aliasing will
make a difference possibly,
On 7/21/07, tbp [EMAIL PROTECTED] wrote:
On 7/19/07, Richard Guenther [EMAIL PROTECTED] wrote:
Of course, if any then the array indexing variant is fixed. It would be nice
to see a complete testcase with a pessimization, maybe you can file
a bugreport about this?
There's many issues for all
On 7/24/07, Richard Guenther [EMAIL PROTECTED] wrote:
For performance small arrays should be the same as individual members
(I can see the annoying fact that initialization is a headache - this has
annoyed me as well). For larger arrays (4 members), aliasing will
make a difference possibly,
On 7/19/07, Richard Guenther [EMAIL PROTECTED] wrote:
Of course, if any then the array indexing variant is fixed. It would be nice
to see a complete testcase with a pessimization, maybe you can file
a bugreport about this?
There's many issues for all alternatives and i'm not qualified to
I have that usual heavy duty 3 fp components class that needs to be
reasonably efficient and takes this form for g++
struct vec_t {
float x,y,z;
const float operator()(const uint_t i) const { return *(x + i); }
float operator()(const uint_t i) { return *(x + i); } // --
On 7/19/07, tbp [EMAIL PROTECTED] wrote:
I have that usual heavy duty 3 fp components class that needs to be
reasonably efficient and takes this form for g++
struct vec_t {
float x,y,z;
const float operator()(const uint_t i) const { return *(x + i); }
float
On 7/19/07, Richard Guenther [EMAIL PROTECTED] wrote:
Well, I always used the array variant, but you should be able to do
[snip]
if you need to (why does the array form not work for you?)
Because if you bench in some non trivial program, on x86/x86-64 at
least, those variations (struct {
On Thu, 19 Jul 2007, tbp wrote:
On 7/19/07, Richard Guenther [EMAIL PROTECTED] wrote:
Well, I always used the array variant, but you should be able to do
[snip]
if you need to (why does the array form not work for you?)
Because if you bench in some non trivial program, on x86/x86-64 at
On 19 July 2007 14:08, tbp wrote:
I have that usual heavy duty 3 fp components class that needs to be
reasonably efficient and takes this form for g++
struct vec_t {
float x,y,z;
const float operator()(const uint_t i) const { return *(x + i); }
float operator()(const
On 7/19/07, tbp [EMAIL PROTECTED] wrote:
On 7/19/07, Richard Guenther [EMAIL PROTECTED] wrote:
Well, I always used the array variant, but you should be able to do
[snip]
if you need to (why does the array form not work for you?)
Because if you bench in some non trivial program, on x86/x86-64
On 7/19/07, Richard Guenther [EMAIL PROTECTED] wrote:
Of course, if any then the array indexing variant is fixed. It would be nice
to see a complete testcase with a pessimization, maybe you can file
a bugreport about this?
By essence they're hard to trigger in small testcases (that's not
where
On 7/19/07, Dave Korn [EMAIL PROTECTED] wrote:
Bogus codegen is the inevitable result of bogus code. Garbage in, garbage
out.
BTW, the const indexing is completely undefined too.
That's the kind of answer i'd get from gcc-help and at that point i'd
be none wiser because i already know
On 19 July 2007 20:38, tbp wrote:
On 7/19/07, Dave Korn wrote:
Bogus codegen is the inevitable result of bogus code. Garbage in,
garbage out.
BTW, the const indexing is completely undefined too.
That's the kind of answer i'd get from gcc-help and at that point i'd
be none wiser
14 matches
Mail list logo
