«

memset and memcpy are turning up in profiles a lot. I'd like to speed
things up a bit.

Sometimes it is clear that using = to initialize a local would be
better than memset. I might not gain anything, but at least there's a
chance.

However, can I gain performance improvements when zeroing out say some
global element in an array like so:

typedef struct x { int var0; char var1[20]; } X;

X gX[30];

void f(int slot)
{
X init = {0};

gX[slot] = init;

...
}

vs.
void f(int slot)
{
memset(&gX[slot], 0, sizeof(X));

...
}

Normally I wouldn't look for a micro-optimization like this but I'm
kind of stuck with the parameters I'm given.

Am 02/07/2012 06:02 PM, schrieb nroberts:
> X gX[30];
>
> void f(int slot)
> {
> X init = {0};
>
> gX[slot] = init;
>
> ...
> }

make it

X const init = { 0 };

or even better use a compound literal

gX[slot] = (X const){ 0 };

> Normally I wouldn't look for a micro-optimization like this but I'm
> kind of stuck with the parameters I'm given.

On any decent compiler the assignment version should not be worse that
the memset version, because the compiler must be able to see that it
is an object only filled with 0.

On the other hand the assignment version *may* be better, when the
compiler can do a data flow analysis that shows e.g that part of what
you initialize is overwritten before being read.

So I'd always prefer the assigment version.

Jens

On 02/07/2012 12:41 PM, Jens Gustedt wrote:
> Am 02/07/2012 06:02 PM, schrieb nroberts:
>> X gX[30];
>>
>> void f(int slot)
>> {
>> X init = {0};
>>
>> gX[slot] = init;
>>
>> ...
>> }
>
> make it
>
> X const init = { 0 };
>
> or even better use a compound literal
>
> gX[slot] = (X const){ 0 };
>
>> Normally I wouldn't look for a micro-optimization like this but I'm
>> kind of stuck with the parameters I'm given.
>
> On any decent compiler the assignment version should not be worse that

This is initialization, not assignment.

> the memset version, because the compiler must be able to see that it
> is an object only filled with 0.

I've used a compiler which, given the following code:

double array[10][1354][3] = {0};

generated the equivalent of the following:

array[0][0][0] = 0;
array[0][0][1] = 0;
etc.
The resulting executable was noticeably larger that I had expected it to
be. I was a little annoyed when I figured out what was going on. I
changed it to use memset(), and got a lot smaller, and executed somewhat
faster, too. The support person I talked with said that my use of {0}
was unreasonable, not their compiler's code generation.

On Feb 7, 9:41*am, Jens Gustedt <jens.gust...@loria.fr> wrote:
> Am 02/07/2012 06:02 PM, schrieb nroberts:
>
> > X gX[30];
>
> > void f(int slot)
> > {
> > * X init = {0};
>
> > * gX[slot] = init;
>
> > * ...
> > }
>
> make it
>
> X const init = { 0 };
>
> or even better use a compound literal
>
> gX[slot] = (X const){ 0 };
>
> > Normally I wouldn't look for a micro-optimization like this but I'm
> > kind of stuck with the parameters I'm given.
>
> On any decent compiler the assignment version should not be worse that
> the memset version, because the compiler must be able to see that it
> is an object only filled with 0.
>
> On the other hand the assignment version *may* be better, when the
> compiler can do a data flow analysis that shows e.g that part of what
> you initialize is overwritten before being read.
>
> So I'd always prefer the assigment version.
>
> Jens

LOL!

Nevermind. I'm not allowed to use this language feature. It's too
"complex". People won't know what it does.

Not the '=' operator... Initializing a structure to all 0 with = {0}.

:/

I keep running into bosses like this. Is this normal in the
programming field or am I just incredibly unlucky?

Am 02/07/2012 07:40 PM, schrieb James Kuyper:
> On 02/07/2012 12:41 PM, Jens Gustedt wrote:
>> On any decent compiler the assignment version should not be worse that
>
> This is initialization, not assignment.

No, you are mistaken. The relevant part is assignment to gX[slot]. The
other part is just initialization of a const. In particular the
initialization of the const qualified compound literal can be done at
compile time if the compiler decides that it is beneficial (as if it
where declared as a static variable).

>> the memset version, because the compiler must be able to see that it
>> is an object only filled with 0.
>
> I've used a compiler which, given the following code:
>
> double array[10][1354][3] = {0};
>
> generated the equivalent of the following:
>
> array[0][0][0] = 0;
> array[0][0][1] = 0;
> etc.
> The resulting executable was noticeably larger that I had expected it to
> be. I was a little annoyed when I figured out what was going on. I
> changed it to use memset(), and got a lot smaller, and executed somewhat
> faster, too. The support person I talked with said that my use of {0}
> was unreasonable, not their compiler's code generation.

How long ago and what compiler was that? My observation over the last
years is that a compiler like gcc is capable of optimizing assignments
to struct fields or different array members as if all of these were
different variables.

(and double may be special, setting all bytes to 0 and initializing
with 0 must not necessarily be the same thing.)

Jens

nroberts <> writes:

> Nevermind. I'm not allowed to use this language feature. It's too
> "complex". People won't know what it does.
>
> Not the '=' operator... Initializing a structure to all 0 with = {0}.

Look on the bright side: on that basis, you should have no
trouble avoiding C++ entirely at that workplace.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1utchar(a[i&15]);break;}}}

On Feb 7, 6:40*pm, James Kuyper <jameskuy...@verizon.net> wrote:
> The support person I talked with said that my use of {0}
> was unreasonable, not their compiler's code generation.
>
Well what can he say? He can't patch the compiler to replace a long
intialisation with a call to memset().

On Feb 7, 11:14*am, b...@cs.stanford.edu (Ben Pfaff) wrote:
> nroberts <roberts.n...@gmail.com> writes:
> > Nevermind. *I'm not allowed to use this language feature. *It's too
> > "complex". *People won't know what it does.
>
> > Not the '=' operator... Initializing a structure to all 0 with = {0}.
>
> Look on the bright side: on that basis, you should have no
> trouble avoiding C++ entirely at that workplace.

I don't consider that a good thing.

On 2/7/2012 14:37, Malcolm McLean wrote:
> On Feb 7, 6:40 pm, James Kuyper<jameskuy...@verizon.net> wrote:
>> The support person I talked with said that my use of {0}
>> was unreasonable, not their compiler's code generation.
>>
> Well what can he say? He can't patch the compiler to replace a long
> intialisation with a call to memset().
>

Call == LOL. Good one.

And the support person cannot patch the compiler to replace a 'struct'
object assignment with a call to 'memcpy' either, presumably.

I've used a Microsoft C implementation which actually will give you a
linker error if you do:

void func(void) {
int array[42] = { 0 };
return;
}

and choose not to link with the standard library... It complains about
a missing 'memset' symbol...

On 2/7/2012 14:07, nroberts wrote:
> LOL!
>
> Nevermind. I'm not allowed to use this language feature. It's too
> "complex". People won't know what it does.
>
> Not the '=' operator... Initializing a structure to all 0 with = {0}.
>
> :/
>
> I keep running into bosses like this. Is this normal in the
> programming field or am I just incredibly unlucky?

That feature has been around since C89/C90. Perhaps you can find a
clever way for your boss to find that out without losing face or without
regretting disallowing its use.