question about macro?

[Flash Gordon]

What processor? Just curious...

Well, it seems the exact range I used is out of production, but the
family continues with similar attributes... the manual I just looked at
gives a 6 stage pipeline, but still not cache or out-of-order execution
or anything like that.

http://focus.ti.com/lit/ug/spru131g/spru131g.pdf

One advantage of such processors is that sometimes you have hard
real-time requirements where something has to take an *exact* amount of
time, and doing the output early is just as bad as doing it late. Or
sometimes, the exact time does not matter as long as every run is a
consistent amount of time. In such situations *not* having a cache or
anything else introducing variability is *very* useful, and you can
count clock cycles.

 

[Phil Carmody]

MBALOVER wrote:
Hi all,

Actually I want my code to be

for (i=0;i<N;i++)
{
array2[i*30]=array1;
..................
array2[i*30+29]=array1;
}

If there anyway to use macros to do it instead for listing out
manually in the code like above?

Forget macros, they won't help here.

How about memset?

On many installations, you'll find that's a macro! ;-)

(untested)

memset( array2+i*30, array1, 30*sizeof(array2[0]) );

As Keith has pointed out memset won't do. memcpy, on the other hand,
can do it in 5 calls:

array2[i+30] = array1;
memcpy(array2+i*30 + 1, array2[i+30], sizeof array2);
memcpy(array2+i*30 + 2, array2[i+30], 2 * sizeof array2);
memcpy(array2+i*30 + 4, array2[i+30], 4 * sizeof array2);
memcpy(array2+i*30 + 8, array2[i+30], 8 * sizeof array2);
memcpy(array2+i*30 + 16, array2[i+30], 14 * sizeof array2);

Note the final multiplier (if I've go it right).

14's right. The +30's should be *30's.

Of course. Thanks.

I timed this against a naive loop for int, long long, and
double types. Conclusions were inconclusive. For double,
the naive loop was faster when compiled for plain i386, but
slower when 'optimised' for the actual athlon-xp architecture.
For int and long long, the memcpys were faster than the loop.
The memcpys were in fact simply unrolled completely.

Was this for the *30 example or the latter *1000 example?
*30

Given that there was a case where the memcpys were measurably
slower, it's not worth blindly going for the clever technique
until you've both found that the naive loop is slowing you down
and measured the two to make sure that the optimisation is in
fact an improvement. Writing a clever version for speed without
measuring whether it's faster or not is dumb. And frequently
done, alas.

The measuring is important but you can't find out that it is not
always faster without writing it! Having written it, I'd be tempted
to keep it around in some sort of conditional compilation so that it
can be switched in when/if measurements show that it is better on some
architecture/implementation.

Indeed. I hope that my comment wasn't taken as a "don't even
suggest it" one. Of course, you have to suggest possibilities
before they are demonstrated to be preferable (likewise inferior).

One does ave to weight the maintenance cost, so there must be at least
the possibility of a benefit.

A simple comment like "/* we now have 16, only need 14 more */" would
be more than enough in your memcpy version. As someone who's maintained
a lot of old code (not admitting to how much of it was originally mine -
having said that, having about a million lines of crap dumped on me once
probably dwarfs all the crap that I've written (I hope)), I do quite
often very clearly see the maintainter's view.

In fact one mantra I picked up recently was something along the lines of
"you are always writing code to be read by someone else - yourself in the
future".

Phil

 

[Seebs]

The first time that I saw C code that I wrote,
but hadn't seen in six months,
I was surprised by how hard it was for me to understand it.

I recently had occasion to dive into some code I had written roughly a
year and a half ago, and let me tell you, I am glad that there were
comments.

My favorite:

/* Want to mess with this? You will need a young priest and an old priest. */

That code is gone now.

-s

 

[Ian Collins]

In fact one mantra I picked up recently was something along the lines of
"you are always writing code to be read by someone else - yourself in the
future".

Which is why all new code should have comprehensive unit tests. Want to
see examples of how to use the code? Read the tests. Want to see if you
changes break the code? Run the tests. Simple.

My tests certainly save me a lot of time and pain when going back to
update my old code.