Обсуждение многопоточности (MT)

[Blackfyre]

2 hours ago, vvm13 said:

Как можно сделать самый быстрый интерфейс доступа к накопителям сделать узким местом? Причём, по-хорошему, данные уже должны были быть закешированы.

Да легко. У накопителя все равно задержка в миллисекундах, т.е. на 3 порядка выше чем у памяти. Т.е. достаточно читать буквально один байт и самое главное ждать пока он прочтется, чтобы получить такие вот пики. Правда, в силу того что проблема не у всех, вообще не факт, что проблема доступе к накопителю.

То же горячее подключение устройств у ED победить не получилось, или вот ты сам выше приводил пример с мышкой(!). Возможна ситуация когда такая злобная "мышь" влият на очередность завершения функций и где-то возникает ожидание (висит несколько миллисекунд какой-нибудь std::thread::join()). Что-то сказать точнее может быть получится если запустить профайлер в проблемной конфигурации и то не факт, потому что профайлер сам может оказывать влияние.

[vvm13]

42 minutes ago, Blackfyre said:

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

Но ведь делать это в другой нити просто напрашивается, причём даже в так называемой "Single Thread"-программе. И ведь совсем недавно все на НЖМД через SATA сидели.

(C USB-устройствами другая нить для них тоже напрашивается).

[Blackfyre]

38 minutes ago, vvm13 said:

Но ведь делать это в другой нити просто напрашивается, причём даже в так называемой "Single Thread"-программе. И ведь совсем недавно все на НЖМД через SATA сидели.

(C USB-устройствами другая нить для них тоже напрашивается).

Если бы чтение было не асинхронным (в отдельном потоке), то тормозило бы всегда и у всех. Но рано или поздно наступает момент ожидания завершения этого чтения(или записи) и может тормозить не у всегда и не всегда, ибо у кого то уже все прочиталось, у кого-то нет. В общем, асинхронность помогает избежать простоев, но не гарантирует их отсутствие.

Но мне кажется у muffler проблема не в этом(не в скоростях чтения/записи), больно предсказуемые пики у него. У меня такие же при включенном хотплаге всегда были.

[Rtyer]

В порядке бреда. А может оторваться от ущербных ПК в сторону современных серверов? Сейчас выпускают компактные офисные серверы для ИИ. Там мощные видеочипы, спаренные процессоры. Конечно дороже ПК, но зато потянет все, что надо, при правильной адаптации движка...

Edited March 23, 2023 by Rtyer

[vvm13]

40 minutes ago, Blackfyre said:

В общем, асинхронность помогает избежать простоев, но не гарантирует их отсутствие.

Я не знаю, как и что. Но дёрганная картинка и дёрганная реакция - это задержка в главном цикле.

Положим, что потенциально тормозящие операции (чтение диска, опрос мышей и джойстиков) находятся во вспомогательных нитях и кладут результаты в очереди, а главный цикл берёт результаты оттуда. В такой схеме эти потенциально тормозящие операции в принципе затормозить главный цикл не могут (считая, что обращение к внутренней очереди в программе практически бесплатно по отношению ко всему остальному). Да, какие-то текстуры могут отрисоваться чуть позже, или программа среагирует на дойстик чуть позже, но на FPS влияние диска и джойстика должно быть 0.

В реальном DCS, наверное, чуточку по-другому. Возможно, с идеей, что обращение к джойстикам и так должно быть асинхронным и т.п.

[biotech]

@Rtyer У меня сейчас в т.н. "тяжелых" миссиях проц 13700к загружен процентов на 10-15. Какие серверы, зачем???

Зато 24 гига памяти на 4090 сжираются в dcs полностью, и здесь где-то давнишняя тема есть, в которой @Taz1004 даже выяснил почему жор видеопамяти происходит и предлагал решение. Ну и всё... Остаётся надеяться, что где-то там выпекается новый граф. движок и нужно только подождать. Не железом единым.

Edited March 23, 2023 by biotech

[muffler]

1 час назад, Blackfyre сказал:

Но мне кажется у muffler проблема не в этом(не в скоростях чтения/записи), больно предсказуемые пики у него. У меня такие же при включенном хотплаге всегда были.

Что такое хотплаг и как его выключить?

[Blackfyre]

17 minutes ago, muffler said:

Что такое хотплаг и как его выключить?

Горячее подключение, чтобы можно было джойстики на ходу подключать/отключать. Включается/выключается кнопкой в настройках управления:

Edited March 23, 2023 by Blackfyre

[Blackfyre]

41 minutes ago, vvm13 said:

Я не знаю, как и что. Но дёрганная картинка и дёрганная реакция - это задержка в главном цикле.

Положим, что потенциально тормозящие операции (чтение диска, опрос мышей и джойстиков) находятся во вспомогательных нитях и кладут результаты в очереди, а главный цикл берёт результаты оттуда. В такой схеме эти потенциально тормозящие операции в принципе затормозить главный цикл не могут (считая, что обращение к внутренней очереди в программе практически бесплатно по отношению ко всему остальному). Да, какие-то текстуры могут отрисоваться чуть позже, или программа среагирует на дойстик чуть позже, но на FPS влияние диска и джойстика должно быть 0.

