Ottimizzare un "while (1);" in C ++ 0x

Aggiornato, vedi sotto!

Ho sentito e letto che C ++ 0x consente a un compilatore di stampare "Hello" per il seguente frammento

#include <iostream>

int main() {
  while(1) 
    ;
  std::cout << "Hello" << std::endl;
}

Apparentemente ha qualcosa a che fare con i thread e le capacità di ottimizzazione. Mi sembra che questo possa sorprendere molte persone però.

Qualcuno ha una buona spiegazione del perché questo era necessario per consentire? Per riferimento, la più recente bozza C ++ 0x dice a6.5/5

Un ciclo che, al di fuori dell'istruzione for-init nel caso di un'istruzione for,

• non effettua chiamate alle funzioni I / O della libreria e
• non accede o modifica oggetti volatili e
• non esegue operazioni di sincronizzazione (1.10) o operazioni atomiche (clausola 29)

l'implementazione può essere considerata terminata. [Nota: questo ha lo scopo di consentire le trasformazioni del compilatore, come la rimozione di loop vuoti, anche quando non è possibile provare la terminazione. - nota finale]

Modificare:

Questo approfondito articolo parla del testo degli Standard

Sfortunatamente, le parole "comportamento indefinito" non vengono utilizzate. Tuttavia, ogni volta che lo standard dice "il compilatore può assumere P", è implicito che un programma che ha la proprietà non-P ha una semantica indefinita.

È corretto e al compilatore è permesso stampare "Bye" per il programma sopra?

C'è un thread ancora più penetrante qui , che riguarda un analogo cambiamento in C, iniziato dal Guy fatto l'articolo sopra riportato. Tra gli altri fatti utili, presentano una soluzione che sembra valere anche per C ++ 0x ( Aggiornamento : non funzionerà più con n3225 - vedi sotto!)

endless:
  goto endless;

A un compilatore non è permesso ottimizzarlo, a quanto pare, perché non è un loop, ma un salto. Un altro ragazzo riassume la modifica proposta in C ++ 0x e C201X

Scrivendo un ciclo, il programmatore sta affermando sia che l'anello fa qualcosa con comportamento visibile (esegue I / O, accessi oggetti volatili, o sincronizzazione esegue o operazioni atomiche), o che alla fine termina. Se viola tale presupposto scrivendo un ciclo infinito senza effetti collaterali, sto mentendo al compilatore e il comportamento del mio programma è indefinito. (Se sono fortunato, il compilatore potrebbe avvertirmi al riguardo.) Il linguaggio non fornisce (non fornisce più?) Un modo per esprimere un ciclo infinito senza comportamento visibile.

Aggiornamento del 3.1.2011 con n3225: la commissione sposta il testo all'1.10 / 24 e dice

L'implementazione può presumere che qualsiasi thread alla fine eseguirà una delle seguenti operazioni:

• terminare,
• effettuare una chiamata a una funzione I / O della libreria,
• accedere o modificare un oggetto volatile, o
• eseguire un'operazione di sincronizzazione o un'operazione atomica.

Il gototrucco non funzionerà più!

Qualcuno ha una buona spiegazione del perché questo era necessario per consentire?

Sì, Hans Boehm fornisce una logica per questo in N1528: Perché un comportamento indefinito per loop infiniti? , sebbene si tratti del documento WG14, la logica si applica anche al C ++ e il documento fa riferimento sia al WG14 che al WG21:

Come indica correttamente N1509, l'attuale bozza fornisce essenzialmente un comportamento indefinito a cicli infiniti in 6.8.5p6. Un grosso problema per farlo è che consente al codice di spostarsi attraverso un ciclo potenzialmente non terminante. Ad esempio, supponiamo di avere i seguenti loop, dove count e count2 sono variabili globali (o hanno avuto il loro indirizzo preso), e p è una variabile locale, il cui indirizzo non è stato preso:

