Многопроцессорная или многопоточная обработка?

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

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

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

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

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

Answer 3

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

Update

INDEPTH Анализ

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

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

Answer 6

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

Answer 7

Это звучит, как вы хотели бы многопоточность.

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

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

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

Answer 8

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

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

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

Answer 9

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

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

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