La variabile locale non inizializzata è il generatore di numeri casuali più veloce?

So che la variabile locale non inizializzata è un comportamento indefinito ( UB ), e anche il valore può avere rappresentazioni di trap che possono influire su ulteriori operazioni, ma a volte voglio usare il numero casuale solo per la rappresentazione visiva e non le userò ulteriormente in altre parti di programma, ad esempio, imposta qualcosa con un colore casuale in un effetto visivo, ad esempio:

void updateEffect(){
    for(int i=0;i<1000;i++){
        int r;
        int g;
        int b;
        star[i].setColor(r%255,g%255,b%255);
        bool isVisible;
        star[i].setVisible(isVisible);
    }
}

è più veloce di

void updateEffect(){
    for(int i=0;i<1000;i++){
        star[i].setColor(rand()%255,rand()%255,rand()%255);
        star[i].setVisible(rand()%2==0?true:false);
    }
}

e anche più veloce di altri generatori di numeri casuali?

Come altri hanno notato, questo è Undefined Behaviour (UB).

In pratica, funzionerà (probabilmente) effettivamente (in qualche modo). La lettura da un registro non inizializzato su architetture x86 [-64] produrrà effettivamente risultati spazzatura e probabilmente non farà nulla di male (al contrario di Itanium, dove i registri possono essere contrassegnati come non validi , in modo che le letture propagano errori come NaN).

Vi sono tuttavia due problemi principali:

1. Non sarà particolarmente casuale. In questo caso, stai leggendo dallo stack, quindi otterrai tutto ciò che c'era in precedenza. Che potrebbe essere effettivamente casuale, completamente strutturato, la password che hai inserito dieci minuti fa o la ricetta dei biscotti di tua nonna.

2. È una cattiva (maiuscola 'B') lasciare che cose del genere si insinuino nel tuo codice. Tecnicamente, il compilatore potrebbe inserire reformat_hdd();ogni volta che leggi una variabile non definita. Non lo farà , ma non dovresti farlo comunque. Non fare cose pericolose. Meno eccezioni fai, più sarai sicuro di errori accidentali in ogni momento.

Il problema più urgente con UB è che rende indefinito il comportamento dell'intero programma. I compilatori moderni possono usarlo per eludere enormi parti del codice o persino per tornare indietro nel tempo . Giocare con UB è come un ingegnere vittoriano che smantella un reattore nucleare in tensione. Ci sono milioni di cose che vanno male e probabilmente non conoscerai la metà dei principi sottostanti o della tecnologia implementata. Si potrebbe andare bene, ma ancora non dovrebbe lasciare che accada. Guarda le altre belle risposte per i dettagli.

Inoltre, ti licenzierei.

Lasciatemelo dire chiaramente: non invochiamo comportamenti indefiniti nei nostri programmi . Non è mai una buona idea, punto. Ci sono rare eccezioni a questa regola; ad esempio, se sei un implementatore di librerie che implementa offsetof . Se il tuo caso rientra in tale eccezione, probabilmente lo sai già. In questo caso sappiamo che l'utilizzo di variabili automatiche non inizializzate è un comportamento indefinito .

I compilatori sono diventati molto aggressivi con l'ottimizzazione del comportamento indefinito e possiamo trovare molti casi in cui il comportamento indefinito ha portato a difetti di sicurezza. Il caso più infame è probabilmente la rimozione del controllo del puntatore null del kernel Linux che menziono nella mia risposta al bug di compilazione C ++? dove un'ottimizzazione del compilatore attorno a comportamenti indefiniti trasformava un ciclo finito in uno infinito.

Possiamo leggere le Ottimizzazioni pericolose di CERT e la perdita di causalità ( video ) che dice, tra le altre cose:

Sempre più spesso, gli autori di compilatori stanno sfruttando comportamenti indefiniti nei linguaggi di programmazione C e C ++ per migliorare le ottimizzazioni.

Spesso, queste ottimizzazioni interferiscono con la capacità degli sviluppatori di eseguire analisi di causa-effetto sul loro codice sorgente, ovvero analizzare la dipendenza dei risultati a valle dai risultati precedenti.

Di conseguenza, queste ottimizzazioni stanno eliminando la causalità nel software e stanno aumentando la probabilità di guasti, difetti e vulnerabilità del software.

