Оптимизация многопоточного приложения

[Kultura]

Изучаю потоки на примере простенькой игрушки - пакмене. Возникли проблемы со скоростью приложения: процессор загружается на ~100% и сама игрушка тормозит 

Есть 5 разных существ (пакмен и враги), для каждого запускается по отдельному потоку. В каждом потоке - бесконечный цикл, в котором несколько проверок плюс изменение координаты, а для врагов еще поиск пути (пока что почти пустой). После изменения координаты - Sleep (creatureSpeed).
С одним таким потоком (один пакмен бегает по карте) загрузка процессора - 30-40%. А с 5-ю еще вдобавок скорость перемещения существ падает (видимо к Sleep-у добавляется не такое уж и маленькое время расчетов)

В общем, вопрос: как сделать правильно?

[Вад]

Kultura, если нужно делать движения с некоторой частотой - то для такого есть таймеры. И если sleep слишком маленький - определённо, будут проблемы с загрузкой.

[RXL]

Kultura, лучше такой подход: поток, исполняемый по таймеру; после появления события таймер останавить; обработка объектов выполняется последовательно; перерисовать картинку; в конце цикла таймер запустить.

[sss]

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

[Kultura]

RXL, т.е., например, таймер изменяет какой-нибудь флаг, а в потоке бесконечным циклом этот флаг опрашивается. Когда флаг активный - выполняется обработка объектов, таймер перезапускается? Это как я понял, или речь идет о чем-то другом?

Вад, sss, все таки надо сделать именно с потоками (в обучающих целях). Но, получается, многопоточность только проигрывает на одноядерных процессорах?

[Антон (LogRus)]

просто вы не умеет их готовить.

я пока из причин для подобного поведения вижу только:
1. маленький слип
2. не очень удачная реализация отрисовки.

и профайлером пройдись по коду.
или самописным или нормальным VTune скачай триальный месяцок погонять.

[Kultura]

LogRus, Sleep (10), проверка проходимости, перемещение на 1 пиксель, обновление экрана, Sleep (10)...

[Kultura]

2. не очень удачная реализация отрисовки.

Закомментил отрисовку карты (поле 20 на 20, например, простые прямоугольники), тормоза ушли. Каждый из 5-ти потоков перерисовывал всю карту 

[Антон (LogRus)]

я бы завёл один поток для отрисовки

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

[RXL]

RXL, т.е., например, таймер изменяет какой-нибудь флаг, а в потоке бесконечным циклом этот флаг опрашивается. Когда флаг активный - выполняется обработка объектов, таймер перезапускается? Это как я понял, или речь идет о чем-то другом?

Вад, sss, все таки надо сделать именно с потоками (в обучающих целях). Но, получается, многопоточность только проигрывает на одноядерных процессорах?

Забудь о бесконечных циклах ожидания - это бесполезная трата процессорного времени.

[sss]

Вад, sss, все таки надо сделать именно с потоками (в обучающих целях). Но, получается, многопоточность только проигрывает на одноядерных процессорах?

Проигрывает кому? Пакману в однопоточном DOS варианте на таком же процессоре? Конечно... Только программировать сложнее.

[Антон (LogRus)]

Забудь о бесконечных циклах ожидания - это бесполезная трата процессорного времени.

а если поток спит в этом цикле в ожидании события?

[Serg79]

Kultura, главная игровая петля - это в том или ином виде (99% всех игр):

Код:

while (1)
{
    Indut();  // получение данных с клавиатуры, миши и т.п.
    Update(); // ИИ, передвижение объектов и т.п.
    Draw();   // Формирование картинки и вывод ее на экран
}

И я думаю Ты прекрасно понимаешь, что начинать рисовать картинку прежде чем будет завершено передвижение всех объектов не имеет смысла.

Если ты двигаешь объекты [Update()] в отдельном потоке, то должен каким то способом проинформировать основной, что все передвижения завершены и можно рисовать картинку [Draw()].

А тот способ который используешь Ты, каждый поток рассчитывает положение своего объекта и потом сам же его рисует это самое плохое что можно придумать.

P.S. 80% всего времени работы программы занимает перенос картинки на экран.

[Kultura]

Serg79, это очень интересная тема - структура игровых приложений. Хотел бы узнать подробнее.
На геймдеве про это ничего нет, есть только отдельные эллементы. Слышал, даже есть специальные игровые паттерны. Где бы почитать?

Только недавно узнал, что используются бесконечные циклы и то случайно.

У меня сразу 2 вопроса.
По Input (): если в этой фунции мы опрашиваем состояние клавиш, а во время Sleep () была нажата кнопка - ее мы пропускаем (а может быть, наоборот во время нажатия цикл несколько раз прокрутится)?
По Draw (): если в игре серьезная графика (я пока что о 2д и gui), слишком часто обновлять все не получится. Но персонажи движутся и окружение около них должно обновляться. Как эта проблема решается?

[Serg79]

По Input (): если в этой фунции мы опрашиваем состояние клавиш, а во время Sleep () была нажата кнопка - ее мы пропускаем (а может быть, наоборот во время нажатия цикл несколько раз прокрутится)?

Обычно за секунду кнопки и мышь опрашивается ~30 раз, я не думаю, что Ты способен барабанить по кнопкам с частотой превышающей 30 Гц.

По Draw (): если в игре серьезная графика (я пока что о 2д и gui), слишком часто обновлять все не получится. Но персонажи движутся и окружение около них должно обновляться. Как эта проблема решается?

Слишком часто обновлять картинку то же не надо. Вполне комфортно для глаз будет если Ты картинку будешь обновлять 30 раз в секунду, 33 ms. для построения картинки более чем достаточно да же на PII.

[lapulya]

Kultura,
По Input размер sleep вообще никакого отношения к моменту нажатия клавиши не имеет (ну почти, если таймаут не гигантский).
По Draw:
1. в наше время (на самом средненьком/простеньком компе) никаких проблем с "очень частым" обновлением нет
2. игр пишутся так, что никакой задержки (sleep) в них нет или почти нет, т.е. она минимальна (кто как), просто fps будет больше. Более того точность sleep примерно 50 мс, поэтому аргумент менее 50 ставить в sleep бесполезно (есть гораздо более точные таймеры)
 Serg79,
на самом деле, делать так
while (1)
{
    Indut();  // получение данных с клавиатуры, миши и т.п.
    Update(); // ИИ, передвижение объектов и т.п.
    Draw();   // Формирование картинки и вывод ее на экран
}
достаточно прогрессивно (не совсем так, но смысл именно в том, что отрисовка приходится на каждый "тик"), именно так разрабатываются современные серьезные системы реального времени (игрушки типичный представитель), дело в том, что для игры, как и для любой программы приоритеным является логика, а не отображение. В случае, когда расчет мира занимает много времени (ну такой момент, когда все во всех стреляют и т.д.) при последовательном отображении на экран картинки фпс будет катострофически мал (отрисовка само по себе очень не быстрая операция) и скорость обсчета мира просто ляжет. Поэтому отрисовка, в такие "сложные моменты", иногда пропускается (ничего страшного если мы будем отображать не каждый кадр а через кадр и т.д.).
Пропуск может осуществляться разными способами (как последовательной обработкой мира и отрисовки, так и параллельной)