Vale la pena valutare l'ottimizzazione del compilatore in casi banali?

2

Attualmente sto testando Visual C ++ 10 su alcuni piccoli pezzi di codice. Ad esempio, come questo (preso da qui ):

int main()
{
    int i;
    clrscr();
    for(i=0,i++,i<=5;i++,i<=2;i=0,i<=5,i+=3){
        printf("%d ",i);
    }
    return 0;
}

Per il codice sopra il compilatore emette il codice macchina che in effetti fa questo:

clrscr();
printf("%d ",2);
return 0;

e questo mi rende felice. A volte il compilatore emette un codice veramente stupido e quindi registro un elemento di feedback di Microsoft Connect.

Ho la seguente preoccupazione. Vale la pena testare un compilatore su un codice banale?

Da un lato, vogliamo che il codice reale sia compilato nel miglior modo possibile, non alcuni stupidi frammenti di esempio.

D'altra parte, l'ottimizzazione del compilatore è ricorsiva nel senso che se il codice B segue il codice A e il compilatore può vedere che il codice B non fa nulla può eliminare il codice B ed eliminare qualsiasi cosa collegata A e B logicamente e quindi ottimizzare (e forse eliminare) codice A migliore. E se il compilatore non riesce a ottimizzare il codice B, probabilmente non sarà in grado di ottimizzare il codice A. Quindi ogni miglioramento del codice generato è importante - un codice migliore a un certo punto può significare un codice migliore altrove e questo è vantaggioso.

Vale la pena testare i compilatori su campioni banali o sono degni solo i test sul "codice reale"?

    
posta sharptooth 14.09.2011 - 15:27
fonte

3 risposte

2

Le ottimizzazioni di cui hai bisogno un compilatore sono per i tipi di codice che in pratica richiedono del tempo. Quindi è una perdita di tempo cercare di trovare casi poco strani che fa o non fa.

In effetti, in alcuni tipi di applicazioni, le ottimizzazioni del compilatore non fanno alcuna differenza, come quasi tutte le app di Windows. Se si prelevano campioni di stack di tale app, come faccio regolarmente, in quasi ogni istante casuale di tempo lo stack delle chiamate ha una profondità di almeno diversi livelli. Il suggerimento dello stack è in alcune chiamate di sistema bloccate, o nell'esecuzione di istruzioni da qualche parte nel sottos piano di una libreria di sistema.

In altre parole, in questo tipo di app, è quasi impossibile catturare l'IP nel codice compilato dal compilatore, e questa è l'unica volta in cui la spremitura del ciclo potrebbe avere importanza.

AGGIUNTO: non fraintendermi. Queste app possono certamente essere ottimizzate. È solo che non puoi aspettarti che il compilatore lo faccia. Questo è il metodo che uso.

    
risposta data 14.09.2011 - 20:47
fonte
9

Is it worth testing compilers on trivial samples

No.

or are only tests on "real code" worthy?

A mala pena. Questo è soprattutto uno spreco di tempo, anche.

Prima di perdere tempo nell'ottimizzazione del compilatore, devi rispondere a tre domande.

  1. Funziona davvero?

  2. È l'algoritmo e la struttura dati corretti?

  3. Esiste un effettivo problema di prestazioni che è necessario risolvere?

"we want real code to be compiled as good as possible"

Questo non è un buon obiettivo. Devi avere una linea guida specifica sul rendimento e devi smettere di sprecare il tuo tempo per ottimizzare quando raggiungi questo obiettivo. "il migliore possibile" è troppo vago.

    
risposta data 14.09.2011 - 15:33
fonte
2

Penso che sia molto probabilmente una perdita di tempo. Peggio ancora, potrebbe deviare le risorse dall'individuare problemi che potrebbero influenzare il codice reale. Se questo accade per colpire un problema che conta davvero, sarà solo per fortuna. Sei molto più propenso a colpire il bersaglio se lo miri.

    
risposta data 14.09.2011 - 15:58
fonte

Leggi altre domande sui tag