Re: Why INFINITE loop in a thread occupy so much CPU time??

See below...
On Tue, 20 Nov 2007 01:40:19 GMT, Geoff <geoff@xxxxxxxxxxxxxxx> wrote:

On Sun, 18 Nov 2007 19:55:21 -0500, Joseph M. Newcomer
<newcomer@xxxxxxxxxxxx> wrote:

Note that to tell what is going on, you must look at the listing when compiled in Release
mode with optimizations on; nothing done in debug mode is worth anything in terms of
measuring code quality or program efficiency. For example, here's the code VS6 produces.
Note that it produces LARGER code because the body of the for-loop is replicated TWICE! So
the "while(TRUE)" form actually generates smaller code. Note that this form, in OPTIMIZED
VS6 code, does not do the test.

Nonsense. You stated the K&R compiler did the silly thing of testing
the constant in the loop. I showed you exactly that behavior in VC6
compiler.
****
Did you? In debug mode, nothing, repeat nothing, matters. Testing the constant remains
silly. ONLY release code matters for the discussion.
****
K&R C was a non-optimizing compiler. Comparing apples to
apples, the VC6 compiler is no better than an ancient 35 year old C
compiler.
****
Then how is it that I am able to demonstrate that VS6 does NOT do the test in release
mode?
****
Now you want to make some kind of point about optimizing
being the only way to judge code quality and program efficiency and by
implication, that while(1) is preferable to for(;;) because it
optimizes better. Let me be the first to declare BS on that point.
****
Funny, it looked to me in the generated code from the compiler that while(TRUE) actually
produced smaller code. Perhaps you can explain how the code executes to convince me that
two instances of the code are smaller than one?
****
There is and should be no difference between the two properly formed
constructs.
****
I agree. What surprised me was that VS6 treats them differently.
****
A compiler that has to be tweaked or coerced into
performing equally well for each of them is a very poor one indeed.
****
Where did I say that the compiler has to be tweaked or coerced?
****
You also managed to produce code that makes the compiler thrash in
some way and it would appear to have duplicated a block of code, after
"optimizing" I might add, that didn't exist in your pre-optimized code
that you probably didn't even look at.
****
Actually, I did. But only optimized code is worthy of discussion for code quality
discussions.
****

I will re-state for the record that the choice between while(constant)
and for(;;) is purely a matter of style and the choice should be what
makes sense for clarity and maintenance and not what the compiler is
putting out in debug or release mode. If you like littering your code
with pragmas to suppress the warnings about while(constant) or
lowering the warning thresholds on your compiler so you don't have to
be nagged, be my guest.
****
while(constant) and if(constant) should NEVER be diagnosed as representing a problem. The
fact that they do means that the compiler is doing something it shouldn't be doing. I am
not "lowering" the warning threshold, I am disabling an erroneously-conceived feature.
****

As for the extra code or the "useless" warnings, I suggest you bring
those questions to the Visual Studio product teams and explain it to
them. Maybe they can have it performing to your satisfaction by the
time they release VS 2015.
****
I doubt that. They make mistakes like this all the time and then declare them the
standards. Besides, since I can disable them, and it makes sense to disable them, they
don't need to do anything. What we need is something better than the gross /W3 and /W4
differences and a way of getting all the enable/disable settings as part of a build
profile that is ideal for whatever my project is.

[Footnote: my Ph.D. is in optimizing compiler technology. I did research in optimizing
compilers for many years, depending on metrics, somewhere between 5 and 10 years, and
worked in developing compilers and optimziation technology for a company that built
commercial optimizing compilers. I used highly-optimizing compilers from 1969 through
1984, went through a dismal set of years using the kind of crap that Unix users thought
was state-of-the-art (it was obsolete in 1970), and finally got to use the Microsoft
optimizing compilers, which on the whole are truly fine compilers, which is why the
double-instance code surprised me.

Newcomer, Joseph M. "Machine-Independent Generation of Optimal Local Code", Ph.D.
dissertation, Carnegie Mellon University, 1975. My advisor was William Wulf, one of the
world's experts on compiler optimization technology.

The basic principles of compiler optimization were laid out by about a dozen people over
the period of 1955-1985 and as far as I can tell, reading the literature, there have been
no new breakthroughs since the mid-eighties.]
joe
****
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: "Sorting" assignment
    ... too slow, other times for optimizing too much, some times for being too ... That is a rather bizarre, not-quite-C compiler, but ok. ... The overlap issue is a different problem, but performing a "swap" on ... CPU hardware feature differences that can be incredibly important to ...
    (comp.programming)
  • Re: Why INFINITE loop in a thread occupy so much CPU time??
    ... measuring code quality or program efficiency. ... You stated the K&R compiler did the silly thing of testing ... Now you want to make some kind of point about optimizing ...
    (microsoft.public.vc.mfc)
  • Re: Compiler code optimization: see code below
    ... >>I'm writing some C to be used in an embedded environment and the code ... I'm using GCC for the workstation and Diab compiler for the ... >>sure what exactly a good optimizing compiler can optimize away. ... > Neither optimization nor efficiency is defined by the C standard. ...
    (comp.lang.c)
  • Re: How about this syntactic candy?
    ... Unless the code in the loop is so simple that it is guaranteed that the list.Count property won't change during the execution of the loop, optimizing the expression to avoid reevaluating list.Count would be wrong. ... I once saw a demo of a for loop all compressed into one line with ingenious shortcuts and contractions, and after the optimising compiler had been through it, it generated EXACTLY the same machine code as an alternative loop written out in full. ... In that case, I could see the utility in providing the compiler with an explicit statement to that effect, but it seems to me that the current method required is so easy and simple, I can't imagine the point in adding something extra to the language to support the behavior. ...
    (microsoft.public.dotnet.languages.csharp)
  • amd64 bitops fix for -Os
    ... filesystem, the kernel mostly hangs. ... When optimizing for speed, the generated code is such that the flags ... Obviously the asm statement must not rely on the compiler setting up ... -inline long find_first_zero_bit(const unsigned long * addr, ...
    (Linux-Kernel)