In particolare per quanto riguarda i valori indeterminati, il rapporto sui difetti standard C 451: instabilità di variabili automatiche non inizializzate rende alcune letture interessanti. Non è stato ancora risolto, ma introduce il concetto di valori traballanti, il che significa che l'indeterminatezza di un valore può propagarsi attraverso il programma e può avere diversi valori indeterminati in diversi punti del programma.

Non conosco esempi in cui ciò accada, ma a questo punto non possiamo escluderlo.

Esempi reali, non il risultato che ti aspetti

È improbabile che tu ottenga valori casuali. Un compilatore potrebbe ottimizzare del tutto il loop. Ad esempio, con questo caso semplificato:

void updateEffect(int  arr[20]){
    for(int i=0;i<20;i++){
        int r ;    
        arr[i] = r ;
    }
}

clang lo ottimizza via ( vederlo dal vivo ):

updateEffect(int*):                     # @updateEffect(int*)
    retq

o forse ottenere tutti gli zeri, come in questo caso modificato:

void updateEffect(int  arr[20]){
    for(int i=0;i<20;i++){
        int r ;    
        arr[i] = r%255 ;
    }
}

vederlo dal vivo :

updateEffect(int*):                     # @updateEffect(int*)
    xorps   %xmm0, %xmm0
    movups  %xmm0, 64(%rdi)
    movups  %xmm0, 48(%rdi)
    movups  %xmm0, 32(%rdi)
    movups  %xmm0, 16(%rdi)
    movups  %xmm0, (%rdi)
    retq

Entrambi questi casi sono forme perfettamente accettabili di comportamento indefinito.

Nota, se siamo su un Itanium potremmo finire con un valore trap :

[...] se il registro contiene uno speciale valore non-cosa-cosa, leggendo le trap del registro tranne alcune istruzioni [...]

Altre note importanti

È interessante notare la varianza tra gcc e clang osservata nel progetto UB Canaries su quanto siano disposti a trarre vantaggio da un comportamento indefinito rispetto alla memoria non inizializzata. L'articolo osserva ( enfasi il mio ):

Ovviamente dobbiamo essere completamente chiari con noi stessi sul fatto che una simile aspettativa non ha nulla a che fare con lo standard linguistico e tutto ciò che ha a che fare con un determinato compilatore, sia perché i provider di quel compilatore non sono disposti a sfruttare quell'UB o semplicemente perché non sono ancora riusciti a sfruttarlo . Quando non esiste alcuna garanzia reale da parte del fornitore del compilatore, ci piace dire che gli UB non ancora sfruttati sono bombe a orologeria : stanno aspettando di esplodere il mese prossimo o l'anno prossimo quando il compilatore diventerà un po 'più aggressivo.

Come sottolinea Matthieu M., ciò che ogni programmatore C dovrebbe sapere sul comportamento indefinito n. 2/3 è rilevante anche per questa domanda. Dice tra l'altro ( enfasi la mia ):

La cosa importante e spaventoso da capire è che quasi ogni ottimizzazione basata sul comportamento indefinito può iniziare l'attivazione, sul codice buggy in qualsiasi momento in futuro . Inline, srotolamento continuo, promozione della memoria e altre ottimizzazioni continueranno a migliorare, e una parte significativa della loro ragione di esistere è esporre ottimizzazioni secondarie come quelle sopra.

Per me questo è profondamente insoddisfacente, in parte perché il compilatore finisce inevitabilmente per essere incolpato, ma anche perché significa che enormi corpi di codice C sono mine di terra che aspettano solo di esplodere.

Per completezza, dovrei probabilmente menzionare che le implementazioni possono scegliere di rendere ben definito il comportamento indefinito, ad esempio gcc consente la punzonatura del tipo attraverso i sindacati mentre in C ++ sembra un comportamento indefinito . In tal caso, l'implementazione dovrebbe documentarlo e questo di solito non sarà portatile.

No, è terribile.

Il comportamento dell'uso di una variabile non inizializzata non è definito in C e C ++ ed è molto improbabile che un tale schema abbia proprietà statistiche desiderabili.

Se vuoi un generatore di numeri casuali "veloce e sporco", allora rand()è la soluzione migliore. Nella sua implementazione, tutto ciò che fa è una moltiplicazione, un'aggiunta e un modulo.

