Многопроцессорность или многопоточность?

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

Это верно лишь отчасти.

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

Однако процессы обмениваются информацией посредством множества механизмов. Конвейер Posix (a | b) означает, что процессы a и b совместно используют информацию — a записывает ее, а b читает. Это работает очень хорошо для многих вещей.

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

Stackless Python не имеет отношения к этому обсуждению — он быстрее и имеет другое планирование потоков. Но я не думаю, что потоки - лучший способ для этого.

"Я думаю, что моя программа должна будет предоставить много информации."

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

«Сервер» — это еще одна архитектура, в которой несколько клиентских процессов получают и/или помещают информацию на центральный сервер. Это отличный способ поделиться информацией. Вы можете использовать эталонную реализацию WSGI для создания простого и надежного сервера.

• Бесстековый: использует 1 ЦП. «Задания» должны сдаваться добровольно. Вариант с приоритетом работает не всегда.
• Threaded: использует 1 ЦП. Собственные потоки распределяют время несколько случайным образом после запуска 20-100 опкодов Python.
• Многопроцессорность: использует несколько процессоров.

Обновить

Углубленный анализ

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

Используйте многопроцессорную обработку, если она очень ограничена мощностью процессора и вам нужна максимальная скорость отклика.

Не используйте stackless, у меня раньше был segfault, и потоки в значительной степени эквивалентны, если только вы не используете сотни или более из них.

В этом году на Pycon был хороший разговор о многопроцессорности. Вывод был следующим: «Используйте многопроцессорность только в том случае, если вы уверены, что у вас есть проблема, которую она решит, которую нельзя решить с помощью потоков; в противном случае используйте потоки».

Процессы имеют много накладных расходов, и все данные, которые будут совместно использоваться процессами, должны быть сериализуемыми (т. е. доступными для обработки).

Слайды и видео можно посмотреть здесь: http://blip.tv/pycon-us-videos-2009-2010-2011/introduction-to-multiprocessing-in-python-1957019

http://us.pycon.org/2009/conference/schedule/event/31/

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

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

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

Например, потенциально вы можете запустить 16 процессов на 8 двухъядерных компьютерах, но не получите преимущества от более чем 4 потоков на четырехъядерном компьютере. Если объем информации, которую вам нужно передать, невелик, многопроцессорная обработка может иметь больше смысла.

Что касается описанного вами стиля YouTube, я бы сказал, что он предполагает многопроцессорность. Если вы следуете подходам MVC, ваш графический интерфейс не должен также содержать модель (результат расчета). С помощью многопроцессорности вы можете связаться с менеджером работ, который может сообщить, какие данные уже доступны.

В CPython несколько потоков не могут выполняться одновременно из-за GIL: текст ссылки.

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

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

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

Между прочим, несколько участников проекта Mozilla (в частности, Брендан Эйх, технический директор Mozilla и создатель JavaScript) особенно критически относились к многопоточности. На некоторые материалы есть ссылки здесь, здесь, здесь и здесь подтверждает такой вывод.

Надеюсь, что это поможет и удачи.

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

Если вы решили использовать обработанный, обмен информацией между подпроцессами может осуществляться несколькими способами: соединения tcp/udp, общая память или каналы. Это добавляет некоторые накладные расходы и сложность.

Очень озадачен. Бастьен Леонар справедливо заметил, что GIL лишает возможности использовать многопоточность каким-либо полезным образом. В его справке говорится:

«Использование глобальной блокировки интерпретатора в языке эффективно ограничивает уровень параллелизма, достижимого за счет параллелизма одного процесса интерпретатора с несколькими потоками. периодов времени (что может снять блокировку GIL в этом потоке во время его обработки), вероятно, будет очень небольшое увеличение скорости при запуске процесса на многопроцессорной машине. может привести к значительному замедлению работы даже на одном процессоре».

В этом случае многопроцессорная обработка является разумным выбором. По моему собственному опыту, Python + MT не приносит заметной пользы пользователю.

Похоже, вам нужна многопоточность.

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

То, что вы пытаетесь получить, — это более отзывчивые дисплеи, позволяя пользователю взаимодействовать и обновлять графику во время моделирования. Это именно то, для чего была создана многопоточность Python.

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