tags:

views:

120

answers:

3

Hi,

I am wondering what happens in a program that just has a while(1); in the main() function when compiled with g++ on unix. When I run the program, I am seeing 0% cpu usage. Why is this? Shouldn't it hog up the cpu?

Is the compiler optimizing this somehow? By putting a yield_processor like system call that context switches out?

The code is compiled with g++ using default optimization (just compiled as g++ source.cpp)

int main()
{
  while(1);
}

Thanks!

A: 

You either have a bug in your code, too much optimization (not likely), or are misreading your cpu usage.

In any case, you are right. It should "hog up the cpu."

Steven
A: 

It's not strictly against the rules for your compiler to do something clever with this code. Under the "as if" rule, there's no way for your program to tell if it's actually spinning in a loop, or just sleeping.

I'd like to hear more about what version of GCC you're running, and on what OS. GCC-4 on Mac OS X doesn't do anything special with this code.

Of course, your OS might have a limit set for CPU usage by one process. I think the process would stop in that case, though.

Mark Bessey
st=i486-linux-gnu --target=i486-linux-gnugcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)
rsinha
+1  A: 

As no dependecies are shown in the while() body, gcc produces an empty trigraph for this piece of code. Now, depending on standard flags you're actually using (also, check env. variables CFLAGS and CXXFLAGS, if in *nix environment), the compiler doesn't produce the asm "hogging" code.

Just check after doing g++ -S source.cpp the source.s file (containing ASM code) if the loop has been produced or not.

Here's my output with no optimization flags by g++ (GCC) 4.5.0 20090910 (experimental):

    .text
.globl _main
_main:
LFB0:
    pushq %rbp
LCFI0:
    movq %rsp, %rbp
LCFI1:
L2:
    jmp L2
LFE0:
    .section __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
EH_frame1:
    .set L$set$0,LECIE1-LSCIE1
    .long L$set$0
LSCIE1:
    .long 0x0
    .byte 0x1
    .ascii "zPR\0"
    .byte 0x1
    .byte 0x78
    .byte 0x10
    .byte 0x6
    .byte 0x9b
    .long ___gxx_personality_v0+4@GOTPCREL
    .byte 0x10
    .byte 0xc
    .byte 0x7
    .byte 0x8
    .byte 0x90
    .byte 0x1
    .align 3
LECIE1:
.globl _main.eh
_main.eh:
LSFDE1:
    .set L$set$1,LEFDE1-LASFDE1
    .long L$set$1
LASFDE1:
    .long LASFDE1-EH_frame1
    .quad LFB0-.
    .set L$set$2,LFE0-LFB0
    .quad L$set$2
    .byte 0x0
    .byte 0x4
    .set L$set$3,LCFI0-LFB0
    .long L$set$3
    .byte 0xe
    .byte 0x10
    .byte 0x86
    .byte 0x2
    .byte 0x4
    .set L$set$4,LCFI1-LCFI0
    .long L$set$4
    .byte 0xd
    .byte 0x6
    .align 3
LEFDE1:
    .constructor
    .destructor
    .align 1
    .subsections_via_symbols

This code hogs my CPU as expected (on Mac OSX 10.6.1).

ZZambia
looks like i am getting a loop from the compiler at both O0 and O3.
rsinha
post your .s file differences, mostly the "label: jmp label" section
ZZambia