2009-09-29 6 views
2

Je me demande ce qui se passe dans un programme qui a juste un while(1); dans la fonction main() lorsqu'il est compilé avec g ++ sur unix. Quand je cours le programme, je vois l'utilisation de cpu de 0%. Pourquoi est-ce? Ne devrait-il pas élever le cpu?unix processus infini

Le compilateur optimise-t-il cela? En mettant un appel système yield_processor comme ce contexte bascule?

Le code est compilé avec g ++ en utilisant l'optimisation par défaut (juste compilé comme g++ source.cpp)

int main() 
{ 
    while(1); 
} 

Merci à!

+0

Quel niveau d'optimisation utilisez-vous? ("-O", "-O2", "-O3"?) –

+0

Exemple de code postal avec des indicateurs de compilation. – Steven

+0

Comment mesurez-vous l'utilisation du processeur? – derobert

Répondre

1

Comme aucune dépendance n'est montrée dans le corps while(), gcc produit un trigraphe vide pour ce morceau de code. Maintenant, en fonction des indicateurs standard que vous utilisez (également, vérifiez les variables d'environnement CFLAGS et CXXFLAGS, si dans l'environnement * nix), le compilateur ne produit pas le code asm "hogging".

Vérifiez simplement après avoir fait g++ -S source.cpp le fichier source.s (contenant le code ASM) si la boucle a été produite ou non.

Voici mon résultat sans drapeaux d'optimisation de g ++ (GCC) 4.5.0 20.090.910 (expérimental):

.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 [email protected] 
    .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 

Ce code porcs mon CPU comme prévu (sur Mac OS X 10.6.1).

+0

semble que je reçois une boucle du compilateur à la fois O0 et O3. – rsinha

+0

publiez vos différences de fichier .s, principalement la section "label: jmp label" – ZZambia

0

Vous avez un bogue dans votre code, trop d'optimisation (peu probable), ou mal interprété votre utilisation du processeur.

Dans tous les cas, vous avez raison. Il devrait "monopoliser le processeur".

0

Il n'est pas strictement contre les règles pour votre compilateur de faire quelque chose d'intelligent avec ce code. Sous la règle «comme si», votre programme ne peut pas dire s'il tourne en boucle ou s'il dort. Je voudrais en savoir plus sur la version de GCC que vous utilisez et sur quel système d'exploitation. GCC-4 sur Mac OS X ne fait rien de spécial avec ce code.

Bien sûr, votre système d'exploitation peut avoir une limite définie pour l'utilisation du processeur par un processus. Je pense que le processus s'arrêterait dans ce cas, cependant.

+0

st = i486-linux-gnu --target = i486-linux-gnu gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) – rsinha