В реальном DCS, наверное, чуточку по-другому. Возможно, с идеей, что обращение к джойстикам и так должно быть асинхронным и т.п.

Я бы не делал ввод/вывод на очередях, и не видел что-бы кто-то так делал. Потому что тогда эти самые очереди будут камнем преткновения, ибо атомарность записи/чтения в них придется обеспечивать во избежании спецэффектов. Зато какие-нибудь тяжелые вычислительные задачи (ИИ например) вполне неплохо могут лечь на архитектуру с очередями.

Еще в таких оптимизациях всегда приходится выбирать между throughput(производительность, читай FPS) и latency (задержка, читай количество времени на формирование кадра). И есть подозрение, что в случае игры всегда выбирают первое.

[muffler]

29 минут назад, Blackfyre сказал:

Горячее подключение, чтобы можно было джойстики на ходу подключать/отключать. Включается/выключается кнопкой в настройках управления:

 

Не помогло.

[biotech]

@muffler TacView не установлен в DCS? или что нибудь еще, выполняющее экспорт.

[vvm13]

1 hour ago, Blackfyre said:

Я бы не делал ввод/вывод на очередях, и не видел что-бы кто-то так делал. Потому что тогда эти самые очереди будут камнем преткновения, ибо атомарность записи/чтения в них придется обеспечивать во избежании спецэффектов. Зато какие-нибудь тяжелые вычислительные задачи (ИИ например) вполне неплохо могут лечь на архитектуру с очередями.

Еще в таких оптимизациях всегда приходится выбирать между throughput(производительность, читай FPS) и latency (задержка, читай количество времени на формирование кадра). И есть подозрение, что в случае игры всегда выбирают первое.

Без (сокрытой внутри реализации) атомарности очереди бессмысленны, но здесь они не будут камнем преткновения, потому что очередей очень мало (три (две для дисков плюс одну на джойстики) или даже 2*M (количество дисков) + N (количество джойстиков)), к каждой обращаются два потока максимум, обращения очень редки (максимум пара-тройки сотен раз в секунду - это практически не нагрузка, а безделье). И обеспечивается "моей" схемой прежде всего throughput, то бишь отсутствие задержек в главном цикле.

Ну, джойстикам могут сойти просто (защищённые) переменные, совместно используемые потоками, тогда как для дисков я воображаю две очереди - в одну главный цикл кладёт команду, а из второй забирает результат.

Но неважно. Это просто то, что сразу пришло мне в голову и пока что кажется неплохим. Если профессионалы делают по-другому и лучше, то тем лучше. Только откуда же тогда фризы?

[muffler]

1 час назад, biotech сказал:

@muffler TacView не установлен в DCS? или что нибудь еще, выполняющее экспорт.

Установлен.

[Blackfyre]

52 minutes ago, vvm13 said:

Без (сокрытой внутри реализации) атомарности очереди бессмысленны, но здесь они не будут камнем преткновения, потому что очередей очень мало (три (две для дисков плюс одну на джойстики) или даже 2*M (количество дисков) + N (количество джойстиков)), к каждой обращаются два потока максимум, обращения очень редки (максимум пара-тройки сотен раз в секунду - это практически не нагрузка, а безделье). И обеспечивается "моей" схемой прежде всего throughput, то бишь отсутствие задержек в главном цикле.

Ну, джойстикам могут сойти просто (защищённые) переменные, совместно используемые потоками, тогда как для дисков я воображаю две очереди - в одну главный цикл кладёт команду, а из второй забирает результат.

Но неважно. Это просто то, что сразу пришло мне в голову и пока что кажется неплохим. Если профессионалы делают по-другому и лучше, то тем лучше. Только откуда же тогда фризы?

Преткновение будет не из-за количества очередей, а из-за того что у тебя минимум два потока будут постоянно пытаться в них читать и писать, т.е. внутри очереди будет происходить синхронизация, а это дорого, но более предсказуемо. Вот из-за дороговизны синхронизации у тебя общая производительность уменьшиться (throughput), зато может быть упадет максимальная задержка(latency).

Плюс некоторые задачи, тебе вот прямо точно надо выполнить, чтобы отрисовать кадр, иначе будет фигня, которая нам не понравится.

 

[kalter72]

21 час назад, SL PAK сказал:

В моей системе нет накопителей M2.

Я имел в виду освещение способа "переноса темпа"

[biotech]

1 час назад, muffler сказал:

Установлен.

попробовать отключить и посмотреть. были с ним проблемы.

[SL PAK]

9 минут назад, kalter72 сказал:

Я имел в виду освещение способа "переноса темпа"

https://remontka.pro/move-temporary-files-folder-windows/

То что это помогает, никто тут не подтверждал. 

[vvm13]

1 hour ago, Blackfyre said:

Преткновение будет не из-за количества очередей, а из-за того что у тебя минимум два потока будут постоянно пытаться в них читать и писать,