for (p = q; p != 0; p = p -> next) {
    ++count;
}
for (p = q; p != 0; p = p -> next) {
    ++count2;
}

Questi due loop potrebbero essere uniti e sostituiti dal seguente loop?

for (p = q; p != 0; p = p -> next) {
        ++count;
        ++count2;
}

Senza la dispensa speciale in 6.8.5p6 per loop infiniti, questo non sarebbe consentito: se il primo loop non termina perché q punta a un elenco circolare, l'originale non scrive mai su count2. Quindi potrebbe essere eseguito in parallelo con un altro thread che accede o aggiorna count2. Questo non è più sicuro con la versione trasformata che accede a count2 nonostante il ciclo infinito. Pertanto la trasformazione potenzialmente introduce una corsa ai dati.

In casi come questo, è molto improbabile che un compilatore sia in grado di provare la terminazione del loop; dovrebbe capire che q indica un elenco aciclico, che credo sia al di là delle capacità della maggior parte dei compilatori tradizionali e spesso impossibile senza le informazioni complete del programma.

Le restrizioni imposte dai loop non terminanti sono una restrizione all'ottimizzazione dei loop terminanti per i quali il compilatore non può provare la terminazione, nonché all'ottimizzazione dei loop effettivamente non terminanti. I primi sono molto più comuni dei secondi e spesso più interessanti da ottimizzare.

Esistono chiaramente anche for-loop con una variabile di ciclo intero in cui sarebbe difficile per un compilatore provare la terminazione, e quindi sarebbe difficile per il compilatore ristrutturare i loop senza 6.8.5p6. Anche qualcosa del genere

for (i = 1; i != 15; i += 2)

o

for (i = 1; i <= 10; i += j)

