Comments 10
forceinline — наше все!
Вообще, это конечно колхоз.
Обфускацию должен делать компилятор.
Спасибо, воспринимайте это как POC, для людей кто не хочет модифицировать конкретный backend LLVM :)
Впрочем, не всегда можно скомпилять себе тулчейн.
Я тоже этим всем занимаюсь.
Часто приходится инлайнить обфусцированный код для создания строк, при помощи forсeinline и alloca.
В коде это выглядит как sprintf(buf, CSTRA(«top secret»), ...);

Заинлайненый alloca в цикле — мой любимый баг :)
А какой смысл использования ГСПЧ, если функция xorshift256_next не сохраняет состояние? Т.е. получается, что каждый следующий вызов RND никак не зависит от предыдущего — при каждом новом вызове просто инициализируется новый ГПСЧ, который генерирует одно число. Не проще ли напрямую использовать хэш от __COUNTER__ и __TIME__?
Можно делать и так как вы говорите, но качество рандома будет хуже чем у xorshift256, это основная причина почему сделано именно так, можете провести эксперимент с TestU01 если есть возможность и интерес. Так же посмотрите макрос SEED в проекте.
Насколько я понимаю, при использовании этого (как и многих других) ГПСЧ, каждый вызов next() должен использовать состояние, сохраненное предыдущим вызовом. Только в этом случае можно говорить о какой то случайной последовательности и, соответственно, ее свойствах.
Здесь же при каждом вызове RND генерируется новое состояние с помощью этого макроса SEED, которое потом никуда не сохраняется и соответственно при следующем вызове xorshift256_next() никак не используется. Т.е. каждое новое случайное число определяется новым SEED и зависит от него, а не от свойств ГПСЧ.
avdx, Вы правильно считаете, но наличие сохраненного состояния не гарантирует вам хорошей рандомизации если за основу взят неправильный принцип его генерации, состояние — это только одна важная часть PRNG. Передо мной не стояла задача сохранять стейт xorshift256, в данном случае просто получить вменяемые compile time значения, чтобы не получать повторения одних и тех же инструкций на большОм количестве операций.
Задача понятна. Но генерируемая таким образом последовательность (назовем ее X), не является последовательностью, генерируемой указанным ГПСЧ, а является последовательностью, полученной из первых чисел последовательностей, генерируемых разными ГПСЧ, инициализированными случайным образом. Соответственно нельзя утверждать, что X обладает свойствами последовательностей, генерируемых данным ГПСЧ. Тогда какой смысл в его использовании вообще?
Я думаю, если сгенерировать тестовую последовательность описанным способом (без сохранения состояния), то указанный в статье тест она пройдет не лучше, чем последовательность, сгенерированная хэш функцией, используемой для генерации состояний. Поэтому я и написал, что проще использовать сразу результат хэш функции. Хотя возможно у этой хэш функции случайность вообще плохая и присутствуют какие то явные патерны, тогда первое число, генерируемое ГПСЧ, действительно может обладать большей случайностью, но все же вся последовательность не будет обладать свойствами, обеспечиваемыми этим генератором.

Использовав xorshift Dinisoid пальнул из пушки по воробьям и устроил пытки MSVC. Для подобной задачи хватило-бы простейшего миксера. Причем использование макросов, а не новомодных constexpr, доставило бы компилятору намного меньше мук ;)


Тем не менее, более-менее приличный ГПСЧ использованный подобным образом (без состояния, с инициализацией от натуральной последовательности) пройдет все упомянутые тесты, как и более-менее приличная хэш-функция.

Only those users with full accounts are able to leave comments. Log in, please.