Il generatore più veloce che conosco richiede di utilizzare a uint32_tcome tipo di variabile pseudo-casuale Ie utilizzare

I = 1664525 * I + 1013904223

per generare valori successivi. Puoi scegliere qualsiasi valore iniziale di I(chiamato seme ) che ti piace. Ovviamente puoi codificarlo in linea. Il wraparound standard garantito di un tipo senza segno funge da modulo. (Le costanti numeriche sono raccolte a mano da quel notevole programmatore scientifico Donald Knuth.)

Buona domanda!

Non definito non significa che sia casuale. Pensaci, i valori che otterrai nelle variabili globali non inizializzate sarebbero stati lasciati lì dal sistema o dalle tue / altre applicazioni in esecuzione. A seconda di ciò che il sistema fa con la memoria non più utilizzata e / o del tipo di valori generati dal sistema e dalle applicazioni, è possibile ottenere:

1. Sempre la stessa.
2. Essere uno di un piccolo insieme di valori.
3. Ottieni valori in uno o più intervalli piccoli.
4. Vedi molti valori divisibili per 2/4/8 dai puntatori sul sistema 16/32/64 bit
5. ...

I valori che otterrai dipenderanno completamente dai valori non casuali lasciati dal sistema e / o dalle applicazioni. Quindi, in effetti ci sarà un po 'di rumore (a meno che il tuo sistema non cancelli più la memoria), ma il pool di valori da cui attingerai non sarà affatto casuale.

Le cose peggiorano molto per le variabili locali perché provengono direttamente dallo stack del tuo programma. È molto probabile che il programma scriva effettivamente queste posizioni dello stack durante l'esecuzione di altro codice. Stimo le possibilità di fortuna in questa situazione molto bassa e un cambio di codice "casuale" che fai prova questa fortuna.

Leggi di casualità . Come vedrai la casualità è una proprietà molto specifica e difficile da ottenere. È un errore comune pensare che se prendi qualcosa che è difficile da tracciare (come il tuo suggerimento) otterrai un valore casuale.

Molte buone risposte, ma mi permettono di aggiungere un altro e sottolineare il fatto che in un computer deterministico, nulla è casuale. Questo vale sia per i numeri prodotti da uno pseudo-RNG che per i numeri apparentemente "casuali" trovati in aree di memoria riservate alle variabili locali C / C ++ nello stack.

MA ... c'è una differenza cruciale.

I numeri generati da un buon generatore pseudocasuale hanno le proprietà che li rendono statisticamente simili ai disegni veramente casuali. Ad esempio, la distribuzione è uniforme. La durata del ciclo è lunga: puoi ottenere milioni di numeri casuali prima che il ciclo si ripeta. La sequenza non è correlata automaticamente: per esempio, non inizierai a vedere emergere strani schemi se prendi ogni 2 °, 3 ° o 27 ° numero o se guardi cifre specifiche nei numeri generati.

Al contrario, i numeri "casuali" lasciati nello stack non hanno nessuna di queste proprietà. I loro valori e la loro apparente casualità dipendono interamente da come viene costruito il programma, da come viene compilato e da come viene ottimizzato dal compilatore. A titolo di esempio, ecco una variante della tua idea come programma autonomo:

#include <stdio.h>

notrandom()
{
        int r, g, b;

        printf("R=%d, G=%d, B=%d", r&255, g&255, b&255);
}

int main(int argc, char *argv[])
{
        int i;
        for (i = 0; i < 10; i++)
        {
                notrandom();
                printf("\n");
        }

        return 0;
}

Quando compilo questo codice con GCC su una macchina Linux ed eseguo, risulta essere deterministico piuttosto spiacevole:

R=0, G=19, B=0
R=130, G=16, B=255
R=130, G=16, B=255
R=130, G=16, B=255
R=130, G=16, B=255
R=130, G=16, B=255
R=130, G=16, B=255
R=130, G=16, B=255
R=130, G=16, B=255
R=130, G=16, B=255

