Генерация случайных чисел окружает нас везде. Любой шаг, дыхание, дуновение ветра, шум кулера, частота мяуканья кошки и т.п. уже может рассматриваться как некая генерация случайности. Так например, на сколько вы контролируете вашу ходьбу? Можете ли вы с точностью до нанометра определить точку опоры? Если не можете, то сама погрешность в неопределённости расстояния начинает становиться для вас генератором случайности. Тем не менее, генерация случайных чисел на практике является не такой тривиальной задачей, когда начинает существовать ряд ограничений. Из таковых - скорость генерации, стоимость генерации, уровень случайности. В подобных ограничениях возникает масса вопросов. Скорость генерации. Наверное является самым явным ограничением в применении. Чем быстрее генерируются случайные числа -  тем лучше. И действительно, если само событие генерации будет происходить раз в год, то такой генератор будет являться неприменимым на практике. Например, попытаемся взять первое число июля в следующем году (в определённом регионе) и если на это время выпадут осадки - то сгенерируется бит = 1, иначе бит = 0. Стоимость генерации. Некоторые генераторы могут производить случайную последовательность более быстро, чем другие и иногда за это приходится переплачивать. Так например, мяуканье кошки стоит символические пять рублей (за приобретение) с последующим кормлением (уже зависит от привередливости самой кошки). За счёт этого, вы получаете пушистый генератор случайных чисел, который раз в определённый промежуток времени может мяукать, мурчать, кусать, кушать и т.д. Если записывать каждое действие и ставить в голове некие ставки, что будет происходить дальше, то будут генерироваться случайные числа. Тем не менее, существуют генераторы случайных чисел ещё дороже (и значительно дороже), например, АЭС (атомная электростанция), которая благодаря распаду атомов урана может генерировать очень эффективно случайные числа. Но для этого понадобится +- 22 миллиарда долларов без учёта последующего обслуживания. Уровень случайности. Является самым сложным ограничением в плане своего описания. Существует множество видов генераторов случайных чисел - ГСЧ (генератор случайных чисел), ГПСЧ (генератора псевдо-случайных чисел), КСГПСЧ (криптографически стойкий генератор псевдо-случайных чисел). Последние два являются генераторами псевдослучайных чисел, иными словами генерируемая ими последовательность лишь выглядит как случайная, но на деле является следствием алгоритма. За счёт алгоритмизации, у псевдослучайных генераторов существует три качества: 1) ГПСЧ и КСГПСЧ имеют периоды генерации при достижении которых вся ранее генерируемая последовательность начнёт повторяться; 2) При необходимости можно повторить всю ранее сгенерированную последовательность, если имеется seed/ключ - начальное значение из которого происходит вся последующая генерация; 3) ГПСЧ и КСГПСЧ работают в разы эффективнее большинства представителей ГСЧ, требуя при этом меньше ресурсов. Тем не менее, если говорить о качестве генераторов, то таковое можно изобразить в неравенстве ГСЧ > КСГПСЧ > ГПСЧ.  Разобрав основные ограничения, настало время разобрать тонкости различия ГСЧ и ГПСЧ. Как было определено ранее, основным отличием ГСЧ от ГПСЧ (в том числе и от КСГПСЧ) является фактор алгоритмизации. Если существует алгоритм, который способен повторить всю генерируемую последовательность, то это значит, что никакой на деле случайности не существует, существует лишь псевдослучайность. Но так ли всё однозначно на первый взгляд? Вернёмся к примеру с кошкой. Если вы живёте с кошкой достаточно длительное количество времени, то рано или поздно вы начнёте предугадывать большинство её действий/событий, что-то будет являться фактором/причиной её последующих действий/следствий. Ровно такие же условия будут действовать с ураном и распадом атомов, если нам будут известны все возможные неизвестные переменные - местоположение атомов, частиц, их скорости, столкновения и т.д. Чисто теоретически, если это всё станет возможным, то ГСЧ регрессирует до ГПСЧ, где вместо входных бит, на вход будут подаваться факторы/причины всех последующих действий.  Тем не менее, ГСЧ с истинной случайностью вполне может существовать, но лишь при условии, что не будет существовать причинно-следственных связей. Науке уже известны квантовые явления, которые могут приводить к неопределённости состояния частиц, что может становиться прототипом хороших и качественных ГСЧ. Но эта тема выходит далеко за рамки данной статьи. Рассмотрев возможный регресс ГСЧ до ГПСЧ, становится логичным последующий вопрос, а возможен ли прогресс ГПСЧ до ГСЧ? Чтобы ответить на данный вопрос, необходимо решить противоречивую задачу, при которой сам алгоритм должен стать неоднозначным. При этом алгоритм не должен задействовать сторонние способы генерации случайных и псевдо-случайных чисел, иначе таковой алгоритм станет нечистым и приведёт лишь к композиции. Иными словами, если рассматривать алгоритм как A, то само A должно стать ГСЧ => A=ГСЧ, а не быть выражением A+ГСЧ. Компьютер представляет собой выражение алгоритма. Действие компьютера - есть действие алгоритма. Со стороны математической модели не может существовать такого алгоритма, который бы стал выражением самой случайности. Тем не менее, компьютер != математическая модель, хоть с одной стороны он действительно детерминирован, но с другой стороны, противоречиво он становится также выражением хаотичности собственных процессов.  Неопределённые поведения (UB - undefined behaviour) алгоритмов - это задачи, на базе которых алгоритм может становиться случайным. Тем не менее, одно неопределённое поведение неравно другому, ровно также одно неопределённое поведение может быть бесполезным для ГСЧ, в то время как другое может становиться его основой.  Так например, существуют неопределённые поведения некоторых языков программирования со стороны стандартов, в которых не указывается единственно верное действие, например язык С и выражение i = i++ + ++i;. Решением такого неопределённого поведения становится порядок вычисления со стороны самих компиляторов. Данное UB крайне проблематично применять в ГСЧ, т.к. единожды установив компилятор, все дальнейшие действия уже будут определены.  Но существуют также UB, которые очень сложно или невозможно определить каким-либо стандартом или спецификацией из-за собственной своей особенности. К таким неопределённым поведениям относится состояние гонки. Состояние гонки - ситуация, при которой несколько параллельных процессов обращаются одновременно к одной области памяти. Так например, если запущено два параллельных процесса, один из которых будет писать в область памяти число = 0, а другой число = 1, то какое число запишется в эту область памяти? С уверенностью на данный вопрос ответить крайне проблематично, потому что в данном контексте не существует никаких документаций, стандартов, реализаций. Если процессы действительно параллельны и обращаются единовременно к участку памяти, то события равновероятны. На основе данной концепции становится возможным построение ГСЧ. Параллельность можно организовывать разными способами. В моём случае, я буду реализовывать генерацию случайных чисел на двух языках - CUDA C (под GPU) и Golang (под CPU). Разные механизмы языков программирования также могут дать понимание, насколько непредсказуемым остаётся состояние гонки.  При тестировании случайных чисел (случайной последовательности - гаммы) будет использоваться программа rngtest. Но стоит помнить, что таковые тесты способны давать хороший результат только в определении неслучайной последовательности. Тем не менее, доказать, что последовательность случайная - они не могут. Поэтому даже если давать таким тестам псевдослучайную последовательность, то она с большей долей вероятности пройдёт тест, потому как внешние характеристики будут указывать на хорошее распределение. Результат программы rngtest. Тогда встаёт логичный вопрос - для чего тогда вообще нужен этот инструмент, если он говорит о том, что псевдослучайная последовательность проходит тест на случайность? Это нужно для того, чтобы быть уверенным в правильном распределении бит, чтобы разрабатываемый ГСЧ не оказался слишком слабым. У некоторых ГСЧ существуют недостатки подобия малого диапазона генерации, частых повторений одних и тех же блоков и т.д. На это может rngtest поругаться, а нам это и будет нужно. Также можно воспользоваться онлайн тестером. Он принимает битовое представление гаммы в символьном виде, поэтому необходимо перевести сырые байты в строковые биты. Можно воспользоваться такой программой. Первое что делаем - готовим шаблон самой генерации. Здесь всё крайне легко, мы подаём в качестве аргумента указатель на переменную, куда будет записываться случайное число. В качестве случайного числа мы берём ID блока, который смог перезаписать число и "выиграть" в гонке. Константа MODULE_N равна 2. Будем генерировать бинарные числа. Константу можно изменить на другое число, алгоритм также продолжит функционировать. Тем не менее, MODULE_N должен быть степенью двойки, то-есть равен 2 или 4 или 8 или 16 и т.д. Это необходимо для более равномерного распределения итоговых чисел по битовому пространству.  Функция вызова rand_uintNs будет выглядить следующим образом. Визуально её можно поделить на две части: 1) генерация сырой гаммы, 2) сжатие сырой гаммы посредством суммирования. Второй пункт приводит к лучшему выравниванию частот встречаемости. Так например, без второго пункта количество нулей часто привышало количество единиц (при MODULE_N=2). Второй пункт приводит к хорошему выравниванию частот встречаемости, в том числе и для разных MODULE_N.  Константа CUDA_BLOCK_N = 4096. В ходе экспериментов, данная константа привела к положительным результатам в тестировании. Связано это с тем, что чем больше будет задействовано параллельности, тем больше будет конечная неопределённость. Тем не менее, тут всё также упирается во время (чем больше CUDA_BLOCK_N, тем дольше ждать). Под каждый блок выделяется только один поток. При экспериментах, потоки ведут себя более конкурентным образом, чем параллельным.  Вызов всего этого кода происходит так. Функция print_uintNs Функция print_uintNs_count   Тесты Программа rngtest смотрит не на символьное представление случайности, а на битовое. Поэтому нужно изменить выдачу результата, иначе rngtest всегда будет говорить о непрохождении теста. Также, чтобы rngtest мог правильно проанализировать данные, ему на вход нужно подать достаточно большую последовательность бит.  Таким образом, меняем константу MODULE_N с 2 на 256, чтобы генерировались конкретно байты. Далее, нужно поменять константу n в функции main с 1024 на 4096, т.к. 1024 будет недостаточно для rngtest. После этого, надо написать функцию, которая сохраняет байты, а не числа в виде строки.  Запускаем ГСЧ. Гамма генерировалась 3 минуты, 10 секунд для CUDA_BLOCK_N=65535 (максимальное количество) и 26 секунд для CUDA_BLOCK_N=4096 (оба значения прошли тест, но если имеется возможность, то лучше использовать конечно консервативный вариант). Относительно неплохое время для ГСЧ, генерирующего в одного 4096 байт. Тем не менее, видеокарта нехило так работала (при 65535), значения в 100%, а ноутбук (на котором все эти вычисления я производил) нагрелся быстро. Ощущение словно биткоин майнил...  И запускаем теперь rngtest, получаем результаты. Теперь настало время потестировать CPU. В данном примере, у нас будет Intel CORE I7 с 12 ядрами. На Golang'e я постарался запрограммировать примерно такой же код с такими же функциями.  Функции генерации случайного числа на основе состояния гонки. Функция randUintN - эквивалент rand_uintN в CUDA C, функция runRandUintN подобие параллельному запуску функции с видеокарты в несколько блоков.  Константа moduleN = 256, blockN = 256. Последнее значение проходит тесты. Такое число было взято по причине полного покрытия диапазона модуля.  Функция randUintNs - эквивалент функции rand_uintNs в CUDA C примере. Основная функция. В ней я устанавливаю максимальное количество процессоров.  Тесты Запускаем ГСЧ. Генерация гаммы заняло 1 минуту, 6 секунд. И запускаем теперь rngtest, получаем результаты. В Go потребовалось всего blockN=256 (тесты проходили и с меньшим числом), в то время как в CUDA C потребовалось CUDA_BLOCK_N=4096 для прохождения тестов. Связано всё это с тем, что чем меньше загружены ядра/блоки, тем менее эффективно будет исполняться состояние гонки. Поэтому CUDA C требует большее количество блоков, чтобы происходило неопределённое поведение. Тема выдалась достаточно интересная, тем не менее, я не рекомендую применять данные генераторы в чистом виде. Это может быть опасно, потому как ГСЧ на базе состояния гонки, по моим предположениям, хуже ГСЧ считывающего шум кулера, а потому лучше применять вышеописанное UB исключительно как составную деталь пула энтропии.  Также, моя работа не является какой-то основополагающей. Предположения на счёт того, что UB можно применять в генерации случайных чисел также существовали. Таковые работы я привожу в разделе Литература.  Помимо прочего, использование только одного инструмента тестирования на случайность также может быть недостаточным. В идеальном случае лучше всё это тестировать при помощи нескольких инструментов. Но тут уже можете привести в комментариях какие тесты проходят, какие не проходят. Если некоторые тесты не проходят, то могу посоветовать покрутить параметры CUDA_BLOCK_N (C) или blockN (Golang), не забывая также выставить MODULE_N и moduleN = 256 (если того требует инструмент тестирования).  Все исходные коды можно посмотреть тут. GPUs and chaos: a new true random number generator https://www.researchgate.net/profile/Je-Sen-Teh/publication/282478044_GPUs_and_chaos_a_new_true_random_number_generator/links/5c05de93a6fdcc315f9ae0f1/GPUs-and-chaos-a-new-true-random-number-generator.pdf GPUs as high-performance random sources https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/el.2013.4047  Криптограф, Программист