6 Jan
2012
6 Jan
'12
4:43 p.m.
On 1/5/12 8:43 PM, "Fred Cisin" <cisin at xenosoft.com> wrote:
[snip]
BUT, even in this example, unless the compiler does
"optimization" to
compile something other than what you asked for (DWIM!) and removes the
temporary variable,
The only time modern compilers don't do optimization is when you tell them
not to, usually so you can step through the code in a debugger. One of
the most common optimizations is the elimination of temporary variables
(which is why you turn off optimization to step through it!). After being
a test manager over a compiler suite that served several different types
of processor on which the target OS ran and seeing the same principles
expressed on load/store architectures and (ugh) x86, I now routinely opt
for clarity in my C code because I have confidence the compiler will
collapse all of the 'courtesy code' into something every bit as tight as
if I'd tried to be tricky and terse. And, as someone else noted on this
thread, it's a whole lot easier if someone (even if it's you) must look at
this code six months later.
the long version will be a TINY bit slower due to the
extra temporary variable being written and read, and then read again for
the comparison. In the "short" )"crammed together") version the value
is
in a register when it is needed, and presumably in the accumulator for the
conditional jump that the while translates to. Likewise, by incrementing
the pointers separately from de-referencing them, you'll probably end up
with an an "unnecessary" retrieval of the pointer value from memory
instead of register for the de-reference.
If the purpose is the fastest possible code, that stuff matters.
Another thing modern compilers do is optimize stuff we don't think about,
for instance, load hoists or elimination of redundant memory accesses in
optimized code. (I saw some of the latter in a compiler I wrote as part
of a graduate-level compiler course, as my simple optimizations created
some redundant sequences that a more sophisticated compiler eliminates
through such mechanisms as keyhole optimization.) They can play to
processor-specific attributes such as cache size and branch optimization,
too. Relax and write clear code.
If the purpose is having the students understand it, without having to
decipher the "puzzle code", delaying them moving on to the rest of the
topic, the long version is far superior.
THAT's where Holub and I don't agree - he considers the long version to be
bordering on "WRONG", even for classroom blackboard! In one of his
columns, he actually CORRECTED similar code in a reader question (about
another issue) - I felt that ease of comprehension by his
readers/students should be a higher priority than "efficiency"
Yeah, having debugged code that tried to be 'clever' and could have been
written clearly instead, Holub and I would be on opposite sides of that
argument. It was true thirty years ago that 'cleverly' written C could be
faster (and there were tests to prove it), but there's little
justification for that position today. -- Ian