Здравствуйте, kaa.python, Вы писали:

I>>Микросекунды на что именно? Нужно считать весь цикл вычисления туда-сюда включая шансы потершать по дороге кванты времени по любой причине.

KP>Я толи что-то не понимаю, толи ты считаешь что идеальное с точки зрения производительности приложение — это приложение работающее в один поток. С такой фольмулировкой я не согласен.

С тз. UI ты не получаешь бенефита, если выталкиваешь мелкие операции в воркер, т.к. в зависимости от загрузки системы у тебя растет латентность. Ты что, решил что все ядра свободны и только и ждут твоего воркера?

I>>Для примера — простая задержка Sleep(1) реально зависит от загрузки системы. Я тут много лет назад выкладывал замеры. В зависимости от загрузки системы этот Sleep(1) выполняется от 1 кванта до 15 секунд.

KP>Если у тебя Sleep(1) занимает 15 секунд, то уже вообще без разницы где и как ты будешь считать — система и так не отзывается.

Это важный факт — реальная задержка зависит от загрузки. Если в фоне работает GC, еще пару-тройку экземпляров этого же приложения, крайне странно думать, что воркеру ктото просто так даст квант времени. 15с это вырожденный случай. Но из 25 кадров сделать 5 вполне себе реально.

I>>Та же проблема и при выталкивании вычислений в другой поток — пропускная способность растет при наличии ядер, но растет и латентность.

KP>Нет такой проблемы. Есть закон Амдала и это единственное ограничение, которое у тебя возникает в общем случае. Дальше есть нюансы типа а какая у тебя модель памяти и прочее, но это уже небольшие уточнения, не более того. Ну а латентностью, возникающей при переключении контекста можно пренебречь как ничтожно маленькой величиной.

Ага, все ядра заняты, но для твоего воркера всенепременно найдется квант времени

Здравствуйте, kaa.python, Вы писали:

I>>Микросекунды на что именно? Нужно считать весь цикл вычисления туда-сюда включая шансы потершать по дороге кванты времени по любой причине.

KP>Я толи что-то не понимаю, толи ты считаешь что идеальное с точки зрения производительности приложение — это приложение работающее в один поток. С такой фольмулировкой я не согласен.

С тз. UI ты не получаешь бенефита, если выталкиваешь мелкие операции в воркер, т.к. в зависимости от загрузки системы у тебя растет латентность. Ты что, решил что все ядра свободны и только и ждут твоего воркера? Наоборот, потоки ставятся в очередь и время выделяется то одному, то другому. Потоки в очереди = латентность.

I>>Для примера — простая задержка Sleep(1) реально зависит от загрузки системы. Я тут много лет назад выкладывал замеры. В зависимости от загрузки системы этот Sleep(1) выполняется от 1 кванта до 15 секунд.

KP>Если у тебя Sleep(1) занимает 15 секунд, то уже вообще без разницы где и как ты будешь считать — система и так не отзывается.

Это важный факт — реальная задержка зависит от загрузки. Если в фоне работает GC, еще пару-тройку экземпляров этого же приложения, крайне странно думать, что воркеру ктото просто так даст квант времени. 15с это вырожденный случай. Но из 25 кадров сделать 5 вполне себе реально.

I>>Та же проблема и при выталкивании вычислений в другой поток — пропускная способность растет при наличии ядер, но растет и латентность.

KP>Нет такой проблемы. Есть закон Амдала и это единственное ограничение, которое у тебя возникает в общем случае. Дальше есть нюансы типа а какая у тебя модель памяти и прочее, но это уже небольшие уточнения, не более того. Ну а латентностью, возникающей при переключении контекста можно пренебречь как ничтожно маленькой величиной.

Ага, все ядра заняты, но для твоего воркера всенепременно найдется квант времени Если потоков больше, чем ядер, потоки в очереди на исполнение. Вот это и есть латентность.