Se guardassi il codice compilato con un disassemblatore, potresti ricostruire in dettaglio ciò che stava succedendo. La prima chiamata a notrandom () utilizzava un'area dello stack che non era stata precedentemente utilizzata da questo programma; chissà cosa c'era dentro. Ma dopo quella chiamata a notrandom (), c'è una chiamata a printf () (che il compilatore GCC effettivamente ottimizza su una chiamata a putchar (), ma non importa) e che sovrascrive lo stack. Quindi, le volte successiva e successiva, quando viene chiamato notrandom (), lo stack conterrà dati non aggiornati dall'esecuzione di putchar () e poiché putchar () viene sempre chiamato con gli stessi argomenti, questi dati non aggiornati saranno sempre gli stessi, pure.

Quindi non c'è assolutamente nulla di casuale in questo comportamento, né i numeri ottenuti in questo modo hanno le proprietà desiderabili di un generatore di numeri pseudocasuali ben scritto. In effetti, nella maggior parte degli scenari della vita reale, i loro valori saranno ripetitivi e altamente correlati.

In effetti, come altri, prenderei seriamente in considerazione l'idea di licenziare qualcuno che ha cercato di far passare questa idea come un "RNG ad alte prestazioni".

Comportamento indefinito significa che gli autori di compilatori sono liberi di ignorare il problema perché i programmatori non avranno mai il diritto di lamentarsi di ciò che accade.

Mentre in teoria quando si entra in UB land tutto può succedere (incluso un demone che vola via dal naso ) ciò che normalmente significa è che gli autori del compilatore non se ne cureranno e, per le variabili locali, il valore sarà qualunque cosa sia nella memoria dello stack in quel punto .

Ciò significa anche che spesso il contenuto sarà "strano" ma fisso o leggermente casuale o variabile ma con un chiaro schema evidente (ad esempio valori crescenti ad ogni iterazione).

Di sicuro non puoi aspettarti che sia un generatore casuale decente.

Il comportamento indefinito non è definito. Ciò non significa che ottieni un valore indefinito, significa che il programma può fare qualsiasi cosa e comunque soddisfare le specifiche del linguaggio.

Un buon compilatore di ottimizzazione dovrebbe richiedere

void updateEffect(){
    for(int i=0;i<1000;i++){
        int r;
        int g;
        int b;
        star[i].setColor(r%255,g%255,b%255);
        bool isVisible;
        star[i].setVisible(isVisible);
    }
}

e compilarlo in un noop. Questo è sicuramente più veloce di qualsiasi alternativa. Ha il lato negativo che non farà nulla, ma tale è il lato negativo di un comportamento indefinito.

Non ancora menzionato, ma i percorsi di codice che invocano comportamenti indefiniti sono autorizzati a fare qualsiasi cosa voglia il compilatore, ad es

void updateEffect(){}

Che è certamente più veloce del tuo loop corretto, e grazie a UB, è perfettamente conforme.

Per motivi di sicurezza, è necessario pulire la nuova memoria assegnata a un programma, altrimenti le informazioni potrebbero essere utilizzate e le password potrebbero passare da un'applicazione all'altra. Solo quando si riutilizza la memoria, si ottengono valori diversi da 0. Ed è molto probabile che su uno stack il valore precedente sia appena corretto, poiché è stato riparato l'uso precedente di quella memoria.

Il tuo particolare esempio di codice probabilmente non farebbe ciò che ti aspetti. Mentre tecnicamente ogni iterazione del ciclo ricrea le variabili locali per i valori r, g e b, in pratica è lo stesso spazio di memoria nello stack. Quindi non verrà randomizzato ad ogni iterazione e finirai per assegnare gli stessi 3 valori per ciascuno dei 1000 colori, indipendentemente da quanto casuali siano r, g e b individualmente e inizialmente.

In effetti, se funzionasse, sarei molto curioso di sapere cosa lo sta ri-randomizzando. L'unica cosa che mi viene in mente sarebbe un interrupt intercalato che era impacchettato in cima a quella pila, altamente improbabile. Forse l'ottimizzazione interna che manteneva quelle come variabili di registro piuttosto che come posizioni di memoria reali, in cui i registri vengono riutilizzati più in basso nel ciclo, farebbe anche il trucco, specialmente se la funzione di visibilità impostata è particolarmente affamata di registro. Comunque, tutt'altro che casuale.

Come la maggior parte delle persone qui ha menzionato un comportamento indefinito. Undefined significa anche che potresti ottenere un valore intero valido (per fortuna) e in questo caso sarà più veloce (poiché la chiamata alla funzione rand non viene effettuata). Ma non usarlo praticamente. Sono sicuro che questo avrà risultati terribili poiché la fortuna non è sempre con te.

