Вы видите эту фразу или подобное время от времени, как правило, относящуюся к программе, которая утверждает, что они не были разработаны, чтобы использовать все преимущества многоядерных процессоров. Это особенно характерно для программирования видеоигр. (конечно, многие программы не имеют параллелизма и не нуждаются в нем, такие как базовые сценарии и т. д.).
Как это может быть? Многие программы (особенно игры) по своей природе используют параллелизм, и, поскольку ОС отвечает за планирование задач на ЦП, то эти программы по своей природе не используют преимущества нескольких доступных ядер? Что бы в этом контексте означало «использовать преимущества нескольких ядер»? Эти разработчики на самом деле запрещают планирование задач ОС и принуждают к сродству или их собственному планированию? (Походит на главную проблему стабильности).
Я программист на Java, поэтому, возможно, мне не приходилось сталкиваться с этим из-за абстракций или чего-то еще.
источник
Ответы:
Хороший параллелизм требует гораздо большего, чем просто добавить несколько потоков в приложение и надеяться на лучшее. Существует диапазон того, насколько параллельная программа может идти от смущающе параллельной к чисто последовательной. Любая данная программа может использовать закон Амдала, чтобы выразить масштабируемость проблемы или алгоритма. Пара квалификаций для смущающе параллельного заявления была бы:
Существуют и другие квалификации, но только с этими двумя мы можем понять, почему игры, в частности, не так просты, как вы думаете, чтобы использовать преимущества нескольких ядер. Например, модель мира, которая будет отображаться, должна использоваться совместно, поскольку различные функции вычисляют физику, движение, применяют искусственный интеллект и т. Д. Во-вторых, каждый кадр этой игровой модели должен отображаться на экране с помощью графической карты.
Честно говоря, многие производители игр используют игровые движки сторонних производителей. Это заняло некоторое время, но эти сторонние игровые движки теперь намного более параллельны, чем раньше.
Есть большие архитектурные проблемы в борьбе с эффективным параллелизмом
Параллелизм может принимать разные формы, от запуска заданий в фоновом режиме до полной архитектурной поддержки параллелизма. Некоторые языки предоставляют вам очень мощные функции параллелизма, такие как ERLANG , но требуют, чтобы вы по-разному думали о том, как вы создаете свое приложение.
Не каждая программа действительно нуждается в сложности полной многоядерной поддержки. Одним из таких примеров является налоговое программное обеспечение или любое приложение на основе форм. Когда большая часть вашего времени тратится на то, чтобы пользователь что-то сделал, сложность многопоточных приложений просто не так полезна.
Некоторые приложения поддаются более смущающему параллельному решению, например, веб-приложениям. В этом случае платформа начинает смущать параллельно, и вам не нужно навязывать конфликт потоков.
Суть:
Не все приложения действительно страдают, если не используют преимущества нескольких потоков (и, следовательно, ядер). Для тех, кому это больно, иногда вычисления не подходят для параллельной обработки или накладных расходов для ее координации, что делает приложение более хрупким. К сожалению, параллельная обработка все еще не так проста, как это должно быть хорошо.
источник
Нет, на самом деле все наоборот. Большинство приложений написаны в едином многопоточном мышлении, и разработчики никогда не вносили необходимые изменения для поддержки параллелизма.
В C, C ++ и C # вам необходимо явно указать приложению запуск новых потоков и / или процессов.
Я думаю, что вы слишком сосредоточены на планировании потоков и недостаточно на обработке данных в потенциальных потоках. Совместное использование данных между потоками и / или процессами требует определенной формы синхронизации. Если вы измените приложение на использование нескольких потоков, но не сможете выполнить синхронизацию, вы, вероятно, увидите много трудных для отслеживания ошибок в коде.
Что касается многопоточных приложений, над которыми я работал, я, как правило, никогда не беспокоился о диспетчеризации и только о синхронизации данных. Единственное, о чем мне приходилось беспокоиться об отправке, это когда я гонялся за условиями гонки из-за неправильной синхронизации данных.
Обычно, когда приложение говорит, что не может использовать несколько ядер, это означает, что у них нет синхронизации для защиты манипулирования данными.
источник
Это касается не столько ядер, сколько потоков. ОС может запланировать запуск потока на любом ядре, и это планирование прозрачно для запланированной программы. Однако многие программы не пишутся с использованием нескольких потоков, поэтому они могут работать только на одном ядре одновременно.
Зачем мне писать однопоточные программы? Их легче писать и легче отлаживать: одна вещь происходит за другой (вместо того, чтобы несколько вещей происходили одновременно и, возможно, переходили друг в друга). Или ваша программа может быть не нацелена на многоядерные машины (как в старых играх). В некоторых случаях многопоточная программа может работать даже медленнее, чем однопоточная версия, если накладные расходы от переключения контекста и обмена данными между потоками превышают скорость, получаемую при параллельном выполнении (некоторые части программы могут не распараллеливаться).
источник
Это не полный ответ. Это предостерегающая история.
Однажды я подумал, что покажу студентам в моем параллельном курсе программирования параллельную быструю сортировку. «Быстрая сортировка должна хорошо распараллелить», - подумал я. Я использовал две темы. Запустил его на моем одноядерном компьютере. Результаты были:
Это было о том, что я ожидал.
Затем я попробовал это на более новой двухъядерной машине.
Два потока разделяют очередь оставшихся задач. Похоже, что поля объекта очереди перемещались взад-вперед между кэшем одного ядра и кэшем другого.
источник