| Численный хаос: генераторы друг в друге (03.11.2026). |
|
| 2026 - Ноябрь | |||
| 03.11.2026 18:39 | |||
Если рассматривать меня как персонажа игры 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 ) |