Безусловно, есть тьма более низкоуровневых решений, которые вероятнее всего при должной реализации будут более эффективны. Но прелесть Python multiprocessing как раз в высоком уровне абстракции.
В моей практике я сталкивалась в основном со случаями, когда и это не годится из-за не-pickable начинки объектов, и тогда приходилось строить решение с помощью событий и других средств.
Мне в голову первым делом приходит ситуация, когда какие-то изменения в объект вносятся через интерфейс, который живет в своем процессе, а сам объект используется для вычислений в другом процессе. Например, вы настроили 3Д модельку чайника на газовой горелке, потом для нее другой процесс рассчитал распределение тепла и вернул эти данные в окно визуализации. Здесь с одной стороны удобно передавать массивы данных, они скорее всего pickable (однако зависит от класса модели), а с другой стороны, при достаточно высокой детализации копировать обновленные данные туда-сюда между процессами очень накладно. Эффективнее один раз передать (это медленно), а потом уже SyncManager будет передавать только изменения, что гораздо быстрее.
Хорошее замечание. Действительно, можно "привязать" процессы насильно к ядру. Но если мы говорим о "голом" multithreading, то там все отдается на волю ОС.
Shared memory используется именно для процессов (processes), так как у них нет общего доступа к памяти, в отличие потоков (threads). Код Python не позволяет нам управлять тем, на каком конкретно ядре или процессоре будет исполнен код. Shared memory работает в любом случае. В документации это описано.
Ссылка, действительно не очень соответствует. Я использовала кальку с английского . Все же тут речь именно о методе построения алгоритмов и написания программ, а не о конкретных вычислениях. То есть я имела в виду программирование как навык.
Безусловно, есть тьма более низкоуровневых решений, которые вероятнее всего при должной реализации будут более эффективны. Но прелесть Python multiprocessing как раз в высоком уровне абстракции.
В моей практике я сталкивалась в основном со случаями, когда и это не годится из-за не-pickable начинки объектов, и тогда приходилось строить решение с помощью событий и других средств.
Мне в голову первым делом приходит ситуация, когда какие-то изменения в объект вносятся через интерфейс, который живет в своем процессе, а сам объект используется для вычислений в другом процессе. Например, вы настроили 3Д модельку чайника на газовой горелке, потом для нее другой процесс рассчитал распределение тепла и вернул эти данные в окно визуализации.
Здесь с одной стороны удобно передавать массивы данных, они скорее всего pickable (однако зависит от класса модели), а с другой стороны, при достаточно высокой детализации копировать обновленные данные туда-сюда между процессами очень накладно. Эффективнее один раз передать (это медленно), а потом уже SyncManager будет передавать только изменения, что гораздо быстрее.
Но мне кажется, это всегда некоторый компромисс)
Хорошее замечание. Действительно, можно "привязать" процессы насильно к ядру. Но если мы говорим о "голом" multithreading, то там все отдается на волю ОС.
Shared memory используется именно для процессов (processes), так как у них нет общего доступа к памяти, в отличие потоков (threads). Код Python не позволяет нам управлять тем, на каком конкретно ядре или процессоре будет исполнен код. Shared memory работает в любом случае. В документации это описано.
Ссылка, действительно не очень соответствует. Я использовала кальку с английского . Все же тут речь именно о методе построения алгоритмов и написания программ, а не о конкретных вычислениях. То есть я имела в виду программирование как навык.