systemd vs sudo
Я мечтаю о моменте, когда systemd сожрёт sudo. Если timesyncd - это спорная идея, то systemd-elevated или как там его назовут - это будет лучший день в системном администрировании.
2021-03-12
Entry tags:
Игрища с рандомом
Я поправил функцию рандома до 1ns (для u8). Удивительно, но ключевым решением была не борьба с ковейером процессора, а #[inline(always)], с u128 в качестве базового типа. (Как всегда, спасибо Олегу).
Проблема в том, что этого не достаточно. 2560*1440*60*4 - это 884 миллиона в секунду (1.1 ns), и это не считая всего остального (например, процесса копирования в текстуру и отправки текстуры в GPU). В целом, чтобы получить желаемые 200 fps (fade in/out примерно столько показывает) нужно делать 339 ps на один байт (плюс запас на вывод), что опасно близко к одному тику процессора (270ps/тик).
Я сейчас подошёл к интереснейшей микрозадачке rust'а (как из [u8] сделать [u128] бесплатно, т.е. с помощью typecast'а), и если мы перейдём на u128, то требования сильно упростятся. u128 - это аж 4 полных пиксела, т.е. можно иметь аж 5.4 ns на каждый рандом. Вероятнее всего, это и будет решение.
На всякий случай, вот формулы:
1/(2560*1440*200*4)*1000*1000*1000 (время на одну u8 компоненту пиксела для вывода 200 fps на 2560x1440)
1/(2560*1440*200/4)*1000*1000*1000 (время на 4 u32 пиксела для вывода 200 fps на 2560x1440)
Проблема в том, что этого не достаточно. 2560*1440*60*4 - это 884 миллиона в секунду (1.1 ns), и это не считая всего остального (например, процесса копирования в текстуру и отправки текстуры в GPU). В целом, чтобы получить желаемые 200 fps (fade in/out примерно столько показывает) нужно делать 339 ps на один байт (плюс запас на вывод), что опасно близко к одному тику процессора (270ps/тик).
Я сейчас подошёл к интереснейшей микрозадачке rust'а (как из [u8] сделать [u128] бесплатно, т.е. с помощью typecast'а), и если мы перейдём на u128, то требования сильно упростятся. u128 - это аж 4 полных пиксела, т.е. можно иметь аж 5.4 ns на каждый рандом. Вероятнее всего, это и будет решение.
На всякий случай, вот формулы:
1/(2560*1440*200*4)*1000*1000*1000 (время на одну u8 компоненту пиксела для вывода 200 fps на 2560x1440)
1/(2560*1440*200/4)*1000*1000*1000 (время на 4 u32 пиксела для вывода 200 fps на 2560x1440)
Entry tags:
u128
u128 (без всяких доп.трюков) сделало почти чудо, да.
На форуме мне показали bytemuck, позволяющий сделать "запретное" в расте и кастануть [u8] к [u128] с правильным пересчётом размера.
Итог:
2.2ms на полное наполнение 2560х1440 (x4), это 454 раз за секунду, более чем достаточно для практических задач шума.
Собственно, это же подтверждается и практическим замером: 100% шума в каждом кадре даёт 260 FPS.
Итого:
1) u128
2) #[inline(always)]
... И ещё одно доказательство тезиса, что не-многопроцессные оптимизации лучше. От 6 тредов я бы получил максимум 5x улучшение, а тут - 9-кратное, причём, практически, без крупноархитектурных усложнений.
Сам код тут: https://github.com/amarao/sdl_random
На форуме мне показали bytemuck, позволяющий сделать "запретное" в расте и кастануть [u8] к [u128] с правильным пересчётом размера.
Итог:
noise fill 2560x1440 time: [2.2220 ms 2.2227 ms 2.2239 ms]
change: [-88.993% -88.989% -88.984%] (p = 0.00 < 0.05)
Performance has improved.
2.2ms на полное наполнение 2560х1440 (x4), это 454 раз за секунду, более чем достаточно для практических задач шума.
Собственно, это же подтверждается и практическим замером: 100% шума в каждом кадре даёт 260 FPS.
Итого:
1) u128
2) #[inline(always)]
... И ещё одно доказательство тезиса, что не-многопроцессные оптимизации лучше. От 6 тредов я бы получил максимум 5x улучшение, а тут - 9-кратное, причём, практически, без крупноархитектурных усложнений.
Сам код тут: https://github.com/amarao/sdl_random