Численный хаос: генераторы друг в друге (03.11.2026). Печать
2026 - Ноябрь
03.11.2026 18:39
Save & Share
Если рассматривать меня как персонажа игры Warhammer 40000 - можно наблюдать, как всё больше происходит падение личности и отказ от Имперской гвардии в сторону армии Хаоса. Руби на части! Уничтожайте слабых! Бей их в спину! ...ересь... Но так сладка.

Ранее создавал мирные программы - теперь воинственные. Вместо защиты железа - борьба с CPU. Вместо упорядочивания информации - сейчас увлёкся её энтропией. Этот материал - распространение энтропии на всё большие расстояния, и повышение её коэффициента Шеннона. Ну и проктология подкинула проблем в своё время: больше крови кровавому богу!


Всё началось с печенегов и половцев. Пять материалов (раз, два, три, четыре, пять), посвящённых генерации мусора, отражают одну и ту же проблему: стандартные генераторы сред программирования слабы, что в 2002 (BCB v.6.0 - 68МБ/с), что в 2023 годах (в Qt v.5.15.2 - ещё меньше). Надо писать свои.

Ну и написал:
- сначала написал ускоренный генератор unsigned int со скоростью 1.05ГБ/с + 1.08ГБ/с (со входным максимумом и без), дополнив его позже генератором long double 0.8ГБ/с;
- потом использовал один из этих генераторов для создания репозитория чисел и манипуляций с ними - скорость генерации хаоса выросла до 3.36ГБ/с и сохранила высокий коэффициент Шеннона 7.5 из 8;
- в погоне за скоростью современного алгоритма XORShift128+ 24ГБ/с, решил создать массив 256 результатов предыдущего генератора - и использовать его 256! вариантов для генерации с теоретической скоростью 134.4ГБ/с;
- ну и изобрёл заново функцию высшего порядка - в контексте генератора мусора. Новая ли это идея? А хрен её знает;
- после создания второй обёртки-генератора для изначального самописного генератора - надо бы это всё сделать в роли класса с вызовами всех возможных генераторов и их обслуги. Это пока мечты; но если функции высшего порядка сработают, - кто-то уделает Себастьяно Винью.

(добавлено 04.11.2026) Создание класса - будет очень укороченным или вообще накроется: любая попытка улучшить алгоритм в сторону удобства для использующего его программиста - приводит к критическому уменьшению скорости. Пишешь лишний if с проверкой самого быстрого bool - 2-3% скорости потерял. Сделал, вместо выходного unsigned int без параметров, void с 2 входными параметрами массива и его размера - скорость падает в 3.5 раза. То есть, я не могу сделать удобство для программиста в ущерб скорости: пусть он сам как-нибудь - и это лучше: вдруг, ему надо всего 255 значений, - напишет сам for с самым быстрым __int8, а не с универсальным моим более медленным unsigned int.

(спустя несколько часов) Опаньки... 6.72ГБ/с...

...но, может быть, можно ещё быстрее?..
Обновлено ( 04.11.2026 17:21 )