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

"I checked it out and it looks good, but I also heard that processes, unlike threads, can't share a lot of information..."

This is only partially true.

Threads are part of a process -- threads share memory trivially. Which is as much of a problem as a help -- two threads with casual disregard for each other can overwrite memory and create serious problems.

Processes, however, share information through a lot of mechanisms. A Posix pipeline (a | b) means that process a and process b share information -- a writes it and b reads it. This works out really well for a lot things.

The operating system will assign your processes to every available core as quickly as you create them. This works out really well for a lot of things.

Stackless Python is unrelated to this discussion -- it's faster and has different thread scheduling. But I don't think threads are the best route for this.

"I think my program will need to share a lot of information."

You should resolve this first. Then, determine how to structure processes around the flow of information. A "pipeline" is very easy and natural to do; any shell will create the pipeline trivially.

A "server" is another architecture where multiple client processes get and/or put information into a central server. This is a great way to share information. You can use the WSGI reference implementation as a way to build a simple, reliable server.

• Stackless : использует 1 процессор. «Тасклеты» должны уступать добровольно. Параметр вытеснения работает не всегда.
• Каскадный : используется 1 процессор. Нативные потоки делят время несколько случайным образом после запуска 20-100 кодов операций Python.
• Многопроцессорная обработка : использует несколько процессоров

Обновление

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

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

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

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

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

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

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

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

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

With CPython multiple threads can't execute at the same time because of the GIL: link text.

I think it's still possible that threads boost your application, e.g. a thread might block on I/O while another one does some work.

If you've never used threads, I suggest that you try them first. It will be useful in any other language, and you'll find a lot of ressources on the web. Then if you realize that you need more parallelism, you still can switch back to processes.

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

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

Звучит так, как будто вы хотели бы создать поток.

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

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

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

В этом году на 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 /

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

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