Richard said:
Assuming proper "wait" facilities are available this is not true. It
running efficiently even leads to power saving and reduced heat.
I'm sure that some systems have proper "wait" facilities. However,
your assertion "Speed is always beneficial" requires that power-saving
wait states exist in ALL such contexts, not just "some" of them, not
even "most" of them. While most of my experience has been in a very
different environment, I have done some real-time programming, and I
know that, at the very least, the system I was using had no such
feature. It did give me the option of letting other lower-priority
tasks run while my task was waiting for something to happen, but it
had no feature that would allow it to consume any less power if all
tasks happened to be waiting at the same time, than it would have
consumed in a "busy-wait" state.
Not the point. The point is to consider. If we talk about portability we
can also consider that there is NO POINT wasting clock cycles since it
might be used in a more constricted environment later.
Portability and "real-time" don't go together. At the simplest level,
this is trivially true: no program intended to control of a particular
device could possible work as intended on a system which has no such
device installed. At a higher level, the critical problem is that the
C standard doesn't say anything about how long anything takes to
execute, not even "int a=0;". In order to work in a real-time
environment, code has to rely upon non-portable assumptions about how
fast various things occur, and use non-portable interfaces to
communicate with the devices involved.
Sigh. Did I need to state the obvious? That I assume the faster program
also is correct?
Yes, you do, since the context of your comment was objections to
Richard Heathfield correctly making precisely that "obvious" point. If
you were not endorsing and contributing to those objections, then that
fact was not clear from the words and context of your message.
I find it astonishing that you even think for ONE second that I mean a
fast WRONG program is better than a slow CORRECT one. Clearly this is
NOT what I mean.
I can't imagine any sane person believing that - yet that's precisely
what it means to object to the statement "correctness is far more
important than speed"; and bizarrely enough, that's what some people
have been doing. That statement was nothing more or less than a
different way of saying that "a fast WRONG program is not better than
a slow CORRECT one". Anyone interpreting it in some other fashion
wasn't paying attention (as, for example, the person who confused
"correctness" with "portabilty").
