![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
systemd vs sudo
Mar. 12th, 2021 03:22 pmЯ мечтаю о моменте, когда systemd сожрёт sudo. Если timesyncd - это спорная идея, то systemd-elevated или как там его назовут - это будет лучший день в системном администрировании.
Mar. 12th, 2021
Игрища с рандомом
Mar. 12th, 2021 03:26 pmЯ поправил функцию рандома до 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)
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