Veramente male! Cattiva abitudine, cattivo risultato. Tener conto di:

A_Function_that_use_a_lot_the_Stack();
updateEffect();

Se la funzione A_Function_that_use_a_lot_the_Stack()effettua sempre la stessa inizializzazione, lascia lo stack con gli stessi dati. Questi dati sono ciò che chiamiamo updateEffect(): sempre lo stesso valore! .

Ho eseguito un test molto semplice e non è stato affatto casuale.

#include <stdio.h>

int main() {

    int a;
    printf("%d\n", a);
    return 0;
}

Ogni volta che ho eseguito il programma, ha stampato lo stesso numero ( 32767nel mio caso) - non puoi essere molto meno casuale di così. Questo è presumibilmente qualunque sia il codice di avvio nella libreria di runtime lasciato nello stack. Poiché utilizza lo stesso codice di avvio ogni volta che il programma viene eseguito e nient'altro varia nel programma tra le esecuzioni, i risultati sono perfettamente coerenti.

Devi avere una definizione di cosa intendi per "casuale". Una definizione ragionevole implica che i valori ottenuti dovrebbero avere poca correlazione. È qualcosa che puoi misurare. Inoltre, non è banale da ottenere in modo controllato e riproducibile. Quindi un comportamento indefinito non è certamente quello che stai cercando.

Ci sono alcune situazioni in cui la memoria non inizializzata può essere letta in modo sicuro usando il tipo "unsigned char *" [es. Un buffer restituito da malloc]. Il codice può leggere tale memoria senza doversi preoccupare del compilatore che lancia la causalità fuori dalla finestra e ci sono momenti in cui può essere più efficiente avere il codice preparato per tutto ciò che la memoria potrebbe contenere rispetto a garantire che i dati non inizializzati non vengano letti ( un esempio comune di questo sarebbe usarememcpy su buffer parzialmente inizializzato piuttosto che copiare discretamente tutti gli elementi che contengono dati significativi).

Anche in questi casi, tuttavia, si dovrebbe sempre supporre che se una qualsiasi combinazione di byte sarà particolarmente vessatoria, la lettura produrrà sempre quel modello di byte (e se un certo modello sarebbe vessatorio nella produzione, ma non nello sviluppo, tale il modello non verrà visualizzato fino a quando il codice non sarà in produzione).

La lettura della memoria non inizializzata potrebbe essere utile come parte di una strategia di generazione casuale in un sistema incorporato in cui si può essere certi che la memoria non sia mai stata scritta con contenuti sostanzialmente non casuali dall'ultima volta che il sistema è stato acceso e se la produzione il processo utilizzato per la memoria fa variare il suo stato di accensione in modo semi-casuale. Il codice dovrebbe funzionare anche se tutti i dispositivi generano sempre gli stessi dati, ma nei casi in cui ad esempio un gruppo di nodi ciascuno deve selezionare ID univoci arbitrari il più rapidamente possibile, avendo un generatore "non molto casuale" che dia alla metà dei nodi lo stesso iniziale L'identificazione potrebbe essere migliore di non avere alcuna fonte iniziale di casualità.

Come altri hanno già detto, sarà veloce, ma non casuale.

Quello che la maggior parte dei compilatori farà per le variabili locali è di prendere un po 'di spazio per loro nello stack, ma non preoccuparsi di impostarlo su nulla (lo standard dice che non è necessario, quindi perché rallentare il codice che stai generando?).

In questo caso, il valore che otterrai dipenderà da ciò che era precedentemente nello stack - se chiami una funzione prima di questa che ha un centinaio di variabili char locali tutte impostate su 'Q' e poi chiami che sei la funzione dopo che ritorna, quindi probabilmente troverai che i tuoi valori "casuali" si comportano come se memset()li avessi tutti su "Q".

È importante sottolineare che per la tua funzione di esempio che cerca di usare questo, questi valori non cambieranno ogni volta che li leggi, saranno sempre gli stessi. Quindi otterrai 100 stelle tutte impostate sullo stesso colore e visibilità.

Inoltre, nulla dice che il compilatore non dovrebbe inizializzare questi valori, quindi un compilatore futuro potrebbe farlo.

