Почему не делают большие программы (такие как игры) используют загрузки различных потоков? [закрытый]

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

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

Главная причина состоит в том, что, столь изящный, как это звучит, с помощью нескольких потоков в программе, столь сложной, как 3D игра является действительно, действительно, действительно трудной. Кроме того, прежде чем довольно недавнее введение недорогих многоядерных систем, с помощью нескольких потоков не предложило большую часть стимула производительности.

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

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

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

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

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

Что касается игр, я не игровой программист, но мое понимание ситуации - это: 3D игры создают программную модель игрового мира; игроки, враги, объекты, ландшафт, и т.д. Этот игровой мир обновляется на дискретных шагах, на основе количества времени, которое протекло начиная с предыдущего обновления. Так, если 1 мс передал с прошлого раза вокруг игрового цикла положение объекта обновляется при помощи его скорости и прошедшее время для определения дельты (очевидно, физика немного более сложна, чем это, но Вы получаете идею). Другие факторы, такие как AI и входные ключи могут также способствовать обновлению. Когда все закончено, обновленный игровой мир представляется как новый кадр, и процесс начинается снова. Этот процесс обычно происходит много раз в секунду.

, Когда мы думаем об игровом цикле таким образом, мы видим, что механизм на самом деле достигает очень похожей цели к той из поточной обработки. Это имеет много длительных задач (обновляющий физику в мире, обрабатывая ввод данных пользователем, и т.д.), и это производит впечатление, что они происходят одновременно путем разламывания их на маленькие обрабатываемые детали и чередования этих частей, но вместо того, чтобы полагаться на ЦП или операционную систему для управления временем, проведенным на каждом, это делает его сам. Это означает, что может сохранить все различные задачи правильно синхронизируемыми и избежать сложностей, которые идут с реальной поточной обработкой: блокировки, вытеснение, повторно используемый код, и т.д. нет никакой импликации производительности к этому подходу также, потому что, поскольку мы сказали, что одноядерная машина может только действительно выполнить код линейно так или иначе.

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

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

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

Лично я думаю, что мы испытываем необходимость в сдвиге парадигмы и новых инструментах.

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

Теперь, когда многоядерные процессоры отсутствовали некоторое время и главные игровые приставки имеют несколько ядер, это - только вопрос времени перед двухъядерными шоу в минимальном списке системных требований для компьютерных игр.

Вот ссылка на интервью с Orion Granatir от Intel, где он говорит о том, чтобы заставлять разработчиков игр использовать в своих интересах многопоточность.

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

Очень трудно использовать потоки без проблем, и большинство API GUI основано на управляемом событиями кодировании так или иначе. Потоки передают под мандат использование блокировки механизмов, которые добавляют задержку с кодом, и часто что задержка непредсказуема в зависимости от того, кто в настоящее время держит блокировку.

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

Потоки мертвы , детка.

На самом деле, при разработке игр потоки не масштабируются за пределы выполнения очень специализированных задач, таких как работа в сети и загрузка. Системы заданий кажутся единственным путем вперед, учитывая, что системы с 8 процессорами становятся все более обычным явлением даже на ПК. И вы можете в значительной степени гарантировать, что грядущие сверхмногоядерные системы, такие как Intel Larrabee , будут основаны на системе заданий.

Это было несколько болезненным осознанием в проектах Playstation3 и XBOX360, и теперь кажется, что даже Apple вскочил на борт со своей «революционной» Grand Central Dispatch системой в Snow Leopard.