Не минимум, а максимум. Есть главный поток, которого обслуживают вспомогательные. Между собой вспомогательные потоки не общаются. И этих вспомогательных потоков довольно мало. Разумно выделить на каждый вспомогательный поток очередь или две.

Положим, работаем с файлами. Очередей будет две.

Для главного цикла (в главном потоке):
* если нам нужно прочитать файл, пишем сообщение ("прочитай мне то-то") и кладём в очередь O1.
* проверяем очередь О2, и если там есть данные, забираем и используем их

Для цикла во вспомогательном потоке"
* проверяем очередь O1. Если там нет сообщения, идём спать на, скажем, 1/1000 секунды. Иначе обрабатываем сообщение, читаем файл, данные кладём в O2.

Для какой-нибудь высоконагруженной СУБД такой подход не годится, но для игры должно быть как раз. Один поток обращается к очереди с частотой FPS (про 200 можно только мечтать), другой не более 1000 раз в секунду, между собой они будут "сталкиваться" очень редко.

[Blackfyre]

2 hours ago, vvm13 said:

Не минимум, а максимум. Есть главный поток, которого обслуживают вспомогательные. Между собой вспомогательные потоки не общаются. И этих вспомогательных потоков довольно мало. Разумно выделить на каждый вспомогательный поток очередь или две.

Положим, работаем с файлами. Очередей будет две.

Для главного цикла (в главном потоке):
* если нам нужно прочитать файл, пишем сообщение ("прочитай мне то-то") и кладём в очередь O1.
* проверяем очередь О2, и если там есть данные, забираем и используем их

Для цикла во вспомогательном потоке"
* проверяем очередь O1. Если там нет сообщения, идём спать на, скажем, 1/1000 секунды. Иначе обрабатываем сообщение, читаем файл, данные кладём в O2.

Для какой-нибудь высоконагруженной СУБД такой подход не годится, но для игры должно быть как раз. Один поток обращается к очереди с частотой FPS (про 200 можно только мечтать), другой не более 1000 раз в секунду, между собой они будут "сталкиваться" очень редко.

Почему между собой вспомогательные не общаются? Допустим я бы точно попробовал бы вынести ИИ в отдельный поток и ему может понадобиться читать файлы/сеть или еще что-нибудь. Но это собственно не очень важно.

В общем, ты пытаешься решить не ту проблему, что будет делать главный поток если ему нужен какой-то файл вот прямо сейчас, а он еще не прочитан? То что ты описал, делается несколько по другому - через пулы потоков и future в качестве результата, хотя идея та же, только очередь там из функций, а не команд, что позволяет не делать принудительный простой во вспомогательных потоках вообще никогда. И ооочень в теории можно попытаться написать код, который никогда не будет ждать результата, а всегда делать что-то полезное. На практике так если и могут, то буквально десятки людей на этой планете(хотя есть реактивное программирование, но в него тоже могут не только лишь все). За исключеним некоторых "простых" случаев. 

В случае высоконагруженной СУБД очереди как раз таки в полный рост используются, только у них там цель другая - снизить мгновенную нагрузку и/или распределить между шардами. В целом очереди используются когда у нас есть много каких-то запросов и ограниченный ресурс их выполнения.  (Еще очереди типа Kafka или RabbitMQ используют в качестве интеграционной шины, но они там на стероидах, но идея та же).

[vvm13]

9 hours ago, Blackfyre said:

Допустим я бы точно попробовал бы вынести ИИ в отдельный поток

Но это к делу не относится. У нас есть факты подтормаживания DCS, как-то связанные с накопителями, и есть факты подтормаживания каких-то игр, связанных с частотой опроса мыши. Я порассуждал на тему "игры, гарантированные от влияния этих факторов возможны". Про остальное (скажем, есть очереди, а есть очереди - называется одинаково, но контекст очень разный) совершенно не по теме.

А что там *реально* происходит...

 

[Blackfyre]

50 minutes ago, vvm13 said:

А что там *реально* происходит...

Мы не знаем, ED скорее всего тоже, а самое грустное, что это нормально Ну и я придерживаюсь мнения, что сами по себе накопители не виноваты. Хотя сразу после обновления на MT у меня винда стала загружаться строго со второго раза, а в первый раз падает в синий экран на драйвере ntfs.sys... Совпадение?

Еще меня беспокоит, то что DCS в меню жрет одно ядро всегда (вечный цикл?). Любителям поковырять редактор миссий мешает.

[Serg66RUS]

Кто-нибудь проверял производительность с НТ и без? На 6-8 ядерном проце.

[SL PAK]

На 4 ядрах включение HT сильно ухудшало производительность. Тестировал при появлении MT в бете.

[muffler]

21 час назад, biotech сказал:

попробовать отключить и посмотреть. были с ним проблемы.

Отключил. Эффекта нет.

[Rokman]

 У меня 6 ядерный процессор.Сегодня выключу Hyper-Threading и отпишусь,кому интересно.Только вот выключение HT как повлияет на другие игры...

Edited March 24, 2023 by Rokman