Устал давать ссылки на предыдущие материалы - пусть будет 1 самый начальный, а там в конце ссылки на весь остальной десяток. Самый главный провал произошедший: отказ и кучи, и стека, выдавать мусор в самих себе при инициализации: Windows подтирает нулями всё, что насоздавали предыдущие программы, - независимо от корректности их завершения.

Шло время. Был создан просто быстрый генератор unsigned int со скоростью >4ГБ/с. Начала применяться парадигма генератора в генераторе - скорость выросла до 5.91ГБ/с, порциями по 512Б. Но жестоко пострадала энтропия, криптостойкость - человек всё ещё мог, зная примерный алгоритм генерации, распознать хаотичный мусор в месте бывших полезных данных. Парадигма генератора в генераторе применилась повторно - результат превзошёл все ожидания.

Генератор в генераторе. Изначальный псевдослучайный генератор был модернизирован для псевдослучайной генерации long double. Long double использовались как мера хаоса, второй генератор: неуправляемое поведение мантиссы, относительно управляемое поведение целой части - прибавил число большое сильно дробное - получил все 10Б другими числами. Псевдохаос превратился в хаос, но скорость по-прежнему была недостаточной. Ускорил - но превратил хаос обратно в псевдохаос - коэффициенты энтропии Шеннона поплыли вниз, ниже изначального псевдослучайного генератора.

Чтобы сделать генератор в генераторе в генераторе, не осталось выбора - пришлось создавать свой класс. Написание "class", потом фигурная скобочка, потом public-protected-private, потом конструктор писать - всё это всегда вызывало омерзение при создании класса с нуля. И омерзение не оказалось напрасным: скорость вызова просто функции и скорость вызова её же из класса - в режиме дебага отличается в медленную сторону процентов на 20. Поэтому - уничтожил класс, со всеми написанными функциями и методами уже, - чтобы не ущемлять программиста в разработке при использовании генератора и найти другое решение вопроса.

В момент уничтожения класса, вспомнилось: как точно так же потратил дохрена времени на стек и кучу, пытаясь халявный мусор достать из них. И тут озаряет: если стек маленький, а куча медленнее стека в 100+ раз, - то есть сегмент данных со средней скоростью. Далее гугл опять меняет свои показания: утверждает, что сегмент данных не средний по скорости - а работает со скоростью стека. Далее заявляет, что его максимальный размер 2ГБ, - полное враньё, вплоть до падения среды разработки и зависания ОС, - неисследованный максимум 64МБ, исследованный максимум 26МБ.

Казалось бы, провал. Не имею права приближаться к максимуму: программисту тоже нужен сегмент данных - как минимум, для своих глобальных переменных. Но тут приходит понимание: какого хрена упёрся в 32768 элементов по 512Б, когда можно упереться в 1677726 элемента по 1Б. Это же поле непаханое для генерации мусора: тратишь менее секунды на генерацию мусора 16МБ - и ультрабыстро бродишь по нему хаотично указателем, и выкусываешь куски по 512Б. Всё, что нужно (и то лишь вероятно: зачем хаос портить), - обеспечить, чтобы номинал указателя всегда отличался на 512Б в обе стороны от предыдущего: не захватывать мусор от предыдущего элемента.

Такая парадигма, в сыром варианте реализации, - не просто дала скорость генерации мусора >118ГБ/с, а увеличение коэффициентов Шеннона до 7.1-7.4 для всех данных 200МБ и 6.7-6.8 для блока данных 512Б.

Исходников пока не будет: причёсывать всё надо. Использованы все известные способы ускорения.

...но, может быть, можно ещё быстрее?..

Да не, бред какой-то (c).

А вот не бред. В режиме релиза - скорость падает до 149ГБ/. Либо время пустого цикла считается с огромной погрешностью, что ведёт к искажению измерения скорости, либо х.з. что. Ответ: маленькие изначальные генераторы - работают в релизе медленнее, чем в дебаге: баг среды разработки.