初期化されていないローカル変数は最速の乱数ジェネレータですか？

初期化されていないローカル変数が未定義の動作（UB）であることを知っています。また、値にはトラップ表現があり、それが以降の操作に影響を与える可能性があります。ただし、乱数を視覚的表現にのみ使用し、それ以外の部分では使用しない場合もあります。たとえば、プログラムを視覚効果にランダムな色で設定します。次に例を示します。

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);
    }
}

それよりも速いですか

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);
    }
}

また、他の乱数ジェネレータよりも高速ですか？

他の人が指摘したように、これは未定義の動作（UB）です。

実際には、（おそらく）実際には（一種の）動作します。x86 [-64]アーキテクチャで初期化されていないレジスタから読み取ると、実際にガベージ結果が生成され、おそらく悪いことは何も行われません（たとえば、Itaniumでは、レジスタに無効のフラグが付けられ、読み取りがNaNのようなエラーを伝播する可能性があります）。

ただし、主な問題が2つあります。

1. 特にランダムではありません。 この場合、スタックから読み取っているので、以前そこにあったものをすべて取得します。これは事実上ランダムで完全に構造化されたもの、10分前に入力したパスワード、または祖母のCookieレシピである可能性があります。

2. このようなことをコードに忍び込ませるのは悪いことです（大文字の 'B'）。技術的にはreformat_hdd();、未定義の変数を読み取るたびにコンパイラーが挿入する可能性があります。それはしませんが、とにかくそれをするべきではありません。安全でないことをしないでください。例外が少ないほど、偶発的な間違いから常に安全になります。

UBのより差し迫った問題は、プログラム全体の動作が未定義になることです。最新のコンパイラはこれを使用して、コードの膨大な部分を排除したり、時間を遡ったりすることができます。UBで遊ぶことは、生きている原子炉を解体するビクトリア朝のエンジニアのようなものです。失敗することは無数にあり、基礎となる原理や実装されているテクノロジーの半分はおそらく分からないでしょう。それは大丈夫かもしれませんが、それをまだ起こさせてはいけません。詳細については、他の素晴らしい答えを見てください。

また、私はあなたを解雇します。

私はこれを明確に言いましょう：私たちはプログラムで未定義の振る舞いを起動しません。それは決して良い考えではありません。このルールにはまれな例外があります。たとえば、offsetofを実装するライブラリ実装者である場合などです。あなたのケースがそのような例外に該当する場合、あなたはおそらくこれをすでに知っています。この場合、初期化されていない自動変数の使用は未定義の動作であることがわかります。

コンパイラは、未定義の動作に関する最適化により非常に攻撃的になり、未定義の動作がセキュリティ上の欠陥につながる多くのケースを見つけることができます。最も悪名高いのは、おそらくLinuxカーネルのnullポインターチェックの削除で、C ++コンパイルのバグに対する私の回答で言及したものでしょうか。未定義の動作に関するコンパイラの最適化により、有限ループが無限ループに変わりました。

CERTの危険な最適化と因果関係の喪失（ビデオ）を読むことができます。

コンパイラの作成者は、CおよびC ++プログラミング言語の未定義の動作を利用して最適化を向上させることがますます増えています。

多くの場合、これらの最適化は、開発者がソースコードに対して原因効果分析を実行する能力、つまり、以前の結果に対する下流の結果の依存性を分析する能力を妨げています。

その結果、これらの最適化はソフトウェアの因果関係を排除し、ソフトウェアの障害、欠陥、および脆弱性の可能性を高めています。

特に、不確定な値に関して、C標準の欠陥レポート451：初期化されていない自動変数の不安定性は、興味深い読み物になります。これはまだ解決されていませんが、値の不確定性がプログラム全体に伝播し、プログラム内の異なるポイントで異なる不確定値を持つ可能性があることを意味する、ぐらついた値の概念が導入されています。

これが発生する例は知りませんが、現時点では除外できません。

実際の例ではなく、期待した結果

ランダムな値を取得することはほとんどありません。コンパイラーはループを完全に最適化できます。たとえば、この単純化されたケースでは：

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

clangはそれを最適化します（実際に見る）：

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

または、この変更されたケースのように、おそらくすべてゼロを取得します。

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

ライブでご覧ください。

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

