Тема диплома бывшего стажёра по созданию ускоренного генератора чисел - была успешно выполнена. Однако не смог остановиться: интерес большего ускорения взял верх - и понеслась. Поставил RAdmin3 на нетбук и виртуалку с одинаковыми Windows XP - код на нетбуке выглядит мелко, но зато стоять у стационарного ПК уже не надо.

Предыдущая теория, из которой родилась предыдущая практика, - были необходимы для быстрого получения хаотичных чисел (и их использование для беспалевной очистки свободного места на носителях, чтобы идиоты ни до чего не доипались - чтобы потом не было липовых актов, высосанных из пальца).

Из практики, где 4млрд раз запускались разные методы генерации чисел, был получен максимальный результат на модернизированном руками примере из интернета (буквально, одной строчкой). Размерность результатов времени - мс/Б (опуская при этом эту цикличность 4млрд: она нужна для получения абсолютно точных результатов). Результат 635мс/Б, в сравнении с 5838мс/Б штатной rand() (перепроверен), - ускорение в 9.2 раза.

Итак, скачиваются исходники работы с SHA512 с единственного немецкого сайта. Естественно для большинства исходников в интернете, как помойки, - не компилируются. Нужно в CPP-файле найти все define многострочные и добавить им слеши \ справа каждой строки, перед начальной скобкой написать do, после конечной скобки - while(0).

Результат, полученный при выполнении функции Update класса SHA512 - классный: 135мс/Б. Однако вторая функция Final - жрала предельно много времени, и был получен результат 1300мс/Б - отрицательный. Пришлось лезть в CPP-файл и изменять все функции, которые относились к Final (и её саму). Процесс был долгим: от изменения типов переменных на более быстрые, до их полного удаления, до удаления строк кода, до удаления вообще целых циклов - пока от функций Final и Transfer не осталось практически ничего. В итоге, алгоритм расчёта контрольной суммы - превратился в генератор рандомных данных 64Б, даже если входные данные были одни и те же. Но запуск - ~900мс/Б. Оптимизировать уже нечего - провал.

BLAKE3 - настроить так и не удалось. Его перспективы по скорости - остаются потенциально выгодными, даже после произошедшего выше и ниже.

Генератор std mt19937 - не проверить, т.к. появился только в C++11.

Далее произошло то, что должно было произойти. Послеоперационная прямая кишка сказала: "Беги!". При операции, вырезали из кишки много - потерял способность при оформленном стуле какать на унитазе. И только исправление анатомического несоответствия унитаза (на корточках в ванну) спасает от невозможности покакать (иначе уехал в больницу бы в 4-й раз - и не раз). И вот, после экзекуции: надо оценить кал на кровотечение, консистенцию по Бристольской шкале - и выкинуть его на одноразовой тарелке в унитаз. Поднимаю одноразовую тарелку - весит столько же, сколько поллитровая бутылка воды в кровати, - при норме человека 250г/сутки. Ну и думаешь сразу: да, принудительные фитомуцил и дюфалак делают своё дело. И вот смотрю на эту кучу - а потом приходит озарение.

Как вы могли?! Вы всё знали с самого начала! Я тут барахтаюсь в попытке ускорить генерацию чисел - а вы, зная как это всё быстро ускорить без труда, - читаете мои материалы и ржёте до коликов? Как вам не стыдно! И никто из вас не сказал об этом решении! Старшее поколение такого бы себе не позволило! В СССР с моралью и нравственностью было лучше! ...розмарин, чтоб его... Кажется, отпустило...

(конец шутки с соответствующими эмоциями)

Куча. Именно куча - есть решение проблемы быстрой генерации чисел. Свободная оперативная память - это куча псевдохаотичных данных, которые попадают хаотично в массив сразу же после его инициализации. Остаётся только взять псевдохаос (могут прямо куски файлов ранее открытых попадаться и т.д.) - и создать из него хаос. Инициализировать массив char 512 на 512 символов, инициализировать другой массив 512 символов - и в цикле: в каждый i-й элемент малого массива положить i-й i-й элемент большого. Или 512 минус i-й - для большей хаотичности, но точно в ущерб скорости. Был выбран первый вариант.

После некоторых ошибок в измерении времени, были получены совершенно неочевидные результаты:

- сам цикл for, даже если он с самой быстрой переменной внутри uint8, - невероятный тормоз (или тормозами выступают переменные в квадратных скобках массивов). С ним был получен 4-значный ложноотрицательный результат, который мог убить всю идею;

- после создания отдельных 512 строк с заполнением массива без цикла - был получен результат 237мс/Б. Дальнейшие игры привели к пониманию: чем больше размер массива - тем медленнее скорость работы. При этом, зависимость нелинейная: разница между размерностью 16 и 64 составляет 1.5% времени (200мс/Б и 203мс/Б), но между 512 и 1000 (1024 нельзя: переполнение стека) - 88% (237мс/Б и 446мс/Б);

- 512Б - размер сектора большинства носителей, меньше сектора - тормоза при записи, больше - незначительное увеличение скорости. С учётом отсутствия необходимости соединять мелкие части массивов между собой - именно массив 512Б, несмотря на потерю в скорости 18.5% относительно 16Б, является оптимальным для использования конкретно в этой задаче записи на носители.

Реальная скорость записи SSD M.2 - >2ГБ/с, и данная скорость наверняка уже выросла. Скорость полученного генератора - 16.9ГБ/с. Возможно, с учётом задержек генерации записи на носитель и подготовки к записи, - созданный алгоритм годится для вывода носителя на предел его возможности записи.

Итого, ускорение относительно штатного: 29.2 раза для порций 16-64Б, 24.6 раза для порции 512Б.

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