Комментарии 19
Ну... Тогда, наверное, есть и перпендикулярное программирование? Может все-таки это разбивка на потоки, которые выполняются одновременно.... Может быть, если ядер много.. Или квазиодновременно, если их не достает...
И вопрос: при реальном исполнении потоков на разных ядрах (или разных процах) вы уверены, что
но в простых случаях лучше использовать
shared memory
вообще будет доступно на другом проце/ядре.
Параллельное программирование есть и успешно (или неуспешно) используется в мире.
Просто в данном конкретном случае имелось ввиду "праллельные вычисления", или распределенные вычисления? Я бы на месте автора перефразировал вступительный абзац. Даже ссылка ведет на "параллельные вычисления"
Ссылка, действительно не очень соответствует. Я использовала кальку с английского . Все же тут речь именно о методе построения алгоритмов и написания программ, а не о конкретных вычислениях. То есть я имела в виду программирование как навык.
Не надо использовать кальку с английского, особенно в том случае, если в результате получившееся выражение уже имеет в языке иное и давно устоявшийся смысл. "Параллельное программирование" это методика программирования, а не то, о чем вы пишете всю статью.
То есть я имела в виду программирование как навык.
Так под параллельным программированием часто подразумевают парное программирование, поэтому построение алгоритмов, которые можно горизонтально распределить. Это не обязательно вычисление в несколько потоков ядра, это именно архитектура алгоритмов, которая позволяет вычислять что-то несколькими участниками, то есть "Распределенные вычисления".
Parallel Computing это взгляд со стороны теории как на вычислительную проблему.
Parallel Programming - со стороны возможностей, предоставляемых Execution Model для вашего языка или фреймворка и конкретным Runtime.
Разница между ними как между правилами дорожного движения и инструкцией по управлению автомобилем.
Distributed Computing - вычислениями в абстрактных распределенных средах (distributed systems), где несколько компьютеров соединены сетью.
Shared memory используется именно для процессов (processes), так как у них нет общего доступа к памяти, в отличие потоков (threads). Код Python не позволяет нам управлять тем, на каком конкретно ядре или процессоре будет исполнен код. Shared memory работает в любом случае. В документации это описано.
Python не позволяет нам управлять тем, на каком конкретно ядре или процессоре будет исполнен код
Возможно вы имели какой-то конкретный случай, а так есть os.sched_setaffinity .
Можете привести примеры приложений где это стоит использовать на практике, а в каких случаях лучше поискать другие альтернативы?
В моей практике я сталкивалась в основном со случаями, когда и это не годится из-за не-pickable начинки объектов, и тогда приходилось строить решение с помощью событий и других средств.
Мне в голову первым делом приходит ситуация, когда какие-то изменения в объект вносятся через интерфейс, который живет в своем процессе, а сам объект используется для вычислений в другом процессе. Например, вы настроили 3Д модельку чайника на газовой горелке, потом для нее другой процесс рассчитал распределение тепла и вернул эти данные в окно визуализации.
Здесь с одной стороны удобно передавать массивы данных, они скорее всего pickable (однако зависит от класса модели), а с другой стороны, при достаточно высокой детализации копировать обновленные данные туда-сюда между процессами очень накладно. Эффективнее один раз передать (это медленно), а потом уже SyncManager будет передавать только изменения, что гораздо быстрее.
Но мне кажется, это всегда некоторый компромисс)
Ещё приходит на ум вариант передавать данные через unix-socket или tcp-socket.
Безусловно, есть тьма более низкоуровневых решений, которые вероятнее всего при должной реализации будут более эффективны. Но прелесть Python multiprocessing как раз в высоком уровне абстракции.
прокачивать данные через socket должно быть заметно медленнее, чем передача через общую память.
Общей памяти может физически не быть.
А так вообще для таких вещей в природе существует MPI.
Не понял, что значит "может физически не быть". Интерфейс к общей (разделяемой) памяти - часть стандартной библиотеки Python:
https://docs.python.org/3/library/multiprocessing.shared_memory.html
Ну а вслуче, когда на системе закончилась память, наступает пора поиска новых решений на замену тех, что приводят к истощению ресурсов машины.
А алгоритм может быть так построен, что не так уж много данных нужно передавать, или эта часть не является бутылочным горлышком
Python Multiprocessing. Обмен данными между процессами. Передача объектов пользовательских классов