Процесс многопроцессорной обработки Python по сравнению с автономным Python VM
Кроме простоты использования multiprocessing модуль когда дело доходит до процессов присоединения с коммуникационными ресурсами, там любые другие различия между порождением нескольких использования процессов multiprocessing по сравнению с использованием subprocess запустить отдельный Python VMs?
2 ответа
На платформах Posix, примитивы многопроцессорной обработки по существу оборачивают os.fork () . Это означает, что в момент, когда вы запускаете процесс в многопроцессорном режиме, уже импортированный / инициализированный код остается в дочернем процессе.
Это может быть благом, если у вас есть много вещей для инициализации, а затем каждый подпроцесс, по сути, выполняет операции с (копиями) этих инициализированных объектов, но не все так полезно, если то, что вы запускаете в подпроцессе, совершенно не связано.
Есть также последствия для ресурсов, таких как дескрипторы файлов, сокеты и т. Д. С многопроцессорной обработкой на unix-подобной платформе.
Между тем, используя подпроцесс , вы создаете совершенно новую программу / интерпретатор каждый раз, когда запускаете новый процесс. Это означает, что между ними может быть меньше разделяемой памяти, но это также означает, что вы можете Popen в совершенно отдельную программу или новую точку входа в ту же программу.
В Windows разница между multiprocessing и подпроцессом меньше, поскольку Windows не поддерживает fork () .
Это отличный вопрос. Здесь существует более одного правдоподобного подхода; вы должны сбалансировать компромиссы и сделать выбор, который соответствует вашим обстоятельствам.
(1) Некоторые утверждают, что этот интерфейс документа должен обеспечивать метод визуализации экземпляров. Это привлекательно с точки зрения OO, но, в зависимости от ваших технологий просмотра, загрузка конкретных классов Document, которые, вероятно, являются простыми модельными классами домена, со знанием JSP, Swing Components или чего-либо другого, может быть непрактичной или абсолютно безобразной.
(2) Некоторые предлагают использовать метод Последовательности getViewName () в Document , который возвращает, например, путь к JSP-файлу, который может правильно визуализировать этот тип документа. Это позволяет избежать уродства # 1 на одном уровне (зависимости библиотеки/« тяжелый подъемный »код), но концептуально создает ту же самую проблему: модель домена знает, что она визуализируется JSP, и знает структуру webapp.
(3) Несмотря на эти точки, лучше, если ваш класс Controller не знает, какие типы документов существуют во вселенной и к какому типу принадлежит каждый экземпляр Document . Рассмотрите возможность настройки какого-либо сопоставления представлений в каком-либо текстовом файле: .properties или .xml. Ты используешь Спринг? Spring DI позволяет быстро указать карту конкретных классов документов и компоненты JSP/View, которые их визуализируют, а затем передать их установщику/конструктору вашего класса Controller. Этот подход позволяет как (1) вашему коду контроллера оставаться агностическим для типов Document , так и (2) вашей модели домена оставаться простым и агностическим для технологий просмотра. Это происходит за счет дополнительной конфигурации: .properties или .xml.
Я бы пошел за № 3 или - если мой бюджет (по времени) для работы над этой проблемой мало - я бы (4) просто жесткий код некоторые базовые знания документов типов в моем контроллере (как вы говорите сейчас) с целью перехода на # 3 в будущем в следующий раз, когда я вынужден обновить свой контроллер из-за менее чем оптимальных характеристик OO. Дело в том, что # s 1-3 каждый занимает больше времени и более сложны, чем # 4, даже если они «правильнее». Придерживаться # 4 также кивает на YAGNI Principal : нет уверенности, что вы когда-либо испытаете негативные последствия # 4, имеет ли смысл оплачивать затраты на их предотвращение?
Я все еще использую старую программу RTVReco . Это просто приложение для нажатия кнопки и очень простое в использовании. Он давно не обновлялся, но он все еще самый простой из всех, что я видел.
-121--4321492- Если вы игнорируете какие-либо проблемы связи (т.е. если отдельные виртуальные машины Python не взаимодействуют между собой или взаимодействуют только через другие явно установленные механизмы), нет других существенных различий. (Я считаю, что многопроцессорная ,при определенных условиях - Unix-подобные платформы, в частности, - могут использовать более эффективную форк , а не пару вилк-exec, всегда подразумеваемую многопроцессорной - но это не «существенно», когда задействовано всего несколько процессов [[IOW, разница в производительности при запуске не будет существенной для производительности всей системы]]).