You would get at least slightly better performance like this:
Draw(Clips[m_frame]);
++m_frame;
if (m_frame > 2)
m_frame = 0;
Though your readable version would probably still be slower than your
performance version due to the temporary value from the post
increment.
This sounds like the discussion about creation of temporaries
(instantiation)
in regards to postincrement overloading in C++. But, I don’t see what it has
to do with working with integers in C or C++. Any reasonable compiler
wouldn’t
waste any registers in the preincrement or postincrement case.
Optimizers aren’t
perfect, but this is fairly trivial.
I just see this thread and am reminded of all kinds of assumptions and
rules of thumb
about instruction level optimization (because I’ve been following this
stuff since the 80s demoscene)
that are correct in very specific (somtimes obsolete) contexts, but
together and misapplied
they are useless or even counterproductive. There are still
microoptimization tricks (probably more)
today, but they aren’t necessariy the same ones from 20 years ago. And
while Michael Abrash’s book
is still a good read today as it was when it was new, the specific
details in the examples are not relevant.
If one has found that they have a critical path and they are interested
in doing hand optimization or even just “helping” the compiler it is
best to do testing first, and also probably good to actually use
something like a recent copy of the Architecture Reference Manual for
the relevant hardware.
// For best performance:
//
Draw(Clips[++m_frame]);
if (m_frame > 1)
m_frame = -1;
m_frame = 0; optimizes better than m_frame = -1; (XOR instead of MOV),
That’s incorrect, they execute at the same speed.
and you’re better off using unsigned where possible.
This is totally arbitrary.
You would get at least slightly better performance like this:
Draw(Clips[m_frame]);
++m_frame;
if (m_frame > 2)
m_frame = 0;
Though your readable version would probably still be slower than your
performance version due to the temporary value from the post
increment.
That’s exactly the point.> On 13 August 2010 02:10, CWC <@charlesw> wrote:
Kenneth Bull wrote:> On 13 August 2010 02:10, CWC wrote:
m_frame = 0; optimizes better than m_frame = -1; (XOR instead of MOV),
and you’re better off using unsigned where possible.
Forgive me for interrupting… Just wanted to point out the humor of
this whole thing…
It just strikes me amusing that we have a rather involved, and I might
add interesting, discussion in about the 3-12 microsecond range
optimizations in a thread about the whole thing being too fast to begin
with…
Anyways, back to the read, and have a wonderful day. =)
m_frame = 0; optimizes better than m_frame = -1; (XOR instead of MOV),
and you’re better off using unsigned where possible.
Forgive me for interrupting… Just wanted to point out the humor of
this whole thing…
It just strikes me amusing that we have a rather involved, and I might
add interesting, discussion in about the 3-12 microsecond range
optimizations in a thread about the whole thing being too fast to begin
with…
Anyways, back to the read, and have a wonderful day. =)
3 to 12 microseconds??? How about 2 to 26, possibly 27??
And what if it were 28??? These are lofty questions, put your optimizer
where your I/o port is ;-)>> On 13 August 2010 02:10, CWC<@charlesw> wrote:
m_frame = 0; optimizes better than m_frame = -1; (XOR instead of MOV),
That’s incorrect, they execute at the same speed.
I’ve even seen stuff like this compiled as XOR eax,eax NOT eax.
Anyway, m_frame = 0; compiles smaller than m_frame = -1; even if it’s
the same clock cycles. I really don’t see any reason to use -1 here.
You could do this though, if you reorder Clips[]:
Draw(Clips[–m_frame]);
if (!m_frame) m_frame = 3;
You’ll save a bit on the conditional expression this way.
and you’re better off using unsigned where possible.
This is totally arbitrary.
Not entirely. It doesn’t make much difference here though.
You would get at least slightly better performance like this:
Draw(Clips[m_frame]);
++m_frame;
if (m_frame > 2)
?m_frame = 0;
Though your readable version would probably still be slower than your
performance version due to the temporary value from the post
increment.
That’s exactly the point.
I’m saying “probably” since the temporary may be optimized out (if
m_frame is not declared volatile), In which case the readable version
is identical to mine. I think this is part of what John’s complaining
about.On 13 August 2010 14:20, CWC wrote:
Yeah, I know. It won’t really affect the speed at which the program
runs, but it may slightly affect CPU load. Even then it’s probably
not enough to matter.On 13 August 2010 16:43, The Novice Coder wrote:
Forgive me for interrupting… ?Just wanted to point out the humor of this
whole thing…
It just strikes me amusing that we have a rather involved, and I might add
interesting, discussion in about the 3-12 microsecond range optimizations in
a thread about the whole thing being too fast to begin with…
Anyways, back to the read, and have a wonderful day. =)
m_frame = 0; optimizes better than m_frame = -1; (XOR instead of MOV),
That’s incorrect, they execute at the same speed.
I’ve even seen stuff like this compiled as XOR eax,eax NOT eax.
Anyway, m_frame = 0; compiles smaller than m_frame = -1; even if it’s
the same clock cycles. I really don’t see any reason to use -1 here.
You could do this though, if you reorder Clips[]:
Draw(Clips[–m_frame]);
if (!m_frame) m_frame = 3;
You’ll save a bit on the conditional expression this way.
and you’re better off using unsigned where possible.
This is totally arbitrary.
Not entirely. It doesn’t make much difference here though.
So if it’s not entirely arbitrary, but it doesn’t make much difference,
describe the difference it doesn’t make much of?
You would get at least slightly better performance like this:
Draw(Clips[m_frame]);
++m_frame;
if (m_frame > 2)
m_frame = 0;
Though your readable version would probably still be slower than your
performance version due to the temporary value from the post
increment.
That’s exactly the point.
I’m saying “probably” since the temporary may be optimized out (if
m_frame is not declared volatile), In which case the readable version
is identical to mine. I think this is part of what John’s complaining
about.
So your suggestion is that, compiler willing, your code might run nearly
as fast as mine “probably”?> On 13 August 2010 14:20, CWC <@charlesw> wrote:
Anyway, it’s time to drop it.On 13 August 2010 21:43, CWC wrote:
I’m saying “probably” since the temporary may be optimized out (if
m_frame is not declared volatile), In which case the readable version
is identical to mine. ?I think this is part of what John’s complaining
about.
So your suggestion is that, compiler willing, your code might run nearly as
fast as mine “probably”?
Ha ha, I don’t think you can get this thread any more off-topic
You might have to be more specific about the effect you want. Do you want a
different frame from the ones stored in the animation to be displayed? Do
you want a random frame from the animation to be displayed every once in a
while? Do you want every frame to be a random choice from the animation
frames?
Jonny DOn Sun, Aug 15, 2010 at 4:48 AM, dekyco wrote:
Ok I need a clip every half second AND a random clip.
Which means that index has to be random (between 1 and 3 becouse it
is a 3-clip animation) every half second?
You lost me…
index should generally be 0 based though (0 to 2, not 1 to 3).
Are you trying to draw two separate sprites with the same frames, or
draw one sprite with a regular animation but with random frames thrown
in, or something else?On 15 August 2010 10:32, dekyco wrote:
Ok I need a clip every half second AND a random clip.
Which means that index has to be random (between 1 and 3 becouse it
is a 3-clip animation) every half second?
this would give your regular animation at 2 frames per second, with
random frames thrown in between on the quarter second.On 15 August 2010 11:13, dekyco wrote:
You are right, draw one sprite with a regular animation but with random
frames thrown
in. AND every half second, like in my original question.
