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

Я делаю программу для запуска моделирования в Python с интерфейсом wxPython. В программе вы можете создать симуляцию, и программа отобразит (= вычисляет) ее для вас. Иногда рендеринг может быть очень трудоемким.

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

Должен ли я использовать несколько процессов или несколько потоков или что? Люди сказали мне использовать пакет multiprocessing, я проверил его, и он выглядит хорошо, но я также слышал, что процессы, в отличие от потоков, не могут делиться большой информацией (и я думаю, что моя программа должна будет поделиться много информации.) Кроме того, я также слышал о Stackless Python: это отдельный вариант? Я понятия не имею.

Просьба сообщить.

Ответ 1

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

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

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

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

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

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

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

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

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

Ответ 2

Stackless: использует 1 процессор. "Задачи" должны давать добровольно. Опция preemption не работает все время.
Резьбовое: использует 1 процессор. Собственные потоки распределяют время несколько случайным образом после выполнения 20-100 кодов операций python.
Многопроцессорная обработка: использует несколько процессоров

Обновление

Независимый анализ

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

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

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

Ответ 3

В этом году был неплохой разговор о многопроцессорности в 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/~~

Ответ 4

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

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

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

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

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

Ответ 5

С несколькими потоками CPython невозможно выполнить одновременно из-за GIL: текст ссылки.

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

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

Ответ 6

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

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

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

Ответ 7

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

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

Ответ 8

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

"Использование блокировки глобального интерпретатора на языке эффективно ограничивает количество parallelism достижимо через concurrency одного интерпретатор с несколькими потоками. Если процесс почти чисто составленный из интерпретируемого кода и не вызывает вызовы за пределами переводчик в течение длительных периодов времени (который может освободить блокировку на GIL на этом потоке, пока он обрабатывается), вероятно, будет очень небольшое увеличение скорости при запуске процесса на многопроцессорная машина. Из-за сигнализации с потоком, связанным с процессором, это может вызвать значительное замедление даже на отдельных процессорах".

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

Ответ 9

Похоже, вы хотите нарезать резьбу.

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

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

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