これらのケースは両方とも、未定義の動作の完全に許容できる形式です。

Itaniumを使用している場合、トラップ値が発生する可能性があることに注意してください。

[...]レジスタが特別な「何もない」値を保持している場合、いくつかの命令を除いてレジスタトラップを読み取る[...]

その他の重要な注意事項

初期化されていないメモリに関して未定義の動作をどのように利用するかについて、UB Canariesプロジェクトで指摘されているgccとclangの違いに注目するのは興味深いことです。記事のノート（強調鉱山）：

もちろん、そのような期待は言語標準とは何の関係もないことと、特定のコンパイラが何をするかとはすべて関係があることを自分自身で完全に明確にする必要があります。そのコンパイラのプロバイダーはそのUBを悪用したくない、または彼らがまだそれを利用することに慣れていないからです。コンパイラープロバイダーからの本当の保証が存在しない場合、まだ利用されていないUBは時限爆弾であると言いたいです。コンパイラーが少し積極的になるとき、彼らは来月または来年のオフを待っています。

Matthieu M.が指摘するように、すべてのCプログラマーが未定義の動作について知っておくべきこと＃2/3もこの質問に関連しています。それは他のものの間で言う（強調鉱山）：

実現するために重要と怖い事はということですちょうど約すべての 未定義の動作に基づいて最適化将来の任意の時点でバギーコードでトリガされ始めることができます。インライン化、ループのアンロール、メモリの昇格、その他の最適化は継続的に改善されます。それらが存在する理由の重要な部分は、上記のような2次的な最適化を公開することです。

私にとって、これは深く不満です。これは、コンパイラーが必然的に非難されてしまうためですが、Cコードの巨大な本体が爆発するのを待っているだけの地雷であることも意味します。

完全を期すために、実装は未定義の動作を明確に定義するように選択できることをおそらく言及する必要があります。たとえば、gccは共用体を介した型パンニングを許可しますが、C ++ではこれは未定義の動作のように見えます。これが事実である場合、実装はそれを文書化する必要があり、これは通常は移植できません。

いいえ、それはひどいです。

初期化されていない変数を使用した場合の動作は、CとC ++の両方で定義されておらず、そのようなスキームが望ましい統計的特性を持つことはほとんどありません。

「迅速で汚れた」乱数ジェネレータが必要な場合rand()は、最善の方法です。その実装では、乗算、加算、係数のみが実行されます。

私の知っている最速の発電機は、使用する必要がありuint32_t、擬似ランダム変数の型としてI、および使用

I = 1664525 * I + 1013904223

連続する値を生成します。あなたはあなたの空想をとるI（シードと呼ばれる）の任意の初期値を選択することができます。もちろん、インラインでコーディングできます。符号なしの型の標準保証のラップアラウンドは、係数として機能します。（数値定数は、その驚くべき科学プログラマーであるドナルドクヌースによって厳選されています。）

良い質問！

未定義は、それがランダムであることを意味しません。考えてみてください。初期化されていないグローバル変数で取得する値は、システムまたは実行中のアプリケーションによって残されています。使用されなくなったメモリでのシステムの動作や、システムとアプリケーションが生成する値の種類に応じて、次のようになります。

1. いつも同じ。
2. 小さな値のセットの1つであること。
3. 1つ以上の小さな範囲の値を取得します。
4. 16/32/64ビットシステムのポインターから2/4/8で割り切れる多くの値を参照してください
5. ...

得られる値は、システムやアプリケーションによって残されたランダムでない値に完全に依存します。したがって、確かにノイズが発生します（システムがメモリを使用しなくなった場合を除きます）が、そこから取得する値のプールは決してランダムではありません。

ローカル変数は、自分のプログラムのスタックから直接取得されるため、状況はさらに悪化します。プログラムが他のコードの実行中にこれらのスタック位置を実際に書き込む可能性は非常に高いです。私はこの状況で運の可能性が非常に低いと推定し、あなたが行った「ランダムな」コード変更がこの運を試みます。

ランダム性についてお読みください。見てわかるように、ランダム性は非常に特異的であり、プロパティを取得するのは困難です。追跡するのが難しい何か（提案など）を取るだけではランダムな値が得られると考えるのはよくある間違いです。