sembra non banale da gestire. (Nel primo caso, è necessaria una teoria dei numeri di base per dimostrare la terminazione, nel secondo caso, dobbiamo sapere qualcosa sui possibili valori di j per farlo. L'avvolgimento per interi senza segno può complicare ulteriormente alcuni di questi ragionamenti. )

Questo problema sembra applicarsi a quasi tutte le trasformazioni di ristrutturazione del ciclo, inclusa la parallelizzazione del compilatore e le trasformazioni di ottimizzazione della cache, entrambe le quali probabilmente acquisiranno importanza e sono già spesso importanti per il codice numerico. Ciò sembra probabilmente trasformarsi in un costo sostanziale a vantaggio della possibilità di scrivere loop infiniti nel modo più naturale possibile, soprattutto perché la maggior parte di noi raramente scrive loop intenzionalmente infiniti.

La principale differenza con C è che C11 fornisce un'eccezione per il controllo di espressioni che sono espressioni costanti che differiscono da C ++ e rendono il tuo esempio specifico ben definito in C11.

Per me, la giustificazione pertinente è:

Ciò ha lo scopo di consentire le trasformazioni del compilatore, come la rimozione di loop vuoti, anche quando non è possibile provare la terminazione.

Presumibilmente, ciò è dovuto al fatto che provare la terminazione meccanicamente è difficile e l'incapacità di provare la terminazione ostacola i compilatori che potrebbero altrimenti apportare trasformazioni utili, come spostare operazioni non dipendenti da prima del ciclo a dopo o viceversa, eseguendo operazioni post-ciclo in un thread mentre il ciclo viene eseguito in un altro e così via. Senza queste trasformazioni, un loop potrebbe bloccare tutti gli altri thread mentre attendono che un thread termini il loop stesso. (Uso vagamente "thread" per indicare qualsiasi forma di elaborazione parallela, inclusi flussi di istruzioni VLIW separati.)

EDIT: esempio stupido:

while (complicated_condition()) {
    x = complicated_but_externally_invisible_operation(x);
}
complex_io_operation();
cout << "Results:" << endl;
cout << x << endl;

Qui, sarebbe più veloce per un thread fare l'altro complex_io_operationmentre l'altro sta facendo tutti i calcoli complessi nel ciclo. Ma senza la clausola che hai citato, il compilatore deve provare due cose prima di poter effettuare l'ottimizzazione: 1) che complex_io_operation()non dipende dai risultati del ciclo e 2) che il ciclo terminerà . Provare 1) è abbastanza facile, dimostrando 2) è il problema di arresto. Con la clausola, si può presumere che il loop termina e ottenere una vincita di parallelizzazione.

Immagino anche che i progettisti abbiano considerato che i casi in cui si verificano cicli infiniti nel codice di produzione sono molto rari e di solito sono cose come i cicli guidati da eventi che accedono all'I / O in qualche modo. Di conseguenza, hanno pessimizzato il caso raro (loop infiniti) a favore dell'ottimizzazione del caso più comune (loop non infiniti, ma difficili da provare meccanicamente non infiniti).

Ciò significa, tuttavia, che i loop infiniti utilizzati negli esempi di apprendimento ne risentiranno e aumenteranno i gotcha nel codice per principianti. Non posso dire che sia del tutto una buona cosa.

EDIT: rispetto all'articolo approfondito che ora colleghi, direi che "il compilatore può supporre X sul programma" è logicamente equivalente a "se il programma non soddisfa X, il comportamento non è definito". Possiamo mostrarlo come segue: supponiamo che esista un programma che non soddisfa la proprietà X. Dove sarebbe definito il comportamento di questo programma? Lo standard definisce solo il comportamento presupponendo che la proprietà X sia vera. Sebbene lo standard non dichiari esplicitamente indefinito il comportamento, lo ha dichiarato non definito per omissione.

Considera un argomento simile: "il compilatore può presumere che una variabile x sia assegnata al massimo una sola volta tra punti di sequenza" equivale a "assegnare a x più di una volta tra punti sequenza non è definito".

Penso che l'interpretazione corretta sia quella della tua modifica: i loop infiniti vuoti sono comportamenti indefiniti.

Non direi che è un comportamento particolarmente intuitivo, ma questa interpretazione ha più senso di quella alternativa, secondo cui al compilatore è arbitrariamente permesso di ignorare infiniti loop senza invocare UB.

Se i loop infiniti sono UB, significa solo che i programmi non terminanti non sono considerati significativi: secondo C ++ 0x, non hanno semantica.

Anche questo ha un certo senso. Sono un caso speciale, in cui un certo numero di effetti collaterali non si verificano più (ad esempio, non viene mai restituito nulla main) e un certo numero di ottimizzazioni del compilatore sono ostacolate dalla necessità di conservare loop infiniti. Ad esempio, lo spostamento dei calcoli attraverso il loop è perfettamente valido se il loop non ha effetti collaterali, poiché alla fine il calcolo verrà eseguito in ogni caso. Ma se il ciclo non termina mai, non possiamo riorganizzare in modo sicuro il codice attraverso di esso, perché potremmo semplicemente cambiare quali operazioni vengono effettivamente eseguite prima che il programma si blocchi. A meno che non trattiamo un programma sospeso come UB, cioè.

Penso che questo sia in linea con questo tipo di domanda , che fa riferimento a un altro thread . L'ottimizzazione può occasionalmente rimuovere i loop vuoti.

Il problema rilevante è che al compilatore è consentito riordinare il codice i cui effetti collaterali non sono in conflitto. Il sorprendente ordine di esecuzione potrebbe verificarsi anche se il compilatore generasse un codice macchina non terminante per il ciclo infinito.

Credo che questo sia l'approccio giusto. Le specifiche del linguaggio definiscono i modi per far rispettare l'ordine di esecuzione. Se vuoi un loop infinito che non può essere riordinato, scrivi questo:

volatile int dummy_side_effect;

while (1) {
    dummy_side_effect = 0;
}

printf("Never prints.\n");

Penso che il problema potrebbe forse essere meglio indicato, in quanto "Se un pezzo di codice successivo non dipende da un pezzo di codice precedente e il pezzo di codice precedente non ha effetti collaterali su nessun'altra parte del sistema, l'output del compilatore può eseguire il pezzo di codice successivo prima, dopo, o mescolato, l'esecuzione del primo, anche se il primo contiene loop, indipendentemente da quando o se il codice precedente sarebbe effettivamente completo . Ad esempio, il compilatore potrebbe riscrivere:

void testfermat (int n)
{
  int a = 1, b = 1, c = 1;
  while (pow (a, n) + pow (b, n)! = pow (c, n))
  {
    se (b> a) a ++; altrimenti if (c> b) {a = 1; b ++}; altrimenti {a = 1; b = 1; c ++};
  }
  printf ("Il risultato è");
  printf ("% d /% d /% d", a, b, c);
}

come

void testfermat (int n)
{
  if (fork_is_first_thread ())
  {
    int a = 1, b = 1, c = 1;
    while (pow (a, n) + pow (b, n)! = pow (c, n))
    {
      se (b> a) a ++; altrimenti if (c> b) {a = 1; b ++}; altrimenti {a = 1; b = 1; c ++};
    }
    signal_other_thread_and_die ();
  }
  else // Secondo thread
  {
    printf ("Il risultato è");
    wait_for_other_thread ();
  }
  printf ("% d /% d /% d", a, b, c);
}

Generalmente non irragionevole, anche se potrei preoccuparmi che:

  int total = 0;
  per (i = 0; num_reps> i; i ++)
  {
    update_progress_bar (i);
    totale + = do_something_slow_with_no_side_effects (i);
  }
  show_result (totale);

potrebbe diventare

  int total = 0;
  if (fork_is_first_thread ())
  {
    per (i = 0; num_reps> i; i ++)
      totale + = do_something_slow_with_no_side_effects (i);
    signal_other_thread_and_die ();
  }
  altro
  {
    per (i = 0; num_reps> i; i ++)
      update_progress_bar (i);
    wait_for_other_thread ();
  }
  show_result (totale);

Avendo una CPU che gestisce i calcoli e un'altra che gestisce gli aggiornamenti della barra di avanzamento, la riscrittura migliorerebbe l'efficienza. Sfortunatamente, gli aggiornamenti della barra di avanzamento sarebbero meno utili di quanto dovrebbero essere.

Non è decidibile per il compilatore per casi non banali se si tratta di un loop infinito.

In diversi casi, può capitare che il tuo ottimizzatore raggiunga una classe di complessità migliore per il tuo codice (es. Era O (n ^ 2) e ottieni O (n) o O (1) dopo l'ottimizzazione).

Quindi, includere una regola del genere che non consente di rimuovere un ciclo infinito nello standard C ++ renderebbe impossibili molte ottimizzazioni. E molte persone non lo vogliono. Penso che questo risponda abbastanza alla tua domanda.

Un'altra cosa: non ho mai visto alcun esempio valido in cui hai bisogno di un ciclo infinito che non fa nulla.

L'unico esempio di cui ho sentito parlare è stato un brutto hack che avrebbe dovuto essere risolto altrimenti: si trattava di sistemi embedded in cui l'unico modo per attivare un ripristino era congelare il dispositivo in modo che il watchdog lo riavviesse automaticamente.

Se conosci qualche esempio valido / valido in cui hai bisogno di un ciclo infinito che non fa nulla, per favore dimmelo.

Penso che valga la pena sottolineare che i loop che sarebbero infiniti, tranne per il fatto che interagiscono con altri thread tramite variabili non volatili e non sincronizzate, possono ora produrre un comportamento errato con un nuovo compilatore.

In altre parole, rendo volatili i tuoi globi - così come gli argomenti passati in un tale ciclo tramite puntatore / riferimento.