Re: Double increment question.

"Robbie Hatley" <bogus.address@xxxxxxx> wrote in message
news:arOxg.75720$Lm5.32482@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Eric Sosman wrote of my string copy experiments:

... it seems more than a little likely that you are
committing the sin of premature optimization.

If this was a large app for long-term use by many, being
built and maintained by a team, then perhaps that might be
true.

But it's actually a tiny hobby app which I wrote expressly
for the purpose of optimization experimentation.

By all means then, experiment. It is an interesting exercise to find out how
fast you can implement something.

But I hope you understand how useless such practices are in real code,
outside of system libraries (such as those that implement memcpy() ). Also
see the below caveat about how to measure improvements.

Until and unless you have MEASURED a performance problem
not hypothecated, not supposed, not "it stands to reason-ed"
until you have made MEASUREMENTS it is irresponsible folly to
micro-optimize.

It's already in a batch file like so:

clock
MyProgram
clock

So I can instantly see whether making a particular change
causes execution time to go up, go down, or stay about the
same.

Hypotheses must come first. Then experimentation to determine
whether your hypotheses are brilliance or bunk. That's the
scientific method.

That is indeed the scientific method. However, your experiment doesn't
measure what you think it measures, and so will lead you to false
conclusions.

Much of the time between the two calls to "clock" will be set-up before
running MyProgram (allocating memory, loading code into memory, initialising
data, changing memory protection setup) and clean-up afterwards
(deallocating memory &c). These can take variable amounts of time depending
on how busy the OS is, how much of your program is in cache already, and the
phase of the moon, and so the variations in setup and cleanup can be greater
than the time-change to the core of the program. This means that even if
your program is running faster, it can appear to run slower, or worse - if
it is running slower, it can appear to run faster.

It's much better to use a tool designed for the job, such as a profiler.

"Premature optimization is the root of all evil."
-- D.E. Knuth

No, I think religiosity (addiction to untested ideas) is the
cause of most evil (including many bad computer programs, and
also including most wars).

It's not an untested idea. It's based on years of collective experience.

"We follow two rules in the matter of optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet."
-- M.A. Jackson

That's stupid. Fear gains nothing. Say instead:
1. If you see an opportunity to optimze, do it, as long as it
doesn't significantly damage readibility or modularity.

You've already broken your own rule. The "optimization" you wrote was
sufficiently confusing that you had to ask c.l.c about it. memcpy() would
have been much more readable.

2. Test it.
3. If it didn't significantly improve performance, revert.

Amdahl's law: optimize the common case.

If you optimize code which executes rarely, you spend lots of time on steps
1,2 and 3 above for an optimization which doesn't gain you much *overall*
speedup. Programmer time is expensive.

Remember that you don't know what "the common case" is until you have
measured it using a profiler. If you hold off optimization until the program
is complete or near-complete, you have a much better idea of a) whether any
optimization is necessary, and b) if it is necessary, where it should be
targeted. Hence "Don't do it yet.".

In most cases, optimization won't be necessary at all - the code is good
enough. All that effort on your 3-step plan will have been wasted.

In other words, I'm not the only person crying that ab initio
micro-optimization is folly; smart people do so, too. Be smart.

False reasoning. Imitating superficial aspects of the behavior
of smart people will not make one smart.

Ignoring smart people does not make one smart either.

And while it is perhaps true that most programs should not be
"optimized ab inito", some should be.

Yes. One example of code which should be "optimized ab inito" is that used
in system libraries, like implementations of memcpy(). If you are truly
interested in optimization, I suggest you learn about how memcpy() is
implemented on various machines. It's very interesting, and a good example
of why such optimizations should be restricted to library code.

Philip

.

Relevant Pages

  • Re: Double increment question.
    ... committing the sin of premature optimization. ... But it's actually a tiny hobby app which I wrote expressly ... for the purpose of optimization experimentation. ...
    (comp.lang.c)
  • Re: expression bit lengths in gate primitive terminals
    ... It looks like verilog XL does handle expressions differently: ... Some experimentation shows that it is not ... optimization put in for literal constants that did not perform the ... usual reduction-OR. ...
    (comp.lang.verilog)
  • Re: Results of the memswap() smackdown from the thread "Sorting" assignment
    ... you used small strings for a reason. ... (but not as good as Ben's optimization) ... relying on the quality of whatever library does memcpy while at the ... a way that I can redefine any library function by a macro. ...
    (comp.programming)
  • Re: Defeating Optimisation for memcmp()
    ... You need to expand your description of the problem to make that point clear; as soon as you do so, we can tell you what to do to prevent the optimization. ... The detail is simply that the code is writing to CMOS. ... The only reason I can think of for your comments is that you were assuming I wanted to check the write because I wasn't confident that memcpy was implemented correctly. ... You said that the memory being pointed at was not volatile. ...
    (comp.lang.c)
  • Re: WaitForSingleObject() will not deadlock
    ... It seems that "memory visibility" has something to do with making sure that results are in ... shared variables should be declared 'volatile' to ensure the compiler ... optimization fence into the intermediate instruction stream inside the compiler). ...
    (microsoft.public.vc.mfc)