Многоплатформенная многопоточность: каковы реальные проблемы?

Хотя такая библиотека, как SDL, предоставляет кроссплатформенный API-оболочку для многопоточности, я думаю, что было бы наивно полагать, что это напрямую ведет к простой разработке игр для совершенно разных платформ (настольных и мобильных).

Каков наилучший способ разработки таким способом (с учетом любого кроссплатформенного API потоков), учитывая следующее:

• разное количество ядер
• очень разные возможности обработки на ядро
• Как правило, другая системная архитектура, например, различные задержки для кэша, оперативной памяти и доступа к вводу / выводу

Мне кажется, что единственный способ сделать это - оценить, сколько потоков может быть запущено для каждого устройства, которое вы намереваетесь поддерживать, и выяснить, какой самый низкий общий знаменатель. Тем не менее, это все еще оставляет меня в неведении относительно общего объема доступной пропускной способности обработки. Прав ли я, полагая, что единственный способ сделать это эффективно - это активно разрабатывать мобильное устройство с самыми низкими техническими характеристиками, которое я намерен поддерживать, на протяжении всего процесса разработки? - т.е. самый низкий общий знаменатель? Если это примерно будет достаточно? Или есть что-то большее, чем это?

РЕДАКТИРОВАТЬ: Пожалуйста, могли бы другие предложить дальнейший опыт по этому вопросу, так как я не чувствую, что мой вопрос еще полностью ответил.

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

Хотя такая библиотека, как SDL, предоставляет кроссплатформенный API-оболочку для многопоточности, я думаю, что было бы наивно полагать, что это напрямую ведет к простой разработке игр для совершенно разных платформ (настольных и мобильных).

Легкая разработка игр - конечно. Оптимальной многопоточности нет. Но вам не нужна многопоточность для создания игр. Чтобы сделать высокопроизводительные, это, безусловно, помогает. Но многие отличные игры работают в одном потоке.

Каков наилучший способ разработки таким способом (с учетом любого кроссплатформенного API потоков), учитывая следующее:

• разное количество ядер
• очень разные возможности обработки на ядро
• Как правило, другая системная архитектура, например, различные задержки для кэша, оперативной памяти и доступа к вводу / выводу

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

Однако разложение игровых функций на отдельные задачи является довольно сложным делом и зачастую не стоит усилий, если только вы не уверены, что вам нужна производительность, поэтому большинство даже не будет пытаться ее выполнить.

Некоторое дальнейшее чтение:

http://www.gamasutra.com/view/feature/1830/multithreaded_game_engine_.php - см. раздел «Параллель данных». С помощью этой модели данные разбиваются на несколько идентичных задач и разбиваются на отдельные потоки.

http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/ - довольно плотно, описывает вещи на уровне ОС, а не на уровне игры.

http://drdobbs.com/high-performance-computing/216500409 - не относится к конкретной игре, но совершенно уместно с точки зрения того, как вам нужно разделить задачи.

http://www.itfgaming.com/news/tech-focus-crysis-2-and-the-future-of-cryengine-3 - на полпути к этому интервью есть анекдот о том, как они перешли на систему на основе задач ,

Когда я занимался мобильными играми, мы сначала разработали «золотую» версию (то есть полностью функциональную игру), а затем разделили ее на 3 основные версии (большой экран, средний размер и маленький экран). Эти были далее преобразованы в 11 версий: требовательная графика (чтение требует много памяти / процессора), низкопрофильная и т. Д. (Были также версии для специальной платформы пары).

Самой большой проблемой было (это была моя работа среди других) выделить необходимые платформы и определить эти версии и способы их создания (то есть, большой экран, но низкий профиль должен быть пониженной версией профиля большого экрана / hi или это должно быть Экран среднего размера / профиль сделан большим экраном?).

Конечно, мы помнили об этом, поэтому игры были очень слабо привязаны к размеру экрана.

НТН

[править] Я имел в виду, что вам нужно разделить целевые платформы по разным качествам (т.е. 1 ядро, 2 ядра, 1 ядро, но в два раза быстрее ...) Затем решите, сколько виртуальных целей вы хотите (например, " only one "или" Low, Mid, Hi ") Затем поместите все платформы в соответствующее« качество »и для каждого качества возьмите наименьший знаменатель и« перенесите »код, чтобы он соответствовал этим требованиям (т.е. работает и работает быстро). довольно).

Может показаться, что вы должны сделать это с большим количеством догадок, но вы уже можете найти худшее качество с худшей платформой. Я бы выбрал каждое следующее качество, по крайней мере, «вдвое лучше», чем первое, это, вероятно, не дало бы больше, чем, скажем, 3-4 «качества». Если код перенесен из золотой версии, любую платформу, которая не работает достаточно хорошо, можно просто ретроградить до более низкого «качества», чтобы ускорить его. Любая новая платформа также может быть легко размещена в нужном качестве.

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

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

Если группа платформ, на которой вы собираетесь работать, имеет возможность перечисления оборудования через API, вы можете использовать этот интерфейс для определения максимального количества потоков, которое может обработать система, и использовать его в качестве основы для определения количества потоков в вашем приложении. должен создать. Единственная проблема здесь - найти эти API; переходите ли вы на уровень ОС или ищите стороннюю библиотеку, или кроссплатформенный SDK / API зависит от вас и зависит от платформ, которые вы пытаетесь поддерживать.

Каков наилучший способ разработки таким способом (с учетом любого кроссплатформенного API потоков), учитывая следующее:

different numbers of cores
vastly different processing capabilities per core
A generally different systems architecture with eg. different

задержки для кэша, оперативной памяти и доступа к вводу / выводу

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