多くの良い答えがありますが、もう1つ追加して、決定論的コンピューターではランダムなものは何もないという点を強調しておきます。これは、疑似RNGによって生成された数値と、スタック上のC / C ++ローカル変数用に予約されたメモリ領域に見られる「ランダムな」数値の両方に当てはまります。

しかし...決定的な違いがあります。

優れた疑似乱数ジェネレーターによって生成された数値には、真にランダムな描画と統計的に類似する特性があります。たとえば、分布は均一です。サイクルの長さは長く、サイクルが繰り返される前に数百万の乱数を取得できます。シーケンスは自己相関ではありません。たとえば、2番目、3番目、または27番目の数値をすべて使用した場合、または生成された数値の特定の桁を調べた場合、奇妙なパターンが出現することはありません。

対照的に、スタックに残された「ランダムな」数には、これらの特性はありません。それらの値と見かけ上のランダム性は、プログラムの構築方法、プログラムのコンパイル方法、およびコンパイラーによる最適化方法に完全に依存します。例として、自己完結型プログラムとしてのアイデアのバリエーションを次に示します。

#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;
}

LinuxマシンでGCCを使用してこのコードをコンパイルし、実行すると、かなり不快に決定的であることがわかります。

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

逆アセンブラでコンパイルされたコードを見ると、何が起こっているのかを詳細に再構築できます。notrandom（）への最初の呼び出しは、このプログラムで以前に使用されなかったスタックの領域を使用しました。そこに何があったかを知っている人。しかし、notrandom（）への呼び出しの後に、printf（）への呼び出し（GCCコンパイラーは実際にはputchar（）への呼び出しに最適化されますが、気にしないでください）があり、スタックが上書きされます。したがって、次回以降、notrandom（）が呼び出されると、スタックにはputchar（）の実行からの古いデータが含まれます。また、putchar（）は常に同じ引数で呼び出されるため、この古いデータは常に同じです。あまりにも。

したがって、この振る舞いについてランダムなことは絶対にありません。また、このようにして得られた数値には、適切に作成された疑似乱数ジェネレータの望ましい特性がありません。実際、ほとんどの実際のシナリオでは、それらの値は反復的であり、高度に相関しています。

実際、他の人と同じように、私はこのアイデアを「高性能RNG」として偽装しようとした人物を解雇することも真剣に検討します。

未定義の動作とは、コンパイラーの作成者が問題を無視してもかまわないことを意味します。なぜなら、プログラマーは何が起こっても不満を言う権利を決して持っていないからです。

理論上、UBランドに入ると何かが起こる可能性がありますが（ノーズから飛び降りるデーモンを含む）、通常意味することは、コンパイラの作成者は気にせず、ローカル変数の場合、値はその時点でスタックメモリにあるものになります。

これはまた、多くの場合、コンテンツは「奇妙」ですが、固定またはわずかにランダムまたは可変ですが、明確なパターン（たとえば、各反復での値の増加）を伴います。

確かにあなたがすることはできません、それはまともな乱数発生器であることを期待しています。

未定義の動作は未定義です。未定義の値を取得することを意味するのではなく、プログラムが何でも実行でき、言語仕様を満たしていることを意味します。

良い最適化コンパイラは

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);
    }
}

そして、それをnoopにコンパイルします。これは確かに他のどの方法よりも高速です。それは何もしないという欠点がありますが、それは未定義の振る舞いの欠点です。

まだ言及されていませんが、未定義の動作を呼び出すコードパスは、コンパイラが望むすべてのことを実行できます。

void updateEffect(){}

これは、正しいループよりも確かに高速で、UBのため、完全に適合しています。

セキュリティ上の理由から、プログラムに割り当てられた新しいメモリをクリーンアップする必要があります。そうしないと、情報が使用され、パスワードがアプリケーション間で漏洩する可能性があります。メモリを再利用する場合にのみ、0とは異なる値が得られます。また、スタックの以前の値は固定されている可能性が非常に高いです。これは、そのメモリの以前の使用が固定されているためです。

あなたの特定のコード例はおそらくあなたが期待していることをしないでしょう。技術的にはループの各反復でr、g、およびbの値のローカル変数が再作成されますが、実際には、それはスタック上のまったく同じメモリ空間です。したがって、反復のたびに再ランダム化されることはなく、r、g、bが個別に、かつ最初にどれだけランダムであるかに関係なく、1000色のそれぞれに同じ3つの値を割り当てることになります。

