Синхронизация алгоритма и wallclock
Mar. 14th, 2021 04:33 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
amaraoОдна из проблем, которая меня очень смущает, это проблема синхронизации времени и алгоритма.
В целом, скорость процессора - это такая внешняя сущность, не относящаяся к алгоритму (и коду). Один и тот же код на разных процессорах будет выполняться за совершенно разное время (банальность, да, но важная).
Вывод на экран, который мы можем считать подобием silky smooth, требует выполнять операции за фиксированное время. Промахнулись? Остались без кадра. Визуально это выглядит как рывок или тормоза.
Т.е. у вас в алгоритме есть некая внешная сущность, которая для алгоритма почти подобна рандому - "сколько времени прошло?". И эта сущность нам говорит, сколько мы можем сделать (в рамках внутренних метрик алгоритма, допустим, "операций").
Нам надо сделать 2 миллиона операций. Это константа runtime'а. А вот сколько кадров это займёт - это некая случайная величина, которую мы не контролируем.
Можно порезать операции на кусочки и выполнять их в цикле, проверяя, "не пора ли заканчивать" (нормально, если обсчёт займёт больше одного кадра, важно не "протупить" в обработке текущего, а продолжить можно будет для следующего). Но на какие кусочки резать? Эмпирика? Микробенчмарк прямо в коде? Автоподстройка по факту пропуска кадра?
Во время моих экспериментов с пистоном я пробовал все их три. Увы, работали плохо.
Была даже четвёртая альтернатива - считать в соседнем треде, и быть готовым "ответить" в любой момент времени накопившимися изменениями. Это, по сути, мало отличается от "отложить рендеринг на следующий фрейм", потому что запросы нужно проверять в event loop'е, и нет никакой разницы, в одном это треде, или в двух. Всё равно работу нужно резать на куски, а какого размера куски не понятно.
Пятая альтернатива пока что звучит интересно: иметь shared buffer, в который один тред пишет, а второй читает. Один тред всё время пишет, второй читает когда нужно. В силу специфики проблемы (попкисельный рендеринг) нет разницы между "чтением в середине записи" и "откладыванием половины работы на следующий тик".
Я уже себя ругаю (ещё раз) за то, что я это делаю, но, допустим, я попробую это. С алгоритмической точки зрения это наиболее разумная идея (мы считаем, не думая про читателя, т.е. просто считаем).
Заодно, познакомлюсь с тем, как шарить mut-память в rust'е между тредами. (Да, я знаю, что это instant-UB, но уж очень соблазнительная идея).
В целом, скорость процессора - это такая внешняя сущность, не относящаяся к алгоритму (и коду). Один и тот же код на разных процессорах будет выполняться за совершенно разное время (банальность, да, но важная).
Вывод на экран, который мы можем считать подобием silky smooth, требует выполнять операции за фиксированное время. Промахнулись? Остались без кадра. Визуально это выглядит как рывок или тормоза.
Т.е. у вас в алгоритме есть некая внешная сущность, которая для алгоритма почти подобна рандому - "сколько времени прошло?". И эта сущность нам говорит, сколько мы можем сделать (в рамках внутренних метрик алгоритма, допустим, "операций").
Нам надо сделать 2 миллиона операций. Это константа runtime'а. А вот сколько кадров это займёт - это некая случайная величина, которую мы не контролируем.
Можно порезать операции на кусочки и выполнять их в цикле, проверяя, "не пора ли заканчивать" (нормально, если обсчёт займёт больше одного кадра, важно не "протупить" в обработке текущего, а продолжить можно будет для следующего). Но на какие кусочки резать? Эмпирика? Микробенчмарк прямо в коде? Автоподстройка по факту пропуска кадра?
Во время моих экспериментов с пистоном я пробовал все их три. Увы, работали плохо.
Была даже четвёртая альтернатива - считать в соседнем треде, и быть готовым "ответить" в любой момент времени накопившимися изменениями. Это, по сути, мало отличается от "отложить рендеринг на следующий фрейм", потому что запросы нужно проверять в event loop'е, и нет никакой разницы, в одном это треде, или в двух. Всё равно работу нужно резать на куски, а какого размера куски не понятно.
Пятая альтернатива пока что звучит интересно: иметь shared buffer, в который один тред пишет, а второй читает. Один тред всё время пишет, второй читает когда нужно. В силу специфики проблемы (попкисельный рендеринг) нет разницы между "чтением в середине записи" и "откладыванием половины работы на следующий тик".
Я уже себя ругаю (ещё раз) за то, что я это делаю, но, допустим, я попробую это. С алгоритмической точки зрения это наиболее разумная идея (мы считаем, не думая про читателя, т.е. просто считаем).
Заодно, познакомлюсь с тем, как шарить mut-память в rust'е между тредами. (Да, я знаю, что это instant-UB, но уж очень соблазнительная идея).
no subject
Date: 2021-03-14 07:23 pm (UTC)no subject
Date: 2021-03-14 07:37 pm (UTC)Собственно, я это могу и так сказать, в целом. В игрушках, если ты в фрейм не успел посчитать, ты роняешь fps. "Ронять данные" можно, но это какой-то супер-хай-энд в стиле "уменьшения разрешения в halo".
А у меня немного другой характер нагрузки. Я рисую долго (десятки фреймов) и мне нужно показывать частично просчитанное (сколько есть), с минимальным объёмом накладных расходов.
См следующий пост с atomic/relaxed. Пока что это самое многообещающее (как с точки зрения скорости, так и с точки зрения API у рисующей библиотеки).