In generale: cattiva idea, non farlo. (come molte ottimizzazioni a livello di codice "intelligenti" davvero ...)

Come altri hanno già detto, si tratta di un comportamento indefinito ( UB ), ma potrebbe "funzionare".

Tranne i problemi già menzionati da altri, vedo un altro problema (svantaggio): non funzionerà in nessun linguaggio diverso da C e C ++. So che questa domanda riguarda C ++, ma se riesci a scrivere codice che sarà un buon codice C ++ e Java e non è un problema, perché no? Forse un giorno qualcuno dovrà portarlo in un'altra lingua e cercare bug causati da "trucchi magici" UB come questo sarà sicuramente un incubo (specialmente per uno sviluppatore C / C ++ inesperto).

Qui c'è una domanda su un altro UB simile. Immagina di provare a trovare un bug come questo senza conoscere questo UB. Se vuoi leggere di più su cose così strane in C / C ++, leggi le risposte alle domande dal link e guarda questa GRANDE presentazione. Ti aiuterà a capire cosa c'è sotto il cofano e come funziona; non è solo un'altra presentazione piena di "magia". Sono abbastanza sicuro che anche la maggior parte dei programmatori C / c ++ esperti può imparare molto da questo.

Non è una buona idea affidare la nostra logica al comportamento indefinito del linguaggio. Oltre a quanto menzionato / discusso in questo post, vorrei menzionare che con il moderno approccio / stile C ++ tale programma potrebbe non essere compilabile.

Questo è stato menzionato nel mio precedente post che contiene il vantaggio della funzione automatica e del link utile per lo stesso.

https://stackoverflow.com/a/26170069/2724703

Quindi, se cambiamo il codice sopra e sostituiamo i tipi effettivi con auto , il programma non verrebbe nemmeno compilato.

void updateEffect(){
    for(int i=0;i<1000;i++){
        auto r;
        auto g;
        auto b;
        star[i].setColor(r%255,g%255,b%255);
        auto isVisible;
        star[i].setVisible(isVisible);
    }
}

Mi piace il tuo modo di pensare. Davvero fuori dagli schemi. Tuttavia, il compromesso non vale davvero la pena. Il compromesso del runtime della memoria è una cosa, incluso il comportamento indefinito per il runtime non lo è .

Deve darti una sensazione molto inquietante sapere che stai usando una logica "casuale" come la tua logica aziendale. Non lo farei.

Usa 7757ogni luogo in cui sei tentato di usare variabili non inizializzate. L'ho scelto a caso da un elenco di numeri primi:

1. è un comportamento definito

2. è garantito che non sia sempre 0

3. è primo

4. è probabile che sia statisticamente casuale come variabili non inizializzate

5. è probabile che sia più veloce delle variabili non inizializzate poiché il suo valore è noto al momento della compilazione

C'è un'altra possibilità da considerare.

I compilatori moderni (ahem g ++) sono così intelligenti che esaminano il tuo codice per vedere quali istruzioni influenzano lo stato e cosa no e se un'istruzione NON influisce sullo stato, g ++ rimuoverà semplicemente quell'istruzione.

Quindi ecco cosa accadrà. g ++ vedrà sicuramente che stai leggendo, eseguendo l'aritmetica, risparmiando, che è essenzialmente un valore di immondizia, che produce più immondizia. Dal momento che non vi è alcuna garanzia che la nuova immondizia sia più utile di quella vecchia, semplicemente eliminerà il ciclo. BLOOP!

Questo metodo è utile, ma ecco cosa farei. Combina UB (Undefined Behaviour) con velocità rand ().

Naturalmente, riduci le rand()s eseguite, ma mescolale in modo che il compilatore non faccia nulla che tu non voglia.

E non ti licenzierò.

L'uso di dati non inizializzati per casualità non è necessariamente una cosa negativa se fatto correttamente. In effetti, OpenSSL fa esattamente questo per seminare il suo PRNG.

Apparentemente, tuttavia, questo utilizzo non è stato ben documentato, perché qualcuno ha notato Valgrind lamentarsi dell'utilizzo di dati non inizializzati e "risolto", causando un errore nel PRNG .

Quindi puoi farlo, ma devi sapere cosa stai facendo e assicurarti che chiunque legga il tuo codice lo capisca.