実際、もしそれがうまくいったなら、何が再ランダム化されているのかについて私は非常に興味があります。私が考えることができる唯一のことは、そのスタックの上にピギーパックされたインターリーブされた割り込みであろう、非常にありそうもない。おそらく、レジスタをループ内のさらに下で再利用する実際のメモリ位置としてではなく、レジスタ変数として保持した内部最適化も、特に可視性の設定関数が特にレジスタを大量に消費する場合にうまくいきます。それでも、ランダムとはほど遠い。

ここのほとんどの人が未定義の振る舞いに言及したように。未定義は、有効な整数値を（幸運にも）取得できることも意味します。この場合、これはより高速になります（rand関数呼び出しが行われないため）。ただし、実際には使用しないでください。運がいつもあなたと一緒にいるわけではないので、これは恐ろしい結果になると確信しています。

すごく悪い！悪い習慣、悪い結果。考慮してください：

A_Function_that_use_a_lot_the_Stack();
updateEffect();

関数A_Function_that_use_a_lot_the_Stack()が常に同じ初期化を行う場合、スタックには同じデータが残ります。そのデータは、私たちが呼び出すものupdateEffect()です。常に同じ値です！。

私は非常に簡単なテストを行いましたが、それはまったくランダムではありませんでした。

#include <stdio.h>

int main() {

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

私がプログラムを実行するたびに、同じ数（32767私の場合）が出力されました。これよりランダムにすることはできません。これはおそらく、ランタイムライブラリのスタートアップコードがスタックに残されたものです。プログラムが実行されるたびに同じ起動コードを使用し、プログラム間で実行間で何も変化しないため、結果は完全に一貫しています。

「ランダム」の意味を定義する必要があります。賢明な定義では、取得する値にはほとんど相関関係がないはずです。それはあなたが測定できるものです。また、制御された再現可能な方法で達成することは簡単ではありません。したがって、未定義の動作は、あなたが探しているものではありません。

初期化されていないメモリが「unsigned char *」型[たとえばから返されるバッファmalloc] を使用して安全に読み取られる場合があります。コードは、コンパイラがウィンドウから因果関係をスローすることを心配する必要なく、そのようなメモリを読み取ることができます。また、初期化されていないデータが読み取られないようにするよりも、メモリに含まれる可能性があるものに対してコードを準備する方が効率的な場合があります（これの当たり前の例はmemcpy、意味のあるデータを含むすべての要素を個別にコピーするのではなく、部分的に初期化されたバッファーです。

ただし、そのような場合でも、バイトの任意の組み合わせが特に厄介なものである場合、それを読み取ると常にそのバイトのパターンが生成されると常に想定する必要があります（特定のパターンが本番環境では問題になりますが、開発では問題になります。パターンは、コードが本稼働するまで表示されません）。

初期化されていないメモリを読み取ることは、システムに最後に電源を入れてからメモリが実質的に非ランダムなコンテンツで書き込まれたことがないことを確認できる組み込みシステムのランダム生成戦略の一部として役立つかもしれません。メモリに使用されるプロセスは、電源投入時の状態を半ランダムに変化させます。すべてのデバイスが常に同じデータを生成する場合でもコードは機能するはずですが、たとえばノードのグループがそれぞれ任意の一意のIDをできるだけ迅速に選択する必要がある場合、半分のノードに同じ初期値を与える「それほどランダムではない」ジェネレーターがあります。 IDは、ランダム性の初期ソースをまったく持たないよりも優れている場合があります。

他の人が言ったように、それは高速ですがランダムではありません。

ほとんどのコンパイラーがローカル変数に対して行うことは、スタック上にそれらのスペースを取得することですが、それを何かに設定することを迷惑をかけることはありません（標準は、それらが必要としないと言っているので、なぜあなたが生成しているコードを遅くしますか？）。

この場合、取得する値は、スタックの以前の状態によって異なります。100個のローカル文字変数がすべて「Q」に設定されている関数の前に関数を呼び出し、その後に関数を呼び出した場合それが戻ると、おそらく「ランダムな」値がmemset()「Q」に等しいかのように動作することがわかります。

重要なのは、これを使用しようとするサンプル関数の場合、これらの値は、読み取るたびに変更されることはなく、毎回同じになることです。したがって、100個の星がすべて同じ色と可視性に設定されます。

また、コンパイラーがこれらの値を初期化してはならないということは何もありません。将来のコンパイラーが初期化する可能性があります。

一般的には、悪い考えですが、しないでください。（多くの「賢い」コードレベルの最適化のように...）

他の人がすでに述べたように、これは未定義の動作（UB）ですが、「機能する」可能性があります。

他の人がすでに述べた問題を除いて、私はもう1つの問題（不利な点）を見つけました-CおよびC ++以外の言語では機能しません。私はこの質問がC ++についてであることを知っていますが、良いC ++とJavaコードになるコードを書くことができ、それが問題ではないのであれば、なぜでしょうか？たぶん、誰かがそれを他の言語に移植して、「手品」によって引き起こされたバグを探す必要があるかもしれませんならず、このような UBすることは間違いなく悪夢になります（特に経験の浅いC / C ++開発者にとって）。

ここでは、別の同様のUBに関する質問があります。このUBについて知らなくても、このようなバグを見つけようとしているところを想像してみてください。C / C ++でこのような奇妙なことについてさらに読みたい場合は、リンクからの質問に対する回答を読んで、この 素晴らしいスライドショーを参照してください。これは、内部の内容とその機能を理解するのに役立ちます。「魔法」でいっぱいの別のスライドショーではありません。ほとんどの経験豊富なC / c ++プログラマーでも、これから多くを学ぶことができると私は確信しています。

ない言語の未定義の振る舞いに関するロジックに依存するのは良い考えで。この投稿で言及/議論されたものに加えて、現代のC ++のアプローチ/スタイルでは、そのようなプログラムはコンパイルできない可能性があることを述べておきます。

これは、自動機能の利点とその便利なリンクを含む私の以前の投稿で言及されました。

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

したがって、上記のコードを変更して実際の型をautoに置き換えると、プログラムはコンパイルさえできなくなります。

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);
    }
}

私はあなたの考え方が好きです。本当に箱の外。ただし、トレードオフは実際には価値がありません。メモリとランタイムのトレードオフは、ランタイムの未定義の動作を含むものではありません。

ビジネスロジックとしてこのような「ランダム」を使用していることを知るのは、非常に不安な気持ちになるはずです。私はそれをしません。

使用7757あなたが初期化されていない変数を使用するように誘惑されているすべての場所を。素数のリストからランダムに選びました：

1. 定義された動作です

2. 常に0であるとは限らないことが保証されています

3. それは素数です

4. 初期化されていない変数と同じくらい統計的にランダムである可能性があります

5. 値はコンパイル時にわかっているため、初期化されていない変数よりも高速になる可能性があります

考慮すべきもう1つの可能性があります。

最新のコンパイラー（ahem g ++）は非常にインテリジェントなので、コードを調べて、どの命令が状態に影響し、何が影響しないかを確認します。命令が状態に影響しないことが保証されている場合、g ++は単にその命令を削除します。

だからここに何が起こるかです。g ++は間違いなく、あなたが読んでいること、算術を実行していること、保存していること、本質的にガベージ値であるものを認識します。新しいガベージが古いガベージよりも有用であるという保証はないので、ループがなくなるだけです。BLOOP！

この方法は便利ですが、ここでは私が何をするかです。UB（Undefined Behaviour）とrand（）の速度を組み合わせます。

もちろん、rand()実行されるsを減らしますが、それらを混ぜ合わせて、コンパイラーが望まないことを何もしないようにします。

そして、私はあなたを解雇しません。

ランダム化のために初期化されていないデータを使用することは、適切に行われれば必ずしも悪いことではありません。実際、OpenSSLはまさにこれを行い、PRNGをシードします。

ただし、Valgrindが初期化されていないデータを使用して「修正」し、PRNGにバグを引き起こしていると不平を言っていることに誰かが気付いたため、この使用法は十分に文書化されていなかったようです。

したがって、それを行うことはできますが、自分が何をしているかを理解し、コードを読んでいる人がこれを理解